672831 – virt-v2v should use core libguestfs inspection

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 672831 - virt-v2v should use core libguestfs inspection

Summary: virt-v2v should use core libguestfs inspection

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	virt-v2v
Sub Component:
Version:	6.1
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Matthew Booth
QA Contact:	Virtualization Bugs
Docs Contact:
URL:
Whiteboard:
Depends On:	672827
Blocks:	666578 672824 673066 677870 682980
TreeView+	depends on / blocked

Reported:	2011-01-26 14:53 UTC by Matthew Booth
Modified:	2011-12-06 15:08 UTC (History)
CC List:	4 users (show)
Fixed In Version:	virt-v2v-0.8.2-1.el6
Doc Type:	Bug Fix
Doc Text:
Clone Of:	672827
Clones:	732637 (view as bug list)
Environment:
Last Closed:	2011-12-06 15:08:00 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)
Check virt-v2v code with patch (14.90 KB, application/octet-stream) 2011-08-23 10:18 UTC, yuping zhang	no flags	Details
View All

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2011:1615	0	normal	SHIPPED_LIVE	Low: virt-v2v security and bug fix update	2011-12-06 00:51:05 UTC

Description Matthew Booth 2011-01-26 14:53:27 UTC

+++ This bug was initially created as a clone of Bug #672827 +++

The Perl inspection code in libguestfs (ie. Sys::Guestfs::Lib)
is obsolete and deprecated upstream.

Either: virt-v2v should move all this code into its own codebase
and maintain it there.

Or: [better] virt-v2v should be changed to use the core inspection
API.  See:
http://libguestfs.org/guestfs.3.html#inspection

+++ This bug was initially created as a clone of Bug #672824 +++

Description of problem:

https://www.redhat.com/archives/virt-tools-list/2011-January/thread.html#00058

If a Windows <= 2003 guest has the Windows Recovery Console
installed, then the perl inspection code detects this as an
extra instance of Windows.  Since virt-v2v does not work with
multiboot operating systems, the conversion fails with the
error:

 virt-v2v: multiboot operating systems are not supported by virt-v2v

Version-Release number of selected component (if applicable):

0.7.1(?)

How reproducible:

Always.

Steps to Reproduce:
1. Install Windows Recovery Console to the guest hard disk.
2. Try virt-v2v conversion.
3.
  
Actual results:

virt-v2v/libguestfs thinks the guest is multiboot and fails.

Expected results:

virt-v2v should ignore the Recovery Console partition and
convert only the main partition.  It should probably warn that
the Recovery Console has not been converted and must be
reinstalled.

Additional info:

Comment 2 Richard W.M. Jones 2011-04-13 20:36:22 UTC

A patch for this has been committed upstream:
http://git.fedorahosted.org/git/?p=virt-v2v.git;a=commitdiff;h=1454043d0bd335ab0220c9b1957e757f54d1309b

Comment 5 yuping zhang 2011-08-23 07:14:12 UTC

1.Install winxp-32b and win2k3-64b on two partitions
2.First convert Windows XP:
#  virt-v2v -ic qemu+ssh://10.66.72.122/system -os default -b rhevm winxp-win2k3
winxp-win2k3.img: 100% [==============================================================================================================]D 0h05m35s

***
Dual- or multi-boot operating system detected. Choose the root filesystem
that contains the main operating system from the list below:

 [1] /dev/sda1 (Microsoft Windows XP)
 [2] /dev/sda5 (Microsoft Windows Server 2003 R2)

Enter number between 1 and 2: 1
virt-v2v: WARNING: There is no virtio net driver available in the directory specified for this version of Windows. The guest will be configured with a rtl8139 network adapter, but no driver will be installed for it. If the rtl8139 driver is not already installed in the guest, you must install it manually after conversion.
virt-v2v: winxp-win2k3 configured with virtio storage only.

3.Boot the guest
  Boot from winxp: boot successfully
  Boot from win2k3: boot fail with message "Windows could not start because of a general computer hardware configuration problem.Attempting to load an x64 operation system,however this CPU is not compatible with x64 mode.Please install an x86 32-bit operation system"

4.Then convert Windows 2003:
 #  virt-v2v -ic qemu+ssh://10.66.72.122/system -os default -b rhevm winxp-win2k3
winxp-win2k3.img: 100% [==============================================================================================================]D 0h06m30s

***
Dual- or multi-boot operating system detected. Choose the root filesystem
that contains the main operating system from the list below:

 [1] /dev/sda1 (Microsoft Windows XP)
 [2] /dev/sda5 (Microsoft Windows Server 2003 R2)

Enter number between 1 and 2: 2
virt-v2v: WARNING: The connected hypervisor does not support feature pae.
virt-v2v: winxp-win2k3 configured with virtio drivers.

5.
Boot the guest
  Boot from winxp: BSOD when boot from winxp.
  Boot from win2k3: Boot successfully.

Firstly,the step 2 and 4,for windows,I think it's more better to use "C:" or "D:"  than "/dev/sda1" "/dev/sda5"
Secondly,the step 5,after boot from winxp,I think it's better not BSOD,or we can document it.

As above,I changed the bug status to ASSIGNED.

Comment 6 yuping zhang 2011-08-23 07:20:26 UTC

Add the packages version:
virt-v2v-0.8.3-1.el6.x86_64
libvirt-0.9.4-4.el6.x86_64
libguestfs-1.7.17-26.el6.x86_64

 (In reply to comment #5)
> 1.Install winxp-32b and win2k3-64b on two partitions
> 2.First convert Windows XP:
.....

Comment 7 Richard W.M. Jones 2011-08-23 07:36:21 UTC

For comment 5, this seems to be a different bug.  I created
a new bug 732637.

Comment 8 Matthew Booth 2011-08-23 09:05:03 UTC

(In reply to comment #7)
> For comment 5, this seems to be a different bug.  I created
> a new bug 732637.

Yes. Recommend this bug is moved to VERIFIED.

Comment 9 yuping zhang 2011-08-23 10:18:04 UTC

Created attachment 519421 [details]
Check virt-v2v code with patch

Comment 10 yuping zhang 2011-08-23 10:20:42 UTC

Tested issue with virt-v2v-0.8.3-1.el6.src,checked if the patch http://git.fedorahosted.org/git/?p=virt-v2v.git;a=commitdiff;h=1454043d0bd335ab0220c9b1957e757f54d1309b  is included in virt-v2v code.

The result I have attached to this bug.But there is still some difference with that patch,maybe virt-v2v code has been updated after the pushed this patch.

Hi Matt, can you confirm it?
I marked the difference part begin with "===".Thank you.

Comment 11 Matthew Booth 2011-08-23 10:31:58 UTC

I've been through this and it's all as expected. The differences are due to changes made since the original patch. In some cases the changes are substantial as you've noticed, but they don't re-introduce reliance on non-core libguestfs inspection.

Comment 12 yuping zhang 2011-08-23 10:38:43 UTC

Per comment 10 and comment 11,change the status to VERIFIED.Thanks,Matt.

Comment 13 Richard W.M. Jones 2011-08-23 10:40:57 UTC

A better way to check this is as follows:

(1) I downloaded virt-v2v 0.8.2-1.el6 (fixed-in-version field
for this bug) from brew.

https://brewweb.devel.redhat.com/buildinfo?buildID=173535

(2) I unpacked the RPM with rpm2cpio.

$ rpm2cpio virt-v2v-0.8.2-1.el6.x86_64.rpm | cpio -id
9978 blocks
$ ls
etc  usr  var  virt-v2v-0.8.2-1.el6.x86_64.rpm

(3) I checked for calls to the deprecated APIs
(only "open_guest" is allowed).

$ find -name '*.p[ml]' | xargs grep 'Sys::Guestfs::Lib'
./usr/share/perl5/vendor_perl/Sys/VirtConvert/GuestfsHandle.pm:use Sys::Guestfs::Lib qw(open_guest);

As you can see, only open_guest symbol is imported now.

(4) I checked for calls to the core inspection APIs
(these are GOOD):

$ find -name '*.p[ml]' | xargs grep -E 'inspect_(get|list)'
[many lines of output here]

Based on this analysis, I would verify this bug.

Comment 14 yuping zhang 2011-08-23 10:51:32 UTC

I also tested this issue on virt-v2v-0.8.3-1.el6 with steps in comment  13

# rpm2cpio virt-v2v-0.8.3-1.el6.x86_64.rpm | cpio -id
10037 blocks

# ls
etc  usr  var  virt-v2v-0.8.3-1.el6.x86_64.rpm

# find -name '*.p[ml]' | xargs grep 'Sys::Guestfs::Lib'
./usr/share/perl5/vendor_perl/Sys/VirtConvert/GuestfsHandle.pm:use Sys::Guestfs::Lib qw(open_guest);

# find -name '*.p[ml]' | xargs grep -E 'inspect_(get|list)'
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/RHEVTarget.pm:    my $arch = $g->inspect_get_arch($root);
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/RHEVTarget.pm:        if ($g->inspect_get_type($root) eq 'linux');
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/RHEVTarget.pm:        if ($g->inspect_get_type($root) eq 'windows');
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/RHEVTarget.pm:    my $major   = $g->inspect_get_major_version($root);
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/RHEVTarget.pm:    my $minor   = $g->inspect_get_minor_version($root);
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/RHEVTarget.pm:    my $product = $g->inspect_get_product_name($root);
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/RHEVTarget.pm:        if (defined($g->can('inspect_get_product_variant')) &&
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/RHEVTarget.pm:            $g->inspect_get_product_variant($root) eq 'Client')
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/RHEVTarget.pm:    my $distro  = $g->inspect_get_distro($root);
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Connection/RHEVTarget.pm:    my $major   = $g->inspect_get_major_version($root);
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter.pm:    my %fses = $g->inspect_get_mountpoints ($root);
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter.pm:    $desc{os}               = $g->inspect_get_type($root);
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter.pm:    $desc{distro}           = $g->inspect_get_distro($root)
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter.pm:    $desc{product_name}     = $g->inspect_get_product_name($root);
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter.pm:    $desc{major_version}    = $g->inspect_get_major_version($root);
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter.pm:    $desc{minor_version}    = $g->inspect_get_minor_version($root);
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter.pm:    $desc{arch}             = $g->inspect_get_arch($root);
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm:    my %mounts = $g->inspect_get_mountpoints($root);
./usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm:    my @apps = $g->inspect_list_applications($root);

Comment 15 errata-xmlrpc 2011-12-06 15:08:00 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2011-1615.html

Note You need to log in before you can comment on or make changes to this bug.