How Do I Do CentOS 7 P2v Migration?

Home » CentOS-Virt » How Do I Do CentOS 7 P2v Migration?
CentOS-Virt 10 Comments

Hi,

I am trying to figure out how to do p2v and v2v migrations on a CentOS 7 kvm host. With previous versions there was virt-p2v but that does not seem to exist with CentOS-7.

I realize that if I am using shared storage, I can do live migrations but that does not help with p2v migrations.

Does anyone know what the recommended procedure is for migrating either physical or virtual machines to CentOS-7 is?

I have tried searching for the answer but my google foo is not being helpful.

Regards,

10 thoughts on - How Do I Do CentOS 7 P2v Migration?

  • Hi

    I do this last week, and I use CloneZilla to generate a file image from a phisical server running Ubuntu and after that, used Clonezilla to restore into KVM hypervisor with no tears…

    Very smoothly…

    Cheers

    2014-08-19 14:21 GMT-03:00 :

  • Thanks for the info. I was kinda hoping for a solution using tools that are supplied with CentOS but this sounds feasible so I will give it a try.

  • Nice

    Keep me posted… I wanna see you progress and I’ll try help..

    Cheers

    2014-08-20 10:54 GMT-03:00 :

  • One of my favorite approaches, which is *FAST*, is to take the live server down and make tarballs of all its relevant filesystems with a live CD, and possibly an NFS share. Store the tarballs for reference, and use a live CD or PXE toolkit to allow access to the disk images in the new virtual machine.

    Then create partitions as needed, mount them, untar the contents onto the partitions, and edit the mounted /etc/fstab. Also do a “grub install” inside the chroot cage, and unless your underlying virtualization.

    Reboot from the new disk image, and voila. Working virtual environment. It can take tuning to automate or optimize it, to install virtualization toolkits or best configure the network, but I’ve installed roughly….. 18,000 systems this way, for both virtualization and hardware operating systems. The tarballs allow excellent source control of the underlying system, and easy tuning of the base OS image: just untar them and do a ‘chroot’ into them, and do manual editing or yum install or whatever. Exit the chroot, and tar them back up, and deploy with the new image.

    This is generally *MUCH, MUCH* faster than replicating disk images or doing a pre-configured kickstart installation.

  • CloneZilla is also my recommendation. I’ve used it for CentOS 5/6 and Windows 2008 P2V to VMWare or Hyper-V and it gets the job done. I’ve even V2V between VMWare and Hyper-V and it worked for Windows and Linux VMs.
    –

  • While maybe not officially recommended, you could rsync [0] the OS over.

    You have a couple of options if you choose to rsync:
    1) set up partitions, mount them in a rescue environment, and rsync most everything (certain items from /dev/ can be excluded and everything from
    /sys/ and /proc/, not to mention NFS mount points, etc). Then tweak fstab, chroot to install grub, and possibly rebuild the initrd/initramfs with proper modules (might need virtio, etc). There are other nuances like MAC
    addresses on interfaces (if HWADDR is defined in your network-scripts files), but those would be a possible gotcha even if you used Clonezilla.
    2) set up partitions, install a fresh copy of CentOS7, then rsync everything over top (means you don’t have to sync identical files).

    You’ll need knowledge of a bunch to do the manual operations (that otherwise would be automated by anaconda) for the rsync method. But the upside is I’ve managed to keep production boxes up and minimized downtime
    (maybe slightly more latency/delay on the production host, but it wasn’t noticeable).

    [0] https://wiki.archlinux.org/index.php/Full_system_backup_with_rsync

  • If you go this route, boot with a Live DVD and make a tarball, or use
    “star” to make an SELinux aware tarball. That way, you have a copy to store, label, and unpack into a chroot cage and edit and propagate elsewhere, as needed.

    Rsync can be efficient, but transmitting and uncompressing a tarball is *much faster*. Put it in the swap partition temporarily, if you need to.

  • +1
    I’ve done this exact process myself, but neglected to mention it to you.

    Can’t beat installing off a local mirror and then rsyncing a few small differences (or much less compared the entire install) between the two machines! ;-)

    That’s the fun of it, eh?