On 20/01/14 10:36, Itamar Heim wrote: > 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?
No, it's not even functionally complete, yet. We're planning to get that sorted soon. 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 _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
