Good morning guys,
I'm in the process of moving my Domain Controller VM from my main datastore to a second due to damage on the first datastore.
Unfortunatelly the VM wasn't made by me so it' essentially a 1.08TB VM to move... I started the move and it's saying that it's gonna take upwards of 2 DAYS to move it...
is it possible?????
I followed a guide online which said to just browse the datastore directly and do a move... at hardware level we are talking about two raid arrays:
source is 4x 300GB 15k drives in RAID5 (corrupted because 1 drive is failed and we cannot find the replacement radily available...)
dest is 3x 1.2TB 10k drives in RAID5 (all new installed the other day)
If you are performing storage vmotion of a VM from one datatsore to another.
Many factors comes into consideration:
-->Where does destination datastore created from(is it from same storage or different than source datastore)
-->If its on different storage array then network bandwidth between both the storage matters.
-->You have to check about host if its been facing any storage related issues or performance hit , which could also cause SV motion to slow down
Below guide may help you in giving some limitation, pre-requisites on migrations :
Hi a.p. thanks for your answer I'll try and answer as best as I can... Unfortunatelly as you may have noticed I'm not that big of an expert on esxi... I'm still learning a lot otf things...
1. I know it's slow but my boss only bought me 3 disks so I had to do with what I have... and there was no other way... I'm not sacrificing a disk to run RAID1... With half the capacity... plus our workload doesn't require much in the way of speeds... weìre not working with video producion or anything like that we make programs...
2. The RAID controller is the one integrated in our IBM xSystem 3650 M4 which if I remember correctly is an LSI chip... (The actual controller is called M5110e but I think the chip itself is LSI) and I'm fairly positive it does not have a backup battery... I don't even see a connector for it... Our old DL360 G6 had it but it's so old it's even dropped out of support for esxi 6.7...
3. This is a standalone host we were planning on buying another two hosts and configure a cluster but still haven't got the time to look into it as I've been travelling a lot lately... I "chose" this way because I didn't exactly know there was another... I just typed into good old google "esxi move VM to different datastore" and the first page that came up was pretty good and well wxplained so I thought I trusted it... problem also is that the host is running esxi 5.5 since I had no time to perform the upgrade on it to a later version...
4. Did I backup the VM? hmmm... well shooooot XD
Do you know if there is a way to stop the "sudo-migration" once it's started??? It's now at 9% and it took 4h and 17min to get there............. ouch......................................
Do you know if there is a way to stop the "sudo-migration" once it's started???
Do you have a link to the website on which you found the steps?
Anyway, I'm afraid that without write-cache for the controller, other migration options won't work a lot faster. Without battery buffered write-cache the controller will work in write-through mode (likely ~10 MB/s).
In case you cannot afford the downtime, it may be possible to reduce downtime to a minimum (a few minutes). This however requires some manual work from the command line, and editing the VM's files. If you want to go this way let me know.
Note that what I'm thinking of includes the creation of a snapshot, which will require additional disk space. How much free disk space do you have on the source datastore?
Steps would basically be:
In any case, make sure that you have an up-to-date backup prior to doing this!!!!
Hi a.p. you are very helpful I'll try and give you all info I can...
This is where I got the guide... The VM is already down and as you can see I used the move button of the browser... ergo I think if I stop it now there is a chance of data loss unless there's a rollback comand that I don't know...
I agree, depending on which files are already moved, canceling the job may result in a situation which requires manual fixes.
In this case it's probably better to let it run, and accept the downtime, especially since there's no recent backup (if I understood you correctly).
No it's just that the VM is made of two disks.. OS and archive... this because the guy who made it for us when I still wasn't hired here thought it was better this way... and since last three weeks I wasn't in office nobody in office noticed that in the OS there was a nice error beeping red that said that the connection to the NAS backup could not be performed... ergo the Archive backup probably is there but a few days old...
You should also consider the fact that you only have a single 6GBps data channel Down to Your disks, and if we consider the fact you have a OS to attend to as well, then you can yourself calculate the time consumption.