[Libguestfs] Pseudo code for v2v

[Matthew Booth]

On 24/07/09 18:30, Gene Czarcinski wrote:
> On Wednesday 15 July 2009 05:12:43 Matthew Booth wrote:
>> I've attached my initial thoughts on the design for the v2v tool.
>
> I have looked over your document and have some questions/comments.
>
> First of all, I would like to see a "plain language" writeup which describes
> your long-term and near-term goals plus a bit on how you plan to do the
> migration/conversion.

Near-term we're looking to have a reliable path from Xen -> KVM. Longer 
term is still under discussion.

> I assume that "v2v" means migrating/converting a guest from one hypervisor
> such as Xen or VMware to another such as qemu-kvm.  Is the long term goal
> going to handle conversion other than to qemu-emu?  How about VirtualBox
> guests?
>
> I do believe that a "super" tool can be created to convert anything to
> anything (or even just to qemu-kvm).  BUT I am skeptical that it is worth the
> effort!  I am extremely skeptical that you will be able to do it for MS Windows
> guests.  I base this skepticism on my our experience of migrating a couple of
> VMware Fedora guests and a couple of VMware win2k guests to qemu-kvm.

I agree that a much more general tool should be possible and may be 
desirable. The focus at the moment, however, is just a qemu-kvm target. 
I guess we'd accept patches for other targets.

> Before describing what I did, a couple of things:
>
> -  maybe I was just lucky but all of the VMware virtual disks and the qemu-kvm
> virtual disks share a common disk geometry: 255 tracks and 63 sectors/track.
> This meant that I could use the same vmdk image file with different disks (that
> is, SCSI, IDE, virtio).  Before doing anything with a vmdk file, I used vmware-
> vdiskmanager to convert segmented vmdk files into a single (sparse) vmdk file.
>
> - I must thank you (Matt) for the tip you gave me via a mailing list message
> by Richard R. M. Jones.  In my own words, the tip was "its the drivers
> stupid".  That is, if I could fix up the drivers on the new qemu-kvm guest,
> then the guest would work.
>
> The following is the result of a lot of googling and hacking while keeping in
> mind "it is the drivers stupid".
>
> 1. Copy the vmdk virtual system disk over to the qemu-kvm/libvirt storage
> pool.  Optionally, the you can convert the file format from vmdk to raw or
> qcow2 but vmdk works fine.
>
> 2. Define a new guest (Fedora or win2k) using virt-manager ... make sure the
> virtual disk under qemu-kvm will be IDE even though all of the original VMware
> guests used SCSI disks ... for the virtual disk, point to the file copied from
> VMware.

virt-v2v should automatically rewrite this stuff for you, at least for 
Linux guests.

> For Fedora guests:
>
> After the new guest is define using virt-manager, bootup the related
> distribution DVD/CD/ISO-image in rescue mode (e.g., Fedora 9 for a Fedora 9
> guest and Fedora 11 for a Fedora 11 guest).  The chroot to the new system and
> run mkinitrd.
>
> I had a case where running mkinitrd did not work (nothing happened or the
> initrd file was far too small).  I do not know what the problem was but I
> "fixed" it by simply re-installing the kernel (rpm -Uvh --force).

Again, virt-v2v should do this for you. It'll also be a bit clever with 
kernel selection.

> For win2k guests:
>
> After the new guest is installed, bootup the win2k installation CD or ISO
> image ... hit enter to select install ...  F8 to agree ... then select "R" to
> repair the existing system ... this "upgrades" the old system and gets all of
> the drivers and system settings corrected ... once the upgrade/installation is
> complete, reboot and re-install the SP4 update.
>
> The above worked for one of my two win2k guests but not for the other one.
> For this second guest, I did something a bit more elaborate:
>
> Running the original win2k guest under VMware, use ntbackup to create a backup
> file of the C: disk and System Settings.  Using virt-manager and qemu-kvm,
> define a new win2k guest and install the system ... update it to SP4 ... then
> run ntbackup to restore the backup file created under VMware.
>
> Now bootup the win2k installation CD/ISO-image and proceed as above in the
> first case.

Thanks for this. Windows guests are on the hitlist, but I haven't 
started looking at the process in detail yet.

> The above processes are fairly simple.
>
> The above processes are highly manual.
>
> The resulting guests work under qemu-kvm.
>
> The above processes should generally work for for other version of Windows,
> other version of Linux, and probably *BSD system (I have no idea about
> Solaris).
>
> While a "v2v" capability would be more than nice, I am worried about all of
> the various systems and about doing the "right thing" for drivers and the
> amount of effort needed to create and then maintain the capability.

You and me both :) My hope is that by being general and relying as much 
as possible on external libraries (augeas being the biggest one here), 
it should mostly tick along. The current process should (I haven't 
tested yet, though) cover RHEL3, RHEL4 and RHEL5 guests. That's a pretty 
wide timeline.

> I was somewhat surprised that I did not find much like the above processes when
> I was googling for information ... maybe I just used the wrong keywords.
>
> While my above descriptions should be adequate for many to replicate what I
> did, I can do a more "cook book" type writeup if there is interest.

Tips always welcome.

Thanks,

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490