Migrating large disk - any risks?
-
We have a VM in production and noted today that it's primary storage disk is on an incorrect SR (it's on the root of the host with little free space) - Are there any risks associated when using the migrate utility (moving the VHD to the correct SR), given it's size. Is there any potential storage impact during the migration?
I assume that a snapshot is created of the disk before it's moved, how much space will this use? The SR only has 230GB of space left. Any advice would greatly be appreciated
-
Hi,
Depends if your SR is thin or thick (it will decide about the snap size). Storage migration isn't very fast per disk (around 40/50 MiB/s) but it's safe.
-
@olivierlambert thank you for always assisting. Disk is thin provisioned, the SR is about 1.92TB and the disk is 1.5TB - I am worried if I start the migrate the snapshot will deplete the available free space (and I am not sure what happens then) - As the VM is in production, I want to take the safest possible route, I assume I cannot "test" how big the snapshot will be before starting the migration.
-
It will grow with new blocks written during the transfer. 1.5TiB
But for such a large disk it will be almost 11h of transfer. Maybe a safest route will be:
- Setup a CR task on your destination SR
- Do the initial CR (long, 11h too)
- If it's successful, shutdown the original VM
- Re-do a CR (very fast)
- Boot on destination. If working, remove VM on source
That's the safest route in your case.
-
@olivierlambert fantastic news, I was unsure how snapshots actuall allocate data, so if I understand you correct, when a new snapshot is created (and a new VHD), only data that changes is written to the new snapshot?
So the behind the scenes process is:
- Migrate kicks off and creates a snapshot
- The base VHD is copied accross to the new SR
- After base is copied, a new snapshot is created and the 2nd snapshot is copied accross and merged with the base on the new SR
- Lastly, the last snapshot is copied accross and merged on the new SR
- Xen is updated with the SR on the new server and the VHD's are deleted on the origin SR
Once done, the location of the VHD is updated and the original VHD's is deleted? If this is the case, we should realistically not run out of free space in 11 hours (even 11 days), so we should be able to simply do the vhd migrate.
Only question is, when a snapshot is deleted and the data is merged back into the base snapshot, is a 3rd file created to merge the 2 snapshots into a single file, or is the data of the snapshot "injected" into the base VHD file? If injected, then there is little storage impact but if a new base is created (so effectively block by block) then I assume there is a potential of the SR running out of free space.
The safest route is definitely the the copy approach, but this would require a minimum of 2 restarts (we will need to copy to failover server and then later back to the correct server. If we can avoid that, even if it takes 11 hours, and there is little risk of the SR running out of free space, I would consider this option first
-
It's more a less that. In short, the new disk is created on both sides, and blocks mirrored on both sides.
First, the read only "parent" VDI with frozen blocks is copied, when it's done, the VM is briefly paused, the memory migrated to the destination and then unpaused on destination.
Consequently, only the blocks written during 11 hours will use space for new blocks on the source SR (and destination, since it's mirrored).
