On 01/20/2014 12:18 PM, Matthew Booth wrote:
On 20/01/14 09:53, Richard W.M. Jones wrote:
On Fri, Jan 17, 2014 at 05:06:13PM +0100, Sander Grendelman wrote:
On Fri, Jan 17, 2014 at 4:19 PM, Itamar Heim <[email protected]> wrote:
I see a lot of threads about v2v pains (mostly from ESX?)
I'm interested to see if we can make this simpler/easier.
hear hear!
if you have experience with this, please describe the steps you are using
(also the source platform),
Sources:
- Existing KVM (virt-manager/libvirt) platform
- ESX
- ova/ovf templates from several sources
Methods:
- KVM:
virt-v2v with libvirtxml option, works reasonably well, most issues
are with windows guests where virt-v2v needs libguestfs-winsupport and
virtio-win (RHEL only)
- ESX:
virt-v2v which works reasonably well _if_ the right packages
(libguestfs-winsupport virtio-win) are installed.
virt-v2v can be used directly from ESX/ESX host (configure .netrc
first) but this is quite slow
another option is to export the VM as an OVA and then import it with virt-v2v
- ova/ovf templates:
hit and miss with virt-v2v, especially if they contain something
that is not a regular windows/linux guest.
Another option is to do a direct copy of the disks on a pre-created
VM, clumsy.
and how you would like to see this make simpler
(I'm assuming that would start from somewhere in the webadmin probably).
Webadmin would be nice, but better behaviour from existing tools would be
a nice start too.
For example: the flow with virt-v2v is
1) Analyze source, look for disks
2) Convert/copy disks to ovirt export domain
3) Try to add virtio stuff to the copied disks on the export domain
If step 3 fails ( which happens a LOT), the copied disks are removed.
This is very frustrating if you just waited a couple of hours for a large
VM (e.g. 200GB) to be copied :(
Some kind of graceful abort/resume would be VERY welcome.
The above basically come down to the fact that currently virt-v2v does
the copy first and the v2v step second. It was my understanding
[Matt?] that guestconv is supposed to do the v2v step first followed
by the copy, which should solve all of that.
guestconv doesn't address this problem directly. We need smarter copying
for that :/
Another issue with virt-v2v is that it _always_ tries to add virtio
drivers. I have a virtual appliance that contains some kind of
proprietary embedded OS: adding drivers will always fail, give me
some option to override that and configure simple ide / e1000
hardware for the VM
guestconv *does* address that.
I suspect in this case what you really should be doing is just copying
the source disk image, without using virt-v2v at all.
Matt
is guestconv ready for adoption/testing instead of virt-v2v?
_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
