Bug 1472288

Summary: virt-v2v fails on opensuse 13.2 guest with error: statns: statns_stub: path must start with a / character
Product: Red Hat Enterprise Linux 7 Reporter: Richard W.M. Jones <rjones>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.5CC: kuwei, mxie, mzhan, ptoscano, rbalakri, rjones, tzheng
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: V2V
Fixed In Version: libguestfs-1.36.6-1.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1472208 Environment:
Last Closed: 2018-04-10 09:18:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1472208, 1472272    
Bug Blocks: 1463620, 1679960    
Attachments:
Description Flags
esx.opensuse.to.ovirt
none
esx-opensuse13.1-to-ovirt none

Description Richard W.M. Jones 2017-07-18 11:28:13 UTC
+++ This bug was initially created as a clone of Bug #1472208 +++

Description of problem:

$ virt-builder opensuse-13.2 
$ virt-v2v -i disk opensuse-13.2.img -o null
[   0.0] Opening the source -i disk opensuse-13.2.img
[   0.0] Creating an overlay to protect the source from being modified
[   0.0] Initializing the target -o null
[   0.0] Opening the overlay
[  10.7] Inspecting the overlay
[  13.3] Checking for sufficient free disk space in the guest
[  13.3] Estimating space required on target for each disk
[  13.3] Converting openSUSE 13.2 (Harlequin) (x86_64) to run on KVM
virt-v2v: warning: no initrd was found in /boot matching kernel-default 
3.16.7-24-default.
virt-v2v: error: libguestfs error: statns: statns_stub: path must start 
with a / character

If reporting bugs, run virt-v2v with debugging enabled and include the 
complete output:

  virt-v2v -v -x [...]


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

libguestfs 1.37.17

How reproducible:

100%

Steps to Reproduce:
1. See above.

--- Additional comment from Richard W.M. Jones on 2017-07-18 05:16 EDT ---



--- Additional comment from Richard W.M. Jones on 2017-07-18 05:19:10 EDT ---

Even with perl & perl-Bootloader installed in the guest I see the
same error.

--- Additional comment from Richard W.M. Jones on 2017-07-18 06:01:37 EDT ---

Patch posted:
https://www.redhat.com/archives/libguestfs/2017-July/msg00154.html

Comment 4 Pino Toscano 2017-09-18 08:35:28 UTC
This will come via the rebase.

Comment 6 kuwei@redhat.com 2017-09-23 11:33:08 UTC
Verify the bug with below builds:
virt-v2v-1.36.6-1.el7.x86_64
libguestfs-1.36.6-1.el7.x86_64
libvirt-3.7.0-2.el7.x86_64
qemu-kvm-rhev-2.9.0-16.el7_4.8.x86_64

Steps:

Scenario 1:
1.Prepare a openSUSE x84_64 guest on local libvirt.
2.Using virt-v2 to convert the guest to rhv
# virt-v2v opensuse13.2 -o rhv -os 10.73.131.93:/home/nfs_export
3.Conversion with no error and checkpoints all passed

Scenario 2:
1.Prepare a openSUSE x84_64 guest on xen server.
2.Using virt-v2 to convert the guest to rhv
# virt-v2v -ic xen+ssh://10.73.3.21  xen-opensuse13.2 -of raw -o rhv -os 10.73.131.93:/home/nfs_export
3.Conversion with no error and checkpoints all passed.

Scenario 3:
1.Prepare a openSUSE x84_64 guest on xen server.
2.Using virt-v2 to convert the guest to libvirt
# virt-v2v -ic xen+ssh://10.73.3.21  xen-opensuse13.2 -of raw 
3.Conversion with no error .

Scenario 4:
1.Prepare a openSUSE x84_64 guest on ESX server.
2.Using virt-v2 to convert the guest to rhv
# virt-v2v -ic vpx://root.75.182/data/10.73.72.61/?no_verify=1 esx6.0-opensuse13.2-x86_64 --password-file /tmp/passwd -o rhv -os 10.73.131.93:/home/nfs_export
3.Conversion with no error.

Scenario 5:
1.Prepare a openSUSE x84_64 guest on ESX server.
2.Using virt-v2 to convert the guest to libvirt
# virt-v2v -ic vpx://root.75.182/data/10.73.72.61/?no_verify=1 esx6.0-opensuse13.2-x86_64 --password-file /tmp/passwd 
3.Conversion with no error.


HI, rjones ,we see the guest can be convert successfuly.
But i have two qeustion about the bug :
1.When convert guest to libvirt(from xen/ESX),the guest video type became"crrus",we know when convert a rhel guest the video will be "QXL"
2.The guest installed on ESX server the network name will be named as ifcfg-eng****, and after conversion we can't find the network when using command "ifconfig" as the attachment picture.

Comment 7 kuwei@redhat.com 2017-09-24 22:47:00 UTC
Created attachment 1330268 [details]
esx.opensuse.to.ovirt

Comment 8 kuwei@redhat.com 2017-09-24 23:05:42 UTC
Created attachment 1330273 [details]
esx-opensuse13.1-to-ovirt

Comment 10 Richard W.M. Jones 2017-09-25 08:48:00 UTC
(In reply to kuwei from comment #6)
> But i have two qeustion about the bug :
> 1.When convert guest to libvirt(from xen/ESX),the guest video type
> became"crrus",we know when convert a rhel guest the video will be "QXL"

Right, as you say for `SUSE_family we force Cirrus instead of QXL.  This derives
from virt-v2v 0.9 code (which I think is no longer online after fedorahosted
got deleted) which said:

# Distributions may use different display drivers.
sub _get_display_driver
{
    my ($g, $root) = @_;

    if (_is_suse_family($g, $root)) {
        # SUSE currently uses cirrus.
        return 'cirrus';
    } else {
        # RedHat uses qxl, which should be the default driver.
        return 'qxl';
    }
}

This code was added by Mike Latimer who did the original port.

I guess it depends on whether SUSE are shipping the full virtio drivers on
Linux now.

> 2.The guest installed on ESX server the network name will be named as
> ifcfg-eng****, and after conversion we can't find the network when using
> command "ifconfig" as the attachment picture.

This is a bug.  Is it a duplicate of bug 1318922?

Comment 11 kuwei@redhat.com 2017-09-25 09:54:15 UTC
Hi, as the bug  duplicate of bug 1318922, I will add a comment to that bug.and move this bug to VEFIFIED.

Comment 14 errata-xmlrpc 2018-04-10 09:18:10 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.

https://access.redhat.com/errata/RHBA-2018:0677