VMware/qemu-kvm-?? migration

[Gene Czarcinski]

Is this the mailing list to ask about issues/problems migrating VMware guests
to run on qemu-kvm, etc.?

If not, please point me to an appropriate mailing list?

Gene

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Cole Robinson]

Gene Czarcinski wrote:
> Is this the mailing list to ask about issues/problems migrating VMware guests
> to run on qemu-kvm, etc.?
>
> If not, please point me to an appropriate mailing list?
>

There isn't a mailing list dedicated to V2V, but this is as good as any. The
virtinst package comes with a tool virt-convert which enables going from vmx
config files to virt-image format (though it hasn't received a lot of
testing). Rich Jones (cc'd) is also working on V2V tools.

So ask away, people will help if they can.

- Cole

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Richard W.M. Jones-2]

On Tue, Jul 14, 2009 at 05:39:45PM -0400, Gene Czarcinski wrote:
> Is this the mailing list to ask about issues/problems migrating VMware guests
> to run on qemu-kvm, etc.?
>
> If not, please point me to an appropriate mailing list?

Yes this is good.

I've actually been playing with manual migration of guests from VMWare
recently.  This is what I do:

(1) Export the guest in OVF format (File -> Export -> Export OVF Template)

(2) Convert the *.vmdk file (disk image) into a raw file:

  qemu-img convert -f vmdk -O raw *.vmdk image.raw

(3) Boot the raw image using libvirt.  I create a libvirt
configuration by hand, but IIRC there is now a tool which does this
automatically.

Some problems: VMWare tools should be uninstalled from the original
guest.  Virtio drivers should be installed in the new guest (this is
very complex to do for existing guests, which is why we are writing
the virt-v2v tool to automate it).

The virt-v2v tool will be ready in a few weeks.  You can follow
progress on it here:

http://libguestfs.org

Rich.

--
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Poul Kristensen-2]

How about the opposite method?

This because of the need to migrate old machines to virtual machines in
Vmware until RHEL5.4 Beta has been released as a stable virtual(kvm)
platform.

TIA

Poul

ons, 15 07 2009 kl. 08:50 +0100, skrev Richard W.M. Jones:

> On Tue, Jul 14, 2009 at 05:39:45PM -0400, Gene Czarcinski wrote:
> > Is this the mailing list to ask about issues/problems migrating VMware guests
> > to run on qemu-kvm, etc.?
> >
> > If not, please point me to an appropriate mailing list?
>
> Yes this is good.
>
> I've actually been playing with manual migration of guests from VMWare
> recently.  This is what I do:
>
> (1) Export the guest in OVF format (File -> Export -> Export OVF Template)
>
> (2) Convert the *.vmdk file (disk image) into a raw file:
>
>   qemu-img convert -f vmdk -O raw *.vmdk image.raw
>
> (3) Boot the raw image using libvirt.  I create a libvirt
> configuration by hand, but IIRC there is now a tool which does this
> automatically.
>
> Some problems: VMWare tools should be uninstalled from the original
> guest.  Virtio drivers should be installed in the new guest (this is
> very complex to do for existing guests, which is why we are writing
> the virt-v2v tool to automate it).
>
> The virt-v2v tool will be ready in a few weeks.  You can follow
> progress on it here:
>
> http://libguestfs.org
>
> Rich.
>

--

Poul Kristensen
IT-Konsulent / IT-Consultant


Det Kongelige Bibliotek | The Royal Library IT-afdelingen | Information Technology

P.O. Box 2149 | DK-1016 København K
tel [phone] | pok@... | www.kb.dk

 
Besøgsadresse | Visiting address | Søren Kierkegaards Plads 1 Leveringsadresse
Delivery address | Christians Brygge 8 | 1219 København K

EAN 5798 000 79 52 97 | Bank 8109 101111-4 | CVR 28 98 88 42 IBAN
DK9881090001011114 | Swiftcode JYBADKKK

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Gene Czarcinski]

On Wednesday 15 July 2009 03:50:32 Richard W.M. Jones wrote:

> On Tue, Jul 14, 2009 at 05:39:45PM -0400, Gene Czarcinski wrote:
> > Is this the mailing list to ask about issues/problems migrating VMware
> > guests to run on qemu-kvm, etc.?
> >
> > If not, please point me to an appropriate mailing list?
>
> Yes this is good.
>
> I've actually been playing with manual migration of guests from VMWare
> recently.  This is what I do:
>
> (1) Export the guest in OVF format (File -> Export -> Export OVF Template)
>
> (2) Convert the *.vmdk file (disk image) into a raw file:
>
>   qemu-img convert -f vmdk -O raw *.vmdk image.raw
>
> (3) Boot the raw image using libvirt.  I create a libvirt
> configuration by hand, but IIRC there is now a tool which does this
> automatically.

Thanks ... I am going to give the above a try.

Before I go too far down this path only to discover that it still will not
work for me, here is some of what I have done (everything was done on a Fedora
11 host with preview updates installed and the host processor is an AMD Phenom
II 940):

1. I have created (under qemu-kvm) a simple F11 guest on a SCSI adapter (qcow2
format) (I had to do some dancing to use the SCSI adapter) .. this
installs/runs fine.

2. I then created (under qemu-kvm) a simple F11 guest with an IDE adapter for
the disk image.  Before booting, I replaced the disk image with a copy of the
disk image from the SCSI install (1) ... this also runs fine ... qemu-kvm does
not seem to care about the image that much if it was created under qemu-kvm.

3. I created a simple (no LVM) F11 guest with IDE interface under VMware
Workstation 6.5.2 where I specified "Workstation 4" comparability so the the
vmdk file was HWversion=3.  Under qemu-kvm, I created a simple guest with IDE
for the disk interface and used the vmdk file I created under VMware ... this
booted up and ran fine!

Now the problem:

4.  Under qemu-kvm I created a simple Fedora guest definition.  I then copied
and used a VMware F9 guest with a vmdk file which is HWversion=4 and was
created under VMware on a SCSI interface disk.  To make matters even worse,
this VMware guest uses the "root" (/) partition on a LVM logical volume.  Boot
the guest up on qemu-kvm and it immediately crashes because it cannot find
"root" or see the logical volumes.

5.  I booted up the F9 distribution DVD in rescue mode and the above vmdk disk
attached ... the disk was "visible" and I could chroot into it.

6.  I examined the disks with guestfish and that worked too.

Should this stuff work?  What am I missing?

BTW, attempting to boot a vmdk disk which is other than HWversion=3, results
in the same problem although qemu-kvm, etc. does not give any error.

BTW, I have used guestfish with various vmdk files and handles them all even if
they are other than HWversion=3 or HWversion=4.

Gene

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Richard W.M. Jones-2]

On Wed, Jul 15, 2009 at 08:53:32AM -0400, Gene Czarcinski wrote:
> 4.  Under qemu-kvm I created a simple Fedora guest definition.  I
> then copied and used a VMware F9 guest with a vmdk file which is
> HWversion=4 and was created under VMware on a SCSI interface disk.
> To make matters even worse, this VMware guest uses the "root" (/)
> partition on a LVM logical volume.  Boot the guest up on qemu-kvm
> and it immediately crashes because it cannot find "root" or see the
> logical volumes.

I'm not really familiar with HWversion in VMWare.  We just support
whatever qemu / qemu-img supports, so I suggest trying to do a
conversion using qemu-img (see my previous posting).

Rich.

--
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Richard W.M. Jones-2]

On Thu, Jul 16, 2009 at 03:16:45PM +0100, Richard W.M. Jones wrote:

> On Wed, Jul 15, 2009 at 08:53:32AM -0400, Gene Czarcinski wrote:
> > 4.  Under qemu-kvm I created a simple Fedora guest definition.  I
> > then copied and used a VMware F9 guest with a vmdk file which is
> > HWversion=4 and was created under VMware on a SCSI interface disk.
> > To make matters even worse, this VMware guest uses the "root" (/)
> > partition on a LVM logical volume.  Boot the guest up on qemu-kvm
> > and it immediately crashes because it cannot find "root" or see the
> > logical volumes.
>
> I'm not really familiar with HWversion in VMWare.  We just support
> whatever qemu / qemu-img supports, so I suggest trying to do a
> conversion using qemu-img (see my previous posting).

Another suggestion (from Matt Booth who's not subscribed to this
list):

Is the right SCSI driver available in the initrd?  You should be able
to find out what driver(s) are in the guest's initrd using
virt-inspector.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Gene Czarcinski]

On Thursday 16 July 2009 10:39:02 Richard W.M. Jones wrote:

> On Thu, Jul 16, 2009 at 03:16:45PM +0100, Richard W.M. Jones wrote:
> > On Wed, Jul 15, 2009 at 08:53:32AM -0400, Gene Czarcinski wrote:
> > > 4.  Under qemu-kvm I created a simple Fedora guest definition.  I
> > > then copied and used a VMware F9 guest with a vmdk file which is
> > > HWversion=4 and was created under VMware on a SCSI interface disk.
> > > To make matters even worse, this VMware guest uses the "root" (/)
> > > partition on a LVM logical volume.  Boot the guest up on qemu-kvm
> > > and it immediately crashes because it cannot find "root" or see the
> > > logical volumes.
> >
> > I'm not really familiar with HWversion in VMWare.  We just support
> > whatever qemu / qemu-img supports, so I suggest trying to do a
> > conversion using qemu-img (see my previous posting).
>
> Another suggestion (from Matt Booth who's not subscribed to this
> list):
>
> Is the right SCSI driver available in the initrd?  You should be able
> to find out what driver(s) are in the guest's initrd using
> virt-inspector.

Light bulb lights above head!

Yup, yup ... thank you very much!  The problem is that the needed drivers are
not in the initrd file.

Now I know what the problem is but "fixing" it will need some thought.

I knew it was something stupid on my part.

Thanks again.

Gene

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Gene Czarcinski]

On Thursday 16 July 2009 15:42:41 Gene Czarcinski wrote:

> > Is the right SCSI driver available in the initrd?  You should be able
> > to find out what driver(s) are in the guest's initrd using
> > virt-inspector.
>
> Light bulb lights above head!
>
> Yup, yup ... thank you very much!  The problem is that the needed drivers
> are not in the initrd file.
>
> Now I know what the problem is but "fixing" it will need some thought.

OK, I got a "fix" that worked and the problem definitely was that the initrd file
did not contain the right/needed drivers for the new hardware configuration.

First:  The guest is an i386 F9 system.  Although the VMware guest used a SCSI
adapter, I used a IDE adapter on qemu-kvm.  I did not bother converting the
file but just used a copy of the vmdk file.

To get a good initrd file:  Bootup the F9 i386 distribution DVD and run rescue
mode.  Use scp to copy the "current" kernel and firmware rpms (the guest was
not up-to-date).  chroot the the guest's disks.  Install the kernel and
firmware rpms.  Reboot to the updated guests ... everything works!  Success!

Before installing a new kernel rpm to get the updated initrd file, I tried just
running mkinitrd for the rescue/chroot mode but this did not appear to
generate a correct initrd file (it did not work).  I used:
   mkinitrd  /boot/initrd______.img  <kernel_version>

Whatever "dance" installing a kernel does to create a good initrd file, just
running mkinitrd is not it.  Any suggestions?  It would be nice to just run
mkinitrd to fix things.

Q: Does virt-p2v fixup initrd as part of its process? [No, I have not tried it
yet]

Since guestfish gives me access to the filesystems on a virtual disk, it would
be nice if I could (easily) update the initrd to have the right drivers.  This
may not be practical since guestfish does not know what the guest's hardware
configuration looks like ... running rescue-mod and chroot may be the best that
can be used to fix things.

Once I get the process down for migrating a Fedora guest from VMware to qemu-
kvm, I will then look into the far bigger challenge of (ugh) Windows.

Gene

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Joey Boggs-2]

Gene Czarcinski wrote:

> On Thursday 16 July 2009 15:42:41 Gene Czarcinski wrote:
>  
>>> Is the right SCSI driver available in the initrd?  You should be able
>>> to find out what driver(s) are in the guest's initrd using
>>> virt-inspector.
>>>      
>> Light bulb lights above head!
>>
>> Yup, yup ... thank you very much!  The problem is that the needed drivers
>> are not in the initrd file.
>>
>> Now I know what the problem is but "fixing" it will need some thought.
>>    
>
> OK, I got a "fix" that worked and the problem definitely was that the initrd file
> did not contain the right/needed drivers for the new hardware configuration.
>
> First:  The guest is an i386 F9 system.  Although the VMware guest used a SCSI
> adapter, I used a IDE adapter on qemu-kvm.  I did not bother converting the
> file but just used a copy of the vmdk file.
>
> To get a good initrd file:  Bootup the F9 i386 distribution DVD and run rescue
> mode.  Use scp to copy the "current" kernel and firmware rpms (the guest was
> not up-to-date).  chroot the the guest's disks.  Install the kernel and
> firmware rpms.  Reboot to the updated guests ... everything works!  Success!
>
> Before installing a new kernel rpm to get the updated initrd file, I tried just
> running mkinitrd for the rescue/chroot mode but this did not appear to
> generate a correct initrd file (it did not work).  I used:
>    mkinitrd  /boot/initrd______.img  <kernel_version>
>
> Whatever "dance" installing a kernel does to create a good initrd file, just
> running mkinitrd is not it.  Any suggestions?  It would be nice to just run
> mkinitrd to fix things.
>
>  

I used to do this manually over a year ago, updating /etc/modprobe.conf
and then running mkinitrd should do the trick.

> Q: Does virt-p2v fixup initrd as part of its process? [No, I have not tried it
> yet]
>
> Since guestfish gives me access to the filesystems on a virtual disk, it would
> be nice if I could (easily) update the initrd to have the right drivers.  This
> may not be practical since guestfish does not know what the guest's hardware
> configuration looks like ... running rescue-mod and chroot may be the best that
> can be used to fix things.
>
> Once I get the process down for migrating a Fedora guest from VMware to qemu-
> kvm, I will then look into the far bigger challenge of (ugh) Windows.
>
> Gene
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools@...
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>  

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Gene Czarcinski]

On Friday 17 July 2009 08:59:23 Joey Boggs wrote:
> > Whatever "dance" installing a kernel does to create a good initrd file,
> > just running mkinitrd is not it.  Any suggestions?  It would be nice to
> > just run mkinitrd to fix things.
> >
> >  
>
> I used to do this manually over a year ago, updating /etc/modprobe.conf
> and then running mkinitrd should do the trick.

My problem is that it did not work for me.  The resulting initrd file was about
a tenth of the size of the original initrd file plus, when booted, it did not
work.  On the other hand, installing a new kernel resulted in a slightly
smaller initrd file and it did work.

Gene

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools