
--------------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--