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

Re: [Libguestfs] Pseudo code for v2v

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 

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 

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.

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 

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).

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.

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 

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.

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.


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