Hi community,
In order to balance the load between all the DMAs in a cluster, we are migrating elements from old DMAs to new DMAs. We are using the latest main release version of DataMiner at the moment, 10.0.0 CU4.
The elements we are migrating were created in April 2020, so they don't have too much historic data, but the elements are CMTSs of both vendors CISCO and CASA Systems, so the amount of data is massive nevertheless.
I did some tests with the export/import method, but when the export process finishes, the package is not created in the path provided, so I think you can take the .zip package created on C:\Skyline DataMiner\System Cache\DELT\Export and use it to import it in the destination DMA. I tried this, but the pop-up window didn't show anything.
So my question is, is there a way to adapt this .zip file and make it work on the destination DMA?
Does someone know how to do this, or where I can find this info?
Hi Jaime,
You mentioned the export fails, did you find any error messages in the SLDELT.txt logfile? If something goes wrong during import/export there should be some indication in there.
Besides that, yes it is possible to create your own .import package (ofcourse the .zip packages needs to contain all data to work correctly). Easiest way to go forward is to do an export of an element locally and look at the structure of the .import package (you can just change the .import to .zip and look at the content) and mimic this.
Hi Jelle
I don’t know why the negative votes, but I gave my thumb up, I’ll try this that you mentioned right now since I left running the process to migrate an element yesterday and it’s still there stuck, and I don’t see errors on the DMA source or DMA destination SLDelt log so I’ll end the process and I’ll try to adapt the zip package.
Thanks
I believe this was downvoted because manually creating/modifying DELT packages is not something that should be encouraged.
I just noticed this is being downvoted without any context, Could somebody expand what exactly is wrong?
In the past I had a similar issue at a customer when doing a migration where we ended up in a situation where the element was neither present at the host nor at the destination. In the end we had to construct our own .import package with the data we had available (which was the initial question here) which worked perfectly fine.