Transfer Large VPS

[infinityM]

Hey Guys,

I was using Virtuaiizor, but I decided to move to Proxmox a short while ago due to the features in proxmox just being more practical...
I do have 1 problem though, I have a vps which is about 2TB big which I need to move, but I can't down it for a day or two to perform the export and import as per proxmox migration guide...

Is there ANY SAFE way to migrate the VM from Virtualizor to proxmox without downing the VM?

 

[Dominic]

Hi!

Could be difficult. What kernel are you using in Virtualizor: kvm, lxc, proxmox? What storage do you use for your VPS?

Best,
Dominic

 

[infinityM]

Hi!

Could be difficult. What kernel are you using in Virtualizor: kvm, lxc, proxmox? What storage do you use for your VPS?

Best,
Dominic

I am using KVM and the storage is LVM

 

[Dominic]

Do you plan to use Proxmox VE on a new server or replace Virtualizor on your current server with Proxmox VE?

 

[infinityM]

Well the server I am moving to is proxmox ve, I intend on shutting down the server that virtualizor is currently running on.

 

[aaron]

I don't believe you will manage without a shutdown. Theoretically, a live migration could work since the source is using KVM for the virtualization like PVE but the chances to recreate the same HW for the VM with the same PCI addresses, etc. is practically zero. Besides doing a live migration manually will difficult in itself?

the storage is LVM

The VMs disk is it's own LV or a file on LVM?

 

[infinityM]

I don't believe you will manage without a shutdown. Theoretically, a live migration could work since the source is using KVM for the virtualization like PVE but the chances to recreate the same HW for the VM with the same PCI addresses, etc. is practically zero. Besides doing a live migration manually will difficult in itself?


The VMs disk is it's own LV or a file on LVM?

Does that matter? All I care about really is the IP address and the data, mac addresses etc is irrelevant.... I've been using the export and import, but this disk is too large, I can do a couple hours, but a couple TB's of disk space is going to take 2 days to export and import into Proxmox / Ceph and that's too much

 

[fabian]

*WARNING* all of the things below are highly experimental and manual *WARNING*

assuming the source VM is a regular Qemu VM, that you have access to the source VMs QMP interface, and that you have some sort of secure & fast link between the virtualizor server and the PVE server.

you could allocate an rbd image on the target/PVE side, then use Qemu's drive mirror and NBD to mirror it while the source VM is still running normally. and then when the drive-mirror is complete (source and target disk have the same content), stop all services in the source VM (to flush everything to disk/stop ongoing activity), suspend the source VM and cancel the drive-mirror (so that the source VM still has the source disk, in case y ou need to revert). kill the NBD server on the target side, start up the PVE VM with the mirrored disk, and if everything worked, from the VM's point of view it should be like a crash while no services where running. if you don't get the target VM running, you can delete the mirrored disk, resume the source VM and start the services again, and attempt again at a later point in time.

highly recommended to test this first with a small VM, and then again with a bigger test VM that is under similar load like the production one. no garantuees, and the outline above is an outline intentionally. if you are not able to get the needed commands using the Qemu man pages and spend some time familiarizing yourself with them, you probably should not attempt any of the above.

also note that Qemu does not (yet) support incremental drive mirror, so it either works or you probably need to start again from scratch. an alternative might be to use the qemu-internal backup (which has incremental modes), but you'd need to investigate that yourself

 

[aaron]

Does that matter?

The one idea that I have that could work will need the disk as a file AFAICT (raw or qcow).

* Create a NFS or SMB export on the same file system as the VM disk is on.
* Add that export as a storage on the PVE server.
* Create a new VM config, similar to the current VM on the PCE server and use that new storage.
* Stop the VM
* Then mv the VMs disk file to the <export dir>/images/<vmid>/vm-<vmid>-disk-0.qcow or similar. This should be instantaneous if done on the same file system.
* Start the VM
* Use the Move Disk button to move the disk to another storage.

Performance will most likely be bad for the time it takes to move the disk because the access to the disk and the migration will share the same network connection.

And as fabian mentioned, try this with a test VM first!

 

[infinityM]

Out of curiosity is it not possible to make a backup of a running VM in virtualizor and somehow restore that backup in Proxmox?
Even if that does take an hour to do? That's still acceptable

 

[aaron]

Out of curiosity is it not possible to make a backup of a running VM in virtualizor and somehow restore that backup in Proxmox?
Even if that does take an hour to do? That's still acceptable

Most likely, but I thought we are talking about a VM with 2TB of storage and that any operation of moving that to the new server will take way too long of a downtime for you?

That's why we are coming up with ideas on how to avoid or keep the downtime to a minimum.

 

[infinityM]

Most likely, but I thought we are talking about a VM with 2TB of storage and that any operation of moving that to the new server will take way too long of a downtime for you?

That's why we are coming up with ideas on how to avoid or keep the downtime to a minimum.

Well ja I need to keep down time to a minimum... But if for example I can get the VM moved over to the new server, we can then just RSYNC the files from the /home directory once moved, and export the MySQL database and import it again.

Those small file differences will be much easier to sync accross if I can get the actual VM moved over without down time...

For example, My thought is:

1. Backup the VM (while running)
2. Restore the vm to Proxmox VE
3. Rsync /home to newly restored VM
4. Export DB & Import it in new VM
5 Shutdown Old VM

That would be ideal. Your previous alternatives would also do the job, but seem a bit more risky... I'd love a safe process, even if it is a few more steps to do it

 

[aaron]

If what is running in the VM actually allows for that then why not.

What kind of backups can you get out of Virtualizer?

 

[infinityM]

I am not sure how the backup can be used with Proxmox (Hense the thread )... Was hoping someone had some experience with it? or advise?

 

[fabian]

if you can get some form of disk image(s) out, those should be importable into PVE. PVE supports qcow2 and raw image files. you can create a VM without disk and your desired settings (CPU, memory, ..) and then use 'qm importdisk' to import the image: qm importdisk <vmid> <source> <storage> [--format <raw|qcow2|vmdk>], where --format is the format of the target disk, the source disk is auto-detected.

 

[infinityM]

if you can get some form of disk image(s) out, those should be importable into PVE. PVE supports qcow2 and raw image files. you can create a VM without disk and your desired settings (CPU, memory, ..) and then use 'qm importdisk' to import the image: qm importdisk <vmid> <source> <storage> [--format <raw|qcow2|vmdk>], where --format is the format of the target disk, the source disk is auto-detected.

Hey Guys,

Can you maybe advise... I've been playing around, And found that Virtualizor's backup makes a .img.gz export, So it's quite simple, just export, unzip and import actually...

There's only 1 thing that i'd like to try and achieve, Can I import and unzip at the same time. The export is 2TB large, so unzipping then importing is going to be a very tedious process since the external drive doesn't have enough free space left for both that image and the zipped file...

Is there a way to directly import from a gz or unzip and import at the same time avoiding the double space usage?

 

[aaron]

AFAIK the qm importdisk cannot do that by itself and does not take input from STDIN.

Do you still use the LVM storage? Assuming that the img.gz backups are RAW image files you could do the following:

Create the VM with a disk of the right size. You will have the disk on the LVM and it should be exposed in /dev/mapper/pve-vm--<VMID>--disk--<X>

Then decompress the image and pipe the output into dd which writes the data directly into the LV which stores the disk data.

gunzip -d -c | dd of=/dev/mapper/pve-vm--<VMID>--disk--<X> bs=16M

That would be the general idea. I did not test if the commands work exactly like this. Before trying this with 2TB please use a smaller test VM to check if this approach works as expected.

 

[infinityM]

AFAIK the qm importdisk cannot do that by itself and does not take input from STDIN.

Do you still use the LVM storage? Assuming that the img.gz backups are RAW image files you could do the following:

Create the VM with a disk of the right size. You will have the disk on the LVM and it should be exposed in /dev/mapper/pve-vm--<VMID>--disk--<X>

Then decompress the image and pipe the output into dd which writes the data directly into the LV which stores the disk data.

gunzip -d -c | dd of=/dev/mapper/pve-vm--<VMID>--disk--<X> bs=16M

That would be the general idea. I did not test if the commands work exactly like this. Before trying this with 2TB please use a smaller test VM to check if this approach works as expected.

I think you have it the wrong way around, The Virtualizor has LVM setup. But that's where I got the image exported.
I now have a something.img.gz file that contains the disk's image I exported from Virtualizor, and I need to import that into my ceph array.

Normally I would do it with qm importdisk 100 /path/export.img Default but since it's a gunzip file now, I am not sure how I can import it without unzipping it first?