[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] Pseudo code for v2v



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]