[PVE-User] Migration to Proxmox VE - Any hints & tips for me?

[Alexandre Kouznetsov]

Hello.

El 14/03/13 12:45, Thinker Rix escribió:
> Thougths & Questions:
> ==================================
> 1. Server A in DMZ:
> My idea is that I backup the virtual disk file of the current VM to an
> USB hard disk, then delete everything and install Proxmox VE on the bare
> metal. After this I copy the virtual disk file of the VM back to Proxmox
> by reconnecting the USB hard disk and make Proxmox VE run this file as a VM
> a) Do you see any obstacles I have to take care of?
Yes.
In case something (anything) goes wrong, you will burn your ships and be 
unable to do a graceful rollback.
I would suggest you to get a new hard disk and use it to install 
Proxmox, without deleting or overwriting anything on the disk that holds 
you current KVM installation. In the worst case, you will have to switch 
the disks back and be able to make another attempt later.
Otherwise, you would have to blow dust form your Disaster Recovery Plan, 
do you have one?

> b) Is it possible to connect the USB hard disk for restoring the virtual
> disk file in Proxmox? I have a normal Debian under the hood, isn't it,
> so I should be able to just mount the USB disk and copy the file to some
> place that Proxmox expects such virtual disk files, right? What place is
> that and what would be the procedure be to make Proxmox use this virtual
> disk file as a VM afterwords?
Proxmox host is expected to recognize your USB disk as any other Debian 
system. You will need to decide a mount point, mount it, and perform any 
file operations manually.
After a default installation of Proxmox, the KVM virtual disk images are 
stored under /var/lib/vz/images/${VMID}/ .

What I have done successfully, is to create a "empty" VM with the
desired name and configuration on the target host, make sure it's turned 
off, and overwrite the files within /var/lib/vz/images/${VMID}/ with the 
disk images from my backup. Make sure the filenames and permissions are 
right. Check the virtual disk image format (RAW by default).

As you move from another KVM, I would expect this procedure to "just 
work". In case you where moving form another type of hypervisor or 
baremetal, the contents of the image would probably need to be modified.


> c) Do you see any problems concerning the "specs"of the VM and
> compatibility with Proxmox VE?
Should not be a problem at all for a Linux VM.

> 2. Server in LAN:
> My idea is to make a full disk backup of the current partition 1 (OS and
> server services) with Clonezilla and an rsync-copy of the data on
> partiton 2, both to an external USB hard disk. Then I delete everything
> and install Proxmox VE on the bare metal. Finally I create a VM, run
> clonezilla again and restore partition 1 and the user data of partition
> 2 by reconnecting the USB-hard disk.
> a) Do you see any obstacles I have to take care of?
Same considerations as in case of server A.
Another thought, don't attempt a simultaneous migration. Do first one, 
and begin the second only after you finish and arm yourself with the 
experience.

Since Proxmox KVM can use a raw image, you may use dd instead of 
Clonezilla or rsync-copy. Note that you will have to go around the 
change of the partitioning schema.

Consider this example:
1. Create the target raw disk image of the desired size on USB drive, dd 
if=/dev/zero of=file.img.
2. Partition your disk images, pretty plain: fdisk file.img
3. Map your disk image partitions to a block device: kpartx -a file.img 
(look for the mapped partitions under /dev/mapper).
4. If the sizes allows it, dd data from your actual partition to the 
mapped partition. If you change the sizes, it would probably be a better 
idea to format the target, mount it, and copy files via "cp -a" to it.
5. Unmap your disk image partitions, so you can take the file elsewhere 
or remove the USB: kpartx -d file.img
6. Repeat with each desired partition.

Note that you will have to do something different with your boot drive. 
A simple dd of the MBR might work, and might not. A "dump" approach 
would be not to bother with the boot loader at all, use a rescue LiveCD 
(as ISO image) on the first boot of your VM and apply a standard boot 
loader recovery technique (mount, chroot, etc).


> b) How about the user data partition? Should I place the data into the
> VM I just created, too, or would it be advisable to create some other
> data drive for that?
I use a separate virtual disk for separate things, even if they live on 
the same VM. This is regardless of the hypervisor used.
For example, in case of a server with user data (homedirs) and service 
data it would need 3 virtual disks: mounted, let's say, as /, /home and 
/srv.
Note that the VM will see the disks as separated block devices, so it's 
a good idea to partition them before use.

> Would it be possible to create some kind of "shared
> data volume" (on this server, not in the network!) for multiple VMs of
> this server to be able to access the data?
Shared between who, different VM's on the same host? That is already so, 
/var/lib/vz is shared between VMs and OpenVZ containers.
Not sure if it's possible to attach the same disk image to several VM's 
simultaneously, probably not. You can use NFS between two VM's, and 
connect them via private network bridge, with no physical interfaces 
attached.

> Or what do you suggest on how
> to handle the Samba Server and it's user data best?
Separate virtual disk for data, no evident need for anything more fancy.

> c) Can I make this partition to be growing instead of the necessity to
> define a fixed size upfront?
You can always resize an existing virtual disk. Note that after that you 
will need to resize the partition within VM, and resize the FS.
http://pve.proxmox.com/wiki/Resizing_disks
Other option would be to define is as a sparse file from the beginning, 
but that would complicate the migration process.


-- 
Alexandre Kouznetsov