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?
This is a known issue at the moment with an easy workaround, but not an easy fix.
See: https://intranet.skyline.be/DataMiner/Lists/Release%20Notes/DispForm.aspx?ID=25177
The crux here is that a DELT export of an element that is not hosted on the dma you’re connected to follows a slightly different flow and needs to use a call that can time out. If the DELT export takes a long time (as is probable here), the call to the hosting DMA will time out and the resulting export package won’t be made. (It will be made, when finished, on the hosting DMA, but since the call already timed out, it won’t be sent to the requesting DMA to be put in the final export package) The workaround for this is to start the DELT export of the element on the same DMA as the element is hosted on.
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.
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.
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.
HI Laurens
Thanks for your answer, and indeed that is the first thing that I check when a I try to migrate an element (see that the element belongs to that DMA). Just yesterday I tried to move another element and the process is still there, so I will try to adapt the .zip file created in the DELT cache and try to import it in the destination DMA, I think the process has many problems when the element is heavy.