I see a lot of threads about v2v pains (mostly from ESX?) I'm interested to see if we can make this simpler/easier. if you have experience with this, please describe the steps you are using (also the source platform), and how you would like to see this make simpler (I'm assuming that would start from somewhere in the webadmin probably). Thanks, Itamar
Hi, I myself have no experience with this so far, but I can quote "blaster" from the ML: Blaster wrote:
I haven’t tried this yet, but if I had to move a VM from ESXi to oVirt this is how I would do it… (actually, this is how I did it with Windows 7 guests…)
Shutdown guest on ESXi (or use GhettoVCB to make a snapshot backup if you don’t want an outtage) NFS copy guest from ESXi server to temp storage somewhere qemu-img convert guest.vmdk -O raw guest.raw Create an oVirt guest with the appropriate OS type Add a disk of the same GB to the guest After oVirt finishes creating the disk, copy the guest.raw file over the disk image oVirt made boot guest and install qemu-agent, ovirt-agent, spice-agent (or better yet, do this before you shutdown on ESXi) remove VMware tools.
The importing and virt2v procedure seems far to complex and error prone to me.
Maybe he can add something :) -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
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. 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
Thanks, Itamar _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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.
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
I suspect in this case what you really should be doing is just copying the source disk image, without using virt-v2v at all. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
On 01/20/2014 11:53 AM, 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.
would we focus on integrating with guestconv? how different from virt-v2v from integration perspective?
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
I suspect in this case what you really should be doing is just copying the source disk image, without using virt-v2v at all.
Rich.
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
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 <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
is guestconv ready for adoption/testing instead of virt-v2v?
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 <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
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
Is there a specification for the ovf/xml/directory structure in the export domain we can use to (semi)manually import an ovirt-compatible machine to an export domain? On Mon, Jan 20, 2014 at 11:39 AM, Matthew Booth <mbooth@redhat.com> wrote:
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 <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
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
On 01/17/2014 10:19 AM, Itamar Heim 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.
if you have experience with this, please describe the steps you are using (also the source platform), and how you would like to see this make simpler (I'm assuming that would start from somewhere in the webadmin probably).
I have spent most of the day trying to do this, and so far have failed. Source: VMWare Server 2.0 disk files (.vmx, .vmdk, etc.), about 10 VMs to transfer. Eliminating all the false starts and detours along the way, this is what I have done so far. * copy my tree of vmware files to local storage; in case I goof up or get fumble-fingered and need to start over clean again. * Set up a 32-bit VM (running Centos 6) because vmware-vdiskmanager only seems to come in 32 bit in the VDSDK package I found to download. I was planning to do this anyway, to run GoogleEarth and other software that doesn't come in pure-64bit format. * run vmware-vdiskmanager -R <file-name.vmdk> to clean up errors that kept next step from happening on about 1/3 of *.vmdk files. * run ovftool <office-5/office-5>.vmx <office-5>.ova to turn .vmx and .vmdk files into .ova files -- long process * BEAT HEAD AGAINST WALL because virt-v2v.x86_64 0.9.1-5.el6_5 from Centos updates doesn't seem to know about .ova files. I was following the instructions in Red_Hat_Enterprise_Virtualization-3.3-Beta-V2V_Guide-en-US.pdf guide, but I figured out that the v2v they are talking about has an "-i ova" option, while the help file for the version I am using does not list ova as an option for -i, and if I try to use it, it tells me that it is an invalid option, and if I leave it off it goes off looking for a qemu///system to attach to. help files for v2v say nothing at all about .ova files. I am wondering where to find a v2v program that knows about .ova files, or else am I going to have to import all my VMWare files to my (non-ovirt) KVM host, and then drag them into ovirt from libvirt? My setup: All hosts running Centos 6.5, fully up to date. 2 hosts engine running in KVM VM, hosted on a non-oVirt KVM host. gluster replica 3 file system across 2 ovirt hosts and on KVM host. Going to bed now to give head some rest. Ted Miller Elkhart, IN, USA
On Sun, Jan 19, 2014 at 7:13 AM, Ted Miller wrote:
* BEAT HEAD AGAINST WALL because virt-v2v.x86_64 0.9.1-5.el6_5 from Centos updates doesn't seem to know about .ova files. I was following the instructions in Red_Hat_Enterprise_Virtualization-3.3-Beta-V2V_Guide-en-US.pdf guide, but I figured out that the v2v they are talking about has an "-i ova" option, while the help file for the version I am using does not list ova as an option for -i, and if I try to use it, it tells me that it is an invalid option, and if I leave it off it goes off looking for a qemu///system to attach to. help files for v2v say nothing at all about .ova files.
I am wondering where to find a v2v program that knows about .ova files, or else am I going to have to import all my VMWare files to my (non-ovirt) KVM host, and then drag them into ovirt from libvirt?
I made a bit of research about this Strange.... I just update a CentOS 6.4 VM to latest 6.5 and see that there (also matching RHEL 6.5 I think) there is indeed as you wrote: virt-v2v-0.9.1-5.el6_5.x86_64 And it seems ova is missing as an option... Instead on a Fedora 19 system with virt-v2v-0.9.0-3.fc19.x86_64 I have it.... So for any reason was it removed in newer packages? It seems also strange to see a Fedora package (even if 19 and not 20) older than a RH EL 6 one ... RHEL 6 version bumped this way skipping 0.9.0: * Wed Jun 12 2013 Matthew Booth <mbooth@redhat.com> - 0.9.1-1 - Rebase to new upstream release * Mon Oct 22 2012 Matthew Booth <mbooth@redhat.com> - 0.8.9-2 while fedora 19 has been currently stopped at * Wed Jul 03 2013 Richard W.M. Jones <rjones@redhat.com> - 0.9.0-3 - Default to using the appliance backend, since in Fedora >= 18 the libvirt backend doesn't support the 'iface' parameter which virt-v2v requires. - Add BR perl(Sys::Syslog), required to run the tests. - Remove some cruft from the spec file. BTW in F20 we do have ova too: virt-v2v-0.9.0-5.fc20.x86_64 and in fact it has the older version... For RHEL 6 I remained here: http://lists.ovirt.org/pipermail/users/2013-May/014457.html ANd no particular virt-v2v package in rhev source repo http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/ For sure the rhev 3.3 beta guide is incorrect at the moment https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtua... because it says " virt-v2v is available on Red Hat Network (RHN) in the Red Hat Enterprise Linux Server (v.6 for 64-bit x86_64) or Red Hat Enterprise Linux Workstation (v.6 for x86_64) channel. Ensure the system is subscribed to the appropriate channel before installing virt-v2v. " and some lines below " 7.1. virt-v2v Parameters The following parameters can be used with virt-v2v: -i input Specifies the input method to obtain the guest for conversion. The default is libvirt. Supported options are: libvirt Guest argument is the name of a libvirt domain. libvirtxml Guest argument is the path to an XML file containing a libvirt domain. ova " Any light to shed on this? Thanks Gianluca
--------------030307010403070106030205 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit I am wide open to suggestions (see discussion at bottom, as usual). On 1/19/2014 5:25 AM, Gianluca Cecchi wrote:
On Sun, Jan 19, 2014 at 7:13 AM, Ted Miller wrote:
* BEAT HEAD AGAINST WALL because virt-v2v.x86_64 0.9.1-5.el6_5 from Centos updates doesn't seem to know about .ova files. I was following the instructions in Red_Hat_Enterprise_Virtualization-3.3-Beta-V2V_Guide-en-US.pdf guide, but I figured out that the v2v they are talking about has an "-i ova" option, while the help file for the version I am using does not list ova as an option for -i, and if I try to use it, it tells me that it is an invalid option, and if I leave it off it goes off looking for a qemu///system to attach to. help files for v2v say nothing at all about .ova files.
I am wondering where to find a v2v program that knows about .ova files, or else am I going to have to import all my VMWare files to my (non-ovirt) KVM host, and then drag them into ovirt from libvirt? I made a bit of research about this
Strange.... I just update a CentOS 6.4 VM to latest 6.5 and see that there (also matching RHEL 6.5 I think) there is indeed as you wrote:
virt-v2v-0.9.1-5.el6_5.x86_64
And it seems ova is missing as an option...
Instead on a Fedora 19 system with virt-v2v-0.9.0-3.fc19.x86_64
I have it.... So for any reason was it removed in newer packages? It seems also strange to see a Fedora package (even if 19 and not 20) older than a RH EL 6 one ...
RHEL 6 version bumped this way skipping 0.9.0: * Wed Jun 12 2013 Matthew Booth <mbooth@redhat.com> - 0.9.1-1 - Rebase to new upstream release
* Mon Oct 22 2012 Matthew Booth <mbooth@redhat.com> - 0.8.9-2
while fedora 19 has been currently stopped at
* Wed Jul 03 2013 Richard W.M. Jones <rjones@redhat.com> - 0.9.0-3 - Default to using the appliance backend, since in Fedora >= 18 the libvirt backend doesn't support the 'iface' parameter which virt-v2v requires. - Add BR perl(Sys::Syslog), required to run the tests. - Remove some cruft from the spec file.
BTW in F20 we do have ova too: virt-v2v-0.9.0-5.fc20.x86_64
and in fact it has the older version...
For RHEL 6 I remained here: http://lists.ovirt.org/pipermail/users/2013-May/014457.html
ANd no particular virt-v2v package in rhev source repo http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/
For sure the rhev 3.3 beta guide is incorrect at the moment
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtua...
because it says " virt-v2v is available on Red Hat Network (RHN) in the Red Hat Enterprise Linux Server (v.6 for 64-bit x86_64) or Red Hat Enterprise Linux Workstation (v.6 for x86_64) channel. Ensure the system is subscribed to the appropriate channel before installing virt-v2v. " and some lines below " 7.1. virt-v2v Parameters The following parameters can be used with virt-v2v: -i input Specifies the input method to obtain the guest for conversion. The default is libvirt. Supported options are: libvirt Guest argument is the name of a libvirt domain. libvirtxml Guest argument is the path to an XML file containing a libvirt domain. ova "
Any light to shed on this?
Thanks Gianluca I think I have some light, but you'd better get out your rose-colored glasses, because that is the only way the light will look good. ;(
I spun up a Fedora 20 64-bit VM (in my brand new oVirt environment) to take advantage of your wonderful discovery. I did a minimal install, then "yum upgrade", then "yum install virt-v2v" brought in 489MB of dependencies! This is what I found (not necessarily in the order I found them). 1. virt-v2v has a missing dependency: perl-Archive-Tar yum install perl-Archive-Tar 2. virt-v2v would error out fairly early in the conversion process: Error extracting archive '/media/VMold/vmware.dud/Fedora13A.ova': /usr/bin/tar: Fedora13A-disk1.vmdk: Wrote only 6144 of 10240 bytes that error went away when I increased VM memory from 1G to 4G (see below). 3. The *.ova files produced by vmware-vdiskmanager build 835872 (downloaded yesterday as part of VDDK 5.0) give the following error messages when running through virt-v2v: Use of uninitialized value $file in hash element at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/VMwareOVASource.pm line 261, <$manifest> line 2. Reading from filehandle failed at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/VMwareOVASource.pm line 271. Though I am not a Perl programmer, I took a look at the code, stuck in some debugging "print" statements, and came to this conclusion: The *.ova files produced by my version of vmware-vdiskmanager contain a "blank" line at the end of the manifest with about 62 spaces in it (nothing else). "sub _verify_manifest" in the file "VMwareOVASource.pm" it throws the error. Since the line is supposed to have and "=" in it, I added "if ($line =~ /=/){ .... } around lines 260-262. It works, though it may be very bad perl. 4. The perl code apparently attempts to extract the ENTIRE virtual disk into memory. After implementing #3, I got errors: line 109 Error extracting archive '/media/VMold/vmware.dud/Fedora13A.ova': /usr/bin/tar: Fedora13A-disk1.vmdk: Wrote only 2048 of 10240 bytes /usr/bin/tar: Exiting with failure status due to previous errors at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/VMwareOVASource.pm line 114. Out of memory! (in cleanup) open3: fork failed: Cannot allocate memory at /usr/share/perl5/vendor_perl/Sys/VirtConvert/ExecHelper.pm line 75. I increased the VM memory from 1G to 4G. Processing a 6-8G virtual disk, I ran "top" and watched the physical memory go from 3+G to 128K, then watched the 1G of swap memory disappear, then got the error message above. 5. I chose one of my smallest .ova files (less than 1G), and it fit into memory, so got past that error. Then I got to the final insult: virt-v2v: RHEV cannot handle volumes of format vmdk At that I threw in the towel. I thought about filing on Bugzilla, but I don't know whether to file 1 bug or 5 or .... To answer your question Gianluca, yes, I think I know why they pulled out the *.ova support -- it doesn't work yet. I checked, but VMWare still seems to be using the *.vmdk naming convention for their disks, so I don't think I can find another name to make virt-v2v happy. For now it looks like I am stuck, unless I bounce everything over to my KVM+virt-manager host, and then import it from there. That makes two days (at well over 8 hours each) that I have spent trying to import my VMs, and so far I have nothing to show for my work. Ted Miller Elkhart, IN --------------030307010403070106030205 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> I am wide open to suggestions (see discussion at bottom, as usual).<br> <br> <div class="moz-cite-prefix">On 1/19/2014 5:25 AM, Gianluca Cecchi wrote:<br> </div> <blockquote cite="mid:CAG2kNCy2PT_V7cidY-hXYMk2asqO1hMWMdT7U0A0BKyVCBXGnw@mail.gmail.com" type="cite"> <pre wrap="">On Sun, Jan 19, 2014 at 7:13 AM, Ted Miller wrote: </pre> <blockquote type="cite"> <pre wrap=""> * BEAT HEAD AGAINST WALL because virt-v2v.x86_64 0.9.1-5.el6_5 from Centos updates doesn't seem to know about .ova files. I was following the instructions in Red_Hat_Enterprise_Virtualization-3.3-Beta-V2V_Guide-en-US.pdf guide, but I figured out that the v2v they are talking about has an "-i ova" option, while the help file for the version I am using does not list ova as an option for -i, and if I try to use it, it tells me that it is an invalid option, and if I leave it off it goes off looking for a qemu///system to attach to. help files for v2v say nothing at all about .ova files. I am wondering where to find a v2v program that knows about .ova files, or else am I going to have to import all my VMWare files to my (non-ovirt) KVM host, and then drag them into ovirt from libvirt? </pre> </blockquote> <pre wrap=""> I made a bit of research about this Strange.... I just update a CentOS 6.4 VM to latest 6.5 and see that there (also matching RHEL 6.5 I think) there is indeed as you wrote: virt-v2v-0.9.1-5.el6_5.x86_64 And it seems ova is missing as an option... Instead on a Fedora 19 system with virt-v2v-0.9.0-3.fc19.x86_64 I have it.... So for any reason was it removed in newer packages? It seems also strange to see a Fedora package (even if 19 and not 20) older than a RH EL 6 one ... RHEL 6 version bumped this way skipping 0.9.0: * Wed Jun 12 2013 Matthew Booth <a class="moz-txt-link-rfc2396E" href="mailto:mbooth@redhat.com"><mbooth@redhat.com></a> - 0.9.1-1 - Rebase to new upstream release * Mon Oct 22 2012 Matthew Booth <a class="moz-txt-link-rfc2396E" href="mailto:mbooth@redhat.com"><mbooth@redhat.com></a> - 0.8.9-2 while fedora 19 has been currently stopped at * Wed Jul 03 2013 Richard W.M. Jones <a class="moz-txt-link-rfc2396E" href="mailto:rjones@redhat.com"><rjones@redhat.com></a> - 0.9.0-3 - Default to using the appliance backend, since in Fedora >= 18 the libvirt backend doesn't support the 'iface' parameter which virt-v2v requires. - Add BR perl(Sys::Syslog), required to run the tests. - Remove some cruft from the spec file. BTW in F20 we do have ova too: virt-v2v-0.9.0-5.fc20.x86_64 and in fact it has the older version... For RHEL 6 I remained here: <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/pipermail/users/2013-May/014457.html">http://lists.ovirt.org/pipermail/users/2013-May/014457.html</a> ANd no particular virt-v2v package in rhev source repo <a class="moz-txt-link-freetext" href="http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/">http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/</a> For sure the rhev 3.3 beta guide is incorrect at the moment <a class="moz-txt-link-freetext" href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html-single/V2V_Guide/index.html#chap-V2V_Guide-Installing_virt_v2v">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.2/html-single/V2V_Guide/index.html#chap-V2V_Guide-Installing_virt_v2v</a> because it says " virt-v2v is available on Red Hat Network (RHN) in the Red Hat Enterprise Linux Server (v.6 for 64-bit x86_64) or Red Hat Enterprise Linux Workstation (v.6 for x86_64) channel. Ensure the system is subscribed to the appropriate channel before installing virt-v2v. " and some lines below " 7.1. virt-v2v Parameters The following parameters can be used with virt-v2v: -i input Specifies the input method to obtain the guest for conversion. The default is libvirt. Supported options are: libvirt Guest argument is the name of a libvirt domain. libvirtxml Guest argument is the path to an XML file containing a libvirt domain. ova " Any light to shed on this? Thanks Gianluca </pre> </blockquote> I think I have some light, but you'd better get out your rose-colored glasses, because that is the only way the light will look good. ;(<br> <br> I spun up a Fedora 20 64-bit VM (in my brand new oVirt environment) to take advantage of your wonderful discovery. I did a minimal install, then "yum upgrade", then "yum install virt-v2v" brought in 489MB of dependencies! This is what I found (not necessarily in the order I found them).<br> <br> 1. virt-v2v has a missing dependency: perl-Archive-Tar<br> yum install perl-Archive-Tar<br> <br> 2. virt-v2v would error out fairly early in the conversion process:<br> <blockquote>Error extracting archive '/media/VMold/vmware.dud/Fedora13A.ova': /usr/bin/tar: Fedora13A-disk1.vmdk: Wrote only 6144 of 10240 bytes<br> </blockquote> that error went away when I increased VM memory from 1G to 4G (see below).<br> <br> 3. The *.ova files produced by vmware-vdiskmanager build 835872 (downloaded yesterday as part of VDDK 5.0) give the following error messages when running through virt-v2v:<br> <br> <blockquote>Use of uninitialized value $file in hash element at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/VMwareOVASource.pm line 261, <$manifest> line 2.<br> Reading from filehandle failed at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/VMwareOVASource.pm line 271.<br> </blockquote> Though I am not a Perl programmer, I took a look at the code, stuck in some debugging "print" statements, and came to this conclusion:<br> <blockquote>The *.ova files produced by my version of vmware-vdiskmanager contain a "blank" line at the end of the manifest with about 62 spaces in it (nothing else). "sub _verify_manifest" in the file "VMwareOVASource.pm" it throws the error.<br> <br> Since the line is supposed to have and "=" in it, I added "if ($line =~ /=/){ .... } around lines 260-262. It works, though it may be very bad perl.<br> <br> </blockquote> 4. The perl code apparently attempts to extract the ENTIRE virtual disk into memory. After implementing #3, I got errors:<br> <blockquote>line 109 Error extracting archive '/media/VMold/vmware.dud/Fedora13A.ova': /usr/bin/tar: Fedora13A-disk1.vmdk: Wrote only 2048 of 10240 bytes <br> /usr/bin/tar: Exiting with failure status due to previous errors <br> at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/VMwareOVASource.pm line 114. <br> Out of memory! <br> (in cleanup) open3: fork failed: Cannot allocate memory at /usr/share/perl5/vendor_perl/Sys/VirtConvert/ExecHelper.pm line 75.<br> <br> I increased the VM memory from 1G to 4G. Processing a 6-8G virtual disk, I ran "top" and watched the physical memory go from 3+G to 128K, then watched the 1G of swap memory disappear, then got the error message above.<br> </blockquote> 5. I chose one of my smallest .ova files (less than 1G), and it fit into memory, so got past that error. Then I got to the final insult:<br> <blockquote>virt-v2v: RHEV cannot handle volumes of format vmdk<br> </blockquote> At that I threw in the towel.<br> <br> I thought about filing on Bugzilla, but I don't know whether to file 1 bug or 5 or ....<br> <br> To answer your question Gianluca, yes, I think I know why they pulled out the *.ova support -- it doesn't work yet.<br> <br> I checked, but VMWare still seems to be using the *.vmdk naming convention for their disks, so I don't think I can find another name to make virt-v2v happy. For now it looks like I am stuck, unless I bounce everything over to my KVM+virt-manager host, and then import it from there.<br> <br> That makes two days (at well over 8 hours each) that I have spent trying to import my VMs, and so far I have nothing to show for my work.<br> <br> Ted Miller<br> Elkhart, IN<br> <br> </body> </html> --------------030307010403070106030205--
https://rhn.redhat.com/errata/RHBA-2013-1749.html """ This update fixes the following bug: * An update to virt-v2v included upstream support for the import of OVA images exported by VMware servers. Unfortunately, testing has shown that VMDK images created by recent versions of VMware ESX cannot be reliably supported, thus this feature has been withdrawn. (BZ#1028983) Users of virt-v2v are advised to upgrade to this updated package, which fixes this bug. """
FWIW, importing directly from an ESX server still works: virt-v2v-host: - RHEL/CentOS 6.5 physical host ( virt-v2v uses qemu-kvm = extra++ slow on a VM) - Packages: virt-v2v-0.9.1-5.el6_5.x86_64 libguestfs-winsupport-1.0-7.el6.x86_64 libguestfs-tools-c-1.20.11-2.el6.x86_64 libguestfs-tools-1.20.11-2.el6.x86_64 libguestfs-1.20.11-2.el6.x86_64 virtio-win-1.6.7-2.el6.noarch ( RHEL only? ) - network acces to: oVirt export domain (NFS) esx host(s) to import from (HTTPS) - virt-v2v has to run as root to mount the oVirt NFS export domain - Edit ~/.netrc and add a line for the esx host(s) to import from (change the <> parts): machine <esx.host.fqdn> login <esxuser> password <esxpassword> - Fix permissions on netrc file: chmod 600 ~/.netrc - Run virt-v2v ( again: change the <> parts, ?no_verify=1 is needed when esx uses self signed certs) LIBGUESTFS_DEBUG=1 virt-v2v -ic esx://<esx.host.fqdn>/?no_verify=1 -o rhev -os <rhev.export.domain.host:/var/exports/export_domain> --network <target_network_name> <vmname> Conversion can take quite some time after the disk copy, especially when virt-v2v removes the vmware tools. Running on a physical host (or using nested virtualization) helps. On Mon, Jan 20, 2014 at 8:59 AM, Sander Grendelman <sander@grendelman.com> wrote:
https://rhn.redhat.com/errata/RHBA-2013-1749.html
""" This update fixes the following bug:
* An update to virt-v2v included upstream support for the import of OVA images exported by VMware servers. Unfortunately, testing has shown that VMDK images created by recent versions of VMware ESX cannot be reliably supported, thus this feature has been withdrawn. (BZ#1028983)
Users of virt-v2v are advised to upgrade to this updated package, which fixes this bug. """
Unfortunately I have not ESX or ESXi server. These VMs were running on a VMWare Server. Ted On 1/20/2014 4:23 AM, Sander Grendelman wrote:
FWIW, importing directly from an ESX server still works:
virt-v2v-host: - RHEL/CentOS 6.5 physical host ( virt-v2v uses qemu-kvm = extra++ slow on a VM) - Packages: virt-v2v-0.9.1-5.el6_5.x86_64 libguestfs-winsupport-1.0-7.el6.x86_64 libguestfs-tools-c-1.20.11-2.el6.x86_64 libguestfs-tools-1.20.11-2.el6.x86_64 libguestfs-1.20.11-2.el6.x86_64 virtio-win-1.6.7-2.el6.noarch ( RHEL only? ) - network acces to: oVirt export domain (NFS) esx host(s) to import from (HTTPS) - virt-v2v has to run as root to mount the oVirt NFS export domain - Edit ~/.netrc and add a line for the esx host(s) to import from (change the <> parts): machine <esx.host.fqdn> login <esxuser> password <esxpassword> - Fix permissions on netrc file: chmod 600 ~/.netrc - Run virt-v2v ( again: change the <> parts, ?no_verify=1 is needed when esx uses self signed certs) LIBGUESTFS_DEBUG=1 virt-v2v -ic esx://<esx.host.fqdn>/?no_verify=1 -o rhev -os <rhev.export.domain.host:/var/exports/export_domain> --network <target_network_name> <vmname>
Conversion can take quite some time after the disk copy, especially when virt-v2v removes the vmware tools. Running on a physical host (or using nested virtualization) helps.
On Mon, Jan 20, 2014 at 8:59 AM, Sander Grendelman <sander@grendelman.com> wrote:
https://rhn.redhat.com/errata/RHBA-2013-1749.html
""" This update fixes the following bug:
* An update to virt-v2v included upstream support for the import of OVA images exported by VMware servers. Unfortunately, testing has shown that VMDK images created by recent versions of VMware ESX cannot be reliably supported, thus this feature has been withdrawn. (BZ#1028983)
Users of virt-v2v are advised to upgrade to this updated package, which fixes this bug. """
-- "He is no fool who gives what he cannot keep, to gain what he cannot lose." - - Jim Elliot For more information about Jim Elliot and his unusual life, see http://www.christianliteratureandliving.com/march2003/carolyn.html. Ted Miller Design Engineer HCJB Global Technology Center 2830 South 17th St Elkhart, IN 46517 574--970-4272 my desk 574--970-4252 receptionist
This is a multi-part message in MIME format. ------=_NextPartTM-000-ccd9a7a9-9ae2-40a0-a795-247b884365d5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Von: users-bounces@ovirt.org [users-bounces@ovirt.org]" im Auftrag v= on "Itamar Heim [iheim@redhat.com]=0A= > Gesendet: Freitag, 17. Januar 2014 16:19=0A= > An: users >> "users@ovirt.org"=0A= > Betreff: [Users] Making v2v easier?=0A= > =0A= > I see a lot of threads about v2v pains (mostly from ESX?)=0A= >=0A= > I'm interested to see if we can make this simpler/easier.=0A= > =0A= > if you have experience with this, please describe the steps you are=0A= > using (also the source platform), and how you would like to see this=0A= > make simpler (I'm assuming that would start from somewhere in the=0A= > webadmin probably).=0A= > =0A= > Thanks,=0A= > Itamar=0A= =0A= Hello,=0A= =0A= for me virt-v2v will be a one-timer until everything is migrated=0A= into OVirt. If you had hard times to arrange everything and know=0A= how to deal with it, the tool works quite well. Nevertheless for=0A= for new users this can be very frustrating. =0A= =0A= The two most annoying things are for me:=0A= =0A= - Migration is sequential and slow. We have a lot of big SAP systems=0A= with 250GB++. The infrastructure is backed by a 10G IPoIB network =0A= that can easily copy files between NFS server at sustained speed of =0A= 500MB/s. virt-v2v cannot go beyond 40MB/s and thus about 2 hours=0A= to migrate a machine. I understand that the process involves a "long" =0A= chain ESXNFS->ESX->virt-v2v->OVirtNFS. Maybe one should think =0A= of providing a parametrization to copy multiple disk images at the =0A= same time. =0A= =0A= - Even worse is to wait 2 hours for the migration to finish and getting=0A= afterwards errors about missing entries in virt-v2v.db or problems=0A= during mount of the VM filesystems. Maybe the step or at least a check=0A= could be issued after the migration of the (small) OS/boot disk.=0A= =0A= Markus=0A= =0A= ------=_NextPartTM-000-ccd9a7a9-9ae2-40a0-a795-247b884365d5 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-ccd9a7a9-9ae2-40a0-a795-247b884365d5--
Hi, I did some migrations with v2v and p2v (most of them to RHEV, but there's not really a difference between RHEV and oVirt). Sources where VMware ESX, KVM-servers (hosted on RHEL and Debian), Xen (hosted on an old SUSE server) and physical machines for p2v. The servers I used to run virt-v2v from where RHEL 6.3-6.5 - didn't test Fedora yet. All sources worked fine except the old SUSE server (had some connection errors to libvirt but didn't analyzed it further, as we decided to not migrate this vm and instead create a new one and migrate the data). One of the most common errors when it comes to migration from VMware is that users connect to vCenter instead of the ESX host directly (I also did this on my first test, as I expected to be redirected to the correct hypervisor by vCenter). In the past there were big issues when migration machines from VMware with installed VMware guest tools. You have to uninstall guest tools _BEFORE_ you migrate the vm. If not, VMware guest tools interfere with RHEV guest tools - meaning that RHEV guest tools want work properly and VMware guest tools refuse to uninstall if the machine is not running on VMware platform. This is definitely more an issue of VMware guest tools then oVirt/RHEV, but it can be a pitfall in the migration process. virt-v2v is doing a great job for Windows and RHEL servers by installing the virtio drivers and setting disks and nics to virtio in ovf-file. For other Linux distributions I edited ovf file manually to have the correct type. Debian and Ubuntu worked fine when changing disk and nic type to virtio (as they use UUIDs in /etc/fstab and have virtio support in initrd), openSUSE nics work fine with virtio, disk don't, btw :) It would be an improvement if virt-v2v could prepare Debian/Ubuntu and openSUSE/SLES for oVirt/RHEV in the same way as it does with RHEL and Windows. Furthermore it would be great if I could change settings during import (e.g. NIC of disk type, memory, cpu, display type,...). One thing which is a big pain is, that virt-v2v copies the whole disk to the export domain and validates it afterwards. If the validation fails, the disk gets removed from the export domain. When migration big disks (> 100GB) this is a real pain. What are the improvements I would like to see? First of all, I would love to do imports from within the webadmin portal. At the moment I have to use virt-v2v, switch to Storage tab in webadmin afterwards to import the vm and change it's settings (if required) in vm tab. One tab for all these actions would be a huge improvements. Especially if Windows admins or non-hardcore-commandline-admins are doing the migration this would help a lot. When adding virt-v2v to webadmin I suggest to add a big red notice that users shall uninstall VMware guest tools before migration the vm when selection ESX as an input source and also mention to use the hypervisor instead of the vCenter server. As written above I would also love to see support for multiple Linux distributions in virt-v2v (and p2v, too). Last, verifying the disk before copying would be really great (don't know if this is possible - if not an option in virt-v2v to not remove the disk would help as maybe the disk can be imported but only virt-v2v fails). I hope I could explain my experience and wishes with/for virt-v2v good enough. -- Best Regards René Koch Senior Solution Architect ============================================ LIS-Linuxland GmbH Brünner Straße 163, A-1210 Vienna Phone: +43 1 236 91 60 Mobile: +43 660 / 512 21 31 E-Mail: rkoch@linuxland.at ============================================ On Fri, 2014-01-17 at 17:19 +0200, Itamar Heim 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.
if you have experience with this, please describe the steps you are using (also the source platform), and how you would like to see this make simpler (I'm assuming that would start from somewhere in the webadmin probably).
Thanks, Itamar _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (9)
-
Gianluca Cecchi -
Itamar Heim -
Markus Stockhausen -
Matthew Booth -
René Koch -
Richard W.M. Jones -
Sander Grendelman -
Sven Kieske -
Ted Miller