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 <iheim@redhat.com> 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 -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490