Bug 1560935

Summary: [RFE] Add libosinfo id to virt-v2v output
Product: Red Hat Enterprise Linux 7 Reporter: Piotr Kliczewski <pkliczew>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: high    
Version: 7.5CC: mtessun, mxie, mzhan, ptoscano, tzheng
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: V2V
Fixed In Version: libguestfs-1.40.2-2.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1650415 (view as bug list) Environment:
Last Closed: 2019-08-06 12:44:11 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: 1544842, 1621895    
Bug Blocks: 1650415    

Description Piotr Kliczewski 2018-03-27 09:52:42 UTC 
Description of problem:

During importing a vm to kubevirt using virt-v2v we need short-id of the os installed on source vm. Providing such information is needed to properly create offlinevm or a template object in kubevirt.

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:



Expected results:

Expected output would be when running:

osinfo-query os name=<source vm os name> --fields=short-id | tail -1 | tr -d '[:space:]'

Example:
$ osinfo-query os name="Red Hat Enterprise Linux 7.4" --fields=short-id | tail -1 | tr -d '[:space:]'
rhel7.4

Additional info:
Comment 3 Richard W.M. Jones 2018-03-27 10:00:50 UTC 
The context isn't very clear, but this is needed so that a future
kubevirt output mode can provide the osinfo short id to kubevirt.

I added the basic groundwork in this commit (although on its own
this commit doesn't do anything useful):

https://github.com/libguestfs/libguestfs/commit/ea49d75d0dd7ef05614f21f575fb27371f60782f
Comment 7 Pino Toscano 2019-01-17 12:03:07 UTC 
This bug will be fixed by the rebase scheduled for RHEL 7.7, see bug 1621895.

In particular, now the libvirt XML includes the libosinfo XML metadata:
https://www.redhat.com/archives/libosinfo/2018-September/msg00003.html
note that the ID is not the short-id, but the full libosinfo ID.

This was implemented with
https://github.com/libguestfs/libguestfs/commit/cbe4150fbcd7d5fd11d6ef95e101bac3eaa062d9
which is in libguestfs >= 1.39.12.
Comment 9 mxie@redhat.com 2019-02-27 06:36:59 UTC 
Test the bug with builds:
virt-v2v-1.40.2-1.el7.x86_64
libguestfs-1.40.2-1.el7.x86_64
libvirt-4.5.0-10.el7_6.4.x86_64
qemu-kvm-rhev-2.12.0-18.el7_6.3.x86_64
virtio-win-1.9.6-1.el7.noarch

Background:
According to comment7, libosinfo metadata will be generated only when the output is local and libvirt

Steps:
Scenario1
1.1 Convert a windows guest from VMX file to libvirt by virt-v2v
# virt-v2v -i vmx esx6.5-win2019-x86_64/esx6.5-win2019-x86_64.vmx -of qcow2

1.2 Check guest libvirtxml for libosinfo ID after finishing v2v conversion.
# virsh dumpxml esx6.5-win2019-x86_64
<domain type='kvm'>
  <name>esx6.5-win2019-x86_64</name>
  <uuid>5787f072-c3ea-4da5-9732-7520b878cecb</uuid>
  <genid>9c75fe06-2256-f012-e5f2-a432d79dab06</genid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://microsoft.com/win/2k16"/>
    </libosinfo:libosinfo>
  </metadata>
....

1.3 Power on guest normally and checkpoints of guest are passed

Result1:
   There is libosinfo in the guest libvirtxml after converting a windows guest from VMX by virt-v2v, but the os id is not very accurate.


Scenario2:
2.1 Convert a ubuntu guest from VMware to local by virt-v2v
# virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io  vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA -n default esx6.7-ubuntu18.04-x86_64 -ip /tmp/passwd

2.3 Power on guest normally and checkpoints of guest are passed
# virsh dumpxml esx6.7-ubuntu18.04-x86_64
<domain type='kvm'>
  <name>esx6.7-ubuntu18.04-x86_64-bug1481930-GUI</name>
  <uuid>fdfd376f-d6f1-48b5-bd93-774132cee655</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://ubuntu.com/ubuntu/18.04"/>
    </libosinfo:libosinfo>
  </metadata>
....

Result2:
   There is libosinfo in the guest libvirtxml after converting a ubuntu guest from ova by virt-v2v
  

Scenario3:
3.1 Convert a opensuse guest from VMware via vddk to libvirt by virt-v2v
#  virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io  vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA -n default esx6.7-opensuse42.3-x86_64 -ip /tmp/passwd

3.2 Check guest libvirtxml for libosinfo ID after finishing v2v conversion
# virsh dumpxml esx6.7-opensuse42.3-x86_64
<domain type='kvm'>
  <name>esx6.7-opensuse42.3-x86_64</name>
  <uuid>9012656d-25a6-46eb-ae55-eb6d467034c4</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://opensuse.org/opensuse/42.3"/>
    </libosinfo:libosinfo>
....
3.3 Power on guest normally and checkpoints of guest are passed

Result3:
   There is libosinfo in the guest libvirtxml after converting a opensuse guest from VMware by virt-v2v


Scenario4:
4.1 Convert a rhel guest from Xen to libvirt by virt-v2v
# virt-v2v -ic xen+ssh://root.3.21 xen-hvm-rhel7.6-x86_64 -of qcow2 -b default

4.2 Check guest libvirtxml for libosinfo ID after finishing v2v conversion
# virsh dumpxml xen-hvm-rhel7.6-x86_64
<domain type='kvm'>
  <name>xen-hvm-rhel7.6-x86_64</name>
  <uuid>e9c0feed-efef-4f56-b37c-75563e364250</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://redhat.com/rhel/7.6"/>
    </libosinfo:libosinfo>
  </metadata>
....
4.3 Power on guest normally and checkpoints of guest are passed

Result4:
   There is libosinfo in the guest libvirtxml after converting a rhel guest from Xen by virt-v2v.


Scenario5:
5.1 Convert a debian guest from VMware to libvirt by virt-v2v
#virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io  vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA -b default esx6.7-debian9.6-x86_64 -ip /tmp/passwd

5.2 Check guest libvirtxml for libosinfo ID after finishing v2v conversion
# virsh dumpxml esx6.7-debian9.6-x86_64
<domain type='kvm' id='4'>
  <name>esx6.7-debian9.6-x86_64</name>
  <uuid>20ef6709-837a-4ae3-bcdc-5b23f636db9f</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://debian.org/debian/9"/>
    </libosinfo:libosinfo>
  </metadata>
....
5.3 Power on guest normally and checkpoints of guest are passed

Result5:
   There is libosinfo in the guest libvirtxml after converting a debian guest from VMware by virt-v2v.


Scenario6:
6.1 Convert a SLES guest from Xen to libvirt by virt-v2v
#virt-v2v -ic xen+ssh://root.3.21 xen-hvm-sles12sp1-x86_64 -of qcow2 -b default

6.2 Check guest libvirtxml for libosinfo ID after finishing v2v conversion
# virsh dumpxml xen-hvm-sles12sp1-x86_64
<domain type='kvm'>
  <name>xen-hvm-sles12sp1-x86_64</name>
  <uuid>2d702110-9e9c-49bf-a254-0a4a30e8a2c1</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://suse.com/sles/12.1"/>
    </libosinfo:libosinfo>
  </metadata>
....

6.3 Power on guest normally and checkpoints of guest are passed

Result6:
   There is libosinfo in the guest libvirtxml after converting a SLES guest from Xen by virt-v2v.


Hi Pino,
   As result1 shows, OS ID shows http://microsoft.com/win/2k16 aften converting a win2019 by v2v, is it possible to show its OS ID more exactly?
Comment 10 mxie@redhat.com 2019-02-28 04:31:38 UTC 
Got Pino's confirmation, file bug1683902 to track osinfo ID for win2019 guest
Comment 11 Pino Toscano 2019-02-28 11:17:38 UTC 
(In reply to mxie from comment #9)
>    As result1 shows, OS ID shows http://microsoft.com/win/2k16 aften
> converting a win2019 by v2v, is it possible to show its OS ID more exactly?

Sure, it is possible.
Note that it practice it does not change anything, since Windows Server 2019 seems like a more recent build of Windows Server 2016. So when doing any change/handling of the guest, it can be safely assumed it works exactly like Windows Server 2016.

I just sent a patch upstream to improve the osinfo ID for Windows Server 2019:
https://www.redhat.com/archives/libguestfs/2019-February/msg00069.html
Comment 12 mxie@redhat.com 2019-04-15 10:44:40 UTC 
Verify the bug with builds:
virt-v2v-1.40.2-2.el7.x86_64
libguestfs-1.40.2-2.el7.x86_64
virtio-win-1.9.7-0.el7.noarch
libvirt-4.5.0-12.el7.x86_64
qemu-kvm-rhev-2.12.0-26.el7.x86_64
nbdkit-1.8.0-1.el7.x86_64
libguestfs-winsupport-7.2-3.el7.x86_64

Background:
According to comment7, libosinfo metadata will be generated only when the output is local and libvirt

Steps:
Scenario1
1.1 Convert a windows guest from VMX file to libvirt by virt-v2v
#  virt-v2v -i vmx -it ssh ssh://root.75.219/vmfs/volumes/5aefd41e-1d448cf8-0b1f-001018d0c8e0/esx6.7-win2019-x86_64-efi/esx6.7-win2019-x86_64-efi.vmx -of qcow2
[   0.0] Opening the source -i vmx ssh://root.75.219/vmfs/volumes/5aefd41e-1d448cf8-0b1f-001018d0c8e0/esx6.7-win2019-x86_64-efi/esx6.7-win2019-x86_64-efi.vmx
[   0.4] Creating an overlay to protect the source from being modified
[   0.8] Opening the overlay
[   7.2] Inspecting the overlay
[  11.8] Checking for sufficient free disk space in the guest
[  11.8] Estimating space required on target for each disk
[  11.8] Converting Windows Server 2019 Standard to run on KVM
virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing.  
Firstboot scripts may conflict with PnP.
virt-v2v: warning: there is no QXL driver for this version of Windows (10.0 
x86_64).  virt-v2v looks for this driver in 
/usr/share/virtio-win/virtio-win.iso

The guest will be configured to use a basic VGA display driver.
virt-v2v: This guest has virtio drivers installed.
[  17.6] Mapping filesystem data to avoid copying unused and blank areas
virt-v2v: warning: fstrim on guest filesystem /dev/sda2 failed.  Usually 
you can ignore this message.  To find out more read "Trimming" in 
virt-v2v(1).

Original message: fstrim: fstrim: /sysroot/: the discard operation is not 
supported
[  18.8] Closing the overlay
[  18.9] Assigning disks to buses
[  18.9] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[  18.9] Initializing the target -o libvirt -os default
[  19.0] Copying disk 1/1 to /var/lib/libvirt/images/esx6.7-win2019-x86_64-efi-sda (qcow2)
    (100.00/100%)
[ 444.1] Creating output metadata
Pool default refreshed

error: Failed to define domain from /tmp/v2vlibvirt440c0a.xml
error: unsupported configuration: IDE controllers are unsupported for this QEMU binary or machine type

virt-v2v: warning: could not define libvirt domain.  The libvirt XML is 
still available in ‘/tmp/v2vlibvirt440c0a.xml’.  Try running ‘virsh 
define /tmp/v2vlibvirt440c0a.xml’ yourself instead.
[ 446.1] Finishing off

1.2 Modify the cdrom type from IDE to SATA in guest libvirtxml and define guest by manual due to bug1369010
# virsh define v2vlibvirt440c0a.xml 
Domain esx6.7-win2019-x86_64-efi defined from v2vlibvirt440c0a.xml

1.3 Check guest libvirtxml for libosinfo ID after finishing v2v conversion.
# virsh dumpxml esx6.7-win2019-x86_64-efi
<domain type='kvm'>
  <name>esx6.7-win2019-x86_64-efi</name>
  <uuid>ebef3a9d-7517-4a12-807e-4f8d7aac0b75</uuid>
  <genid>0f5ad477-8ae9-d247-e3ba-bda61f1e57bc</genid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://microsoft.com/win/2k19"/>
    </libosinfo:libosinfo>
  </metadata>
....

1.4 Power on guest and checkpoints of guest are passed

Result1:
   There is libosinfo in the guest libvirtxml after converting a windows guest from VMX by virt-v2v

Scenario2:
2.1 Convert a ubuntu guest from VMware to local by virt-v2v via vddk
# virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io  vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA -n default esx6.7-ubuntu18.04-x86_64-GUI -ip /tmp/passwd

2.2 Power on guest normally and checkpoints of guest are passed
# virsh dumpxml esx6.7-ubuntu18.04-x86_64-GUI
<domain type='kvm'>
  <name>esx6.7-ubuntu18.04-x86_64-GUI</name>
  <uuid>083fc42c-1f57-4948-a67c-c449bc104ef0</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://ubuntu.com/ubuntu/18.04"/>
    </libosinfo:libosinfo>
  </metadata>
....

2.3  Power on guest and checkpoints of guest are passed

Result2:
   There is libosinfo in the guest libvirtxml after converting a ubuntu guest from ova by virt-v2v
  

Scenario3:
3.1 Convert a opensuse guest from VMware via vddk to libvirt by virt-v2v
virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io  vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA -n default esx6.7-opensuse15-x86_64-xfs -ip /tmp/passwd

3.2 Check guest libvirtxml for libosinfo ID after finishing v2v conversion
# virsh dumpxml esx6.7-opensuse15-x86_64-xfs
<domain type='kvm'>
  <name>esx6.7-opensuse15-x86_64-xfs</name>
  <uuid>d7ca66ec-bebc-4e6f-94ea-a74f9fe294bd</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://opensuse.org/opensuse/15.0"/>
    </libosinfo:libosinfo>
  </metadata>
....
3.3 Power on guest normally and checkpoints of guest are passed

Result3:
   There is libosinfo in the guest libvirtxml after converting a opensuse guest from VMware by virt-v2v


Scenario4:
4.1 Convert a rhel guest from Xen to libvirt by virt-v2v
# virt-v2v -ic xen+ssh://root.3.21 xen-pv-rhel5.11-x86_64 -of qcow2 -b default

4.2 Check guest libvirtxml for libosinfo ID after finishing v2v conversion
]# virsh dumpxml xen-pv-rhel5.11-x86_64
<domain type='kvm'>
  <name>xen-pv-rhel5.11-x86_64</name>
  <uuid>fda2e3fe-9afb-47e9-906c-533253db6859</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://redhat.com/rhel/5.11"/>
    </libosinfo:libosinfo>
  </metadata>
....
4.3 Power on guest normally and checkpoints of guest are passed

Result4:
   There is libosinfo in the guest libvirtxml after converting a rhel guest from Xen by virt-v2v.


Scenario5:
5.1 Convert a debian guest from VMware to libvirt by virt-v2v
#virt-v2v -ic vpx://root.73.141/data/10.73.196.89/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io  vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA -b default esx6.5-debian9.8-x86_64 -ip /tmp/passwd

5.2 Check guest libvirtxml for libosinfo ID after finishing v2v conversion
# virsh dumpxml esx6.5-debian9.8-x86_64
<domain type='kvm'>
  <name>esx6.5-debian9.8-x86_64</name>
  <uuid>5be4cdf3-8df4-4979-9829-b5e2c784ddca</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://debian.org/debian/9"/>
    </libosinfo:libosinfo>
  </metadata>
....
5.3 Power on guest normally and checkpoints of guest are passed

Result5:
   There is libosinfo in the guest libvirtxml after converting a debian guest from VMware by virt-v2v.


Scenario6:
6.1 Convert a SLES guest from Xen to libvirt by virt-v2v
# virt-v2v -ic xen+ssh://root.3.21 xen-hvm-sles12sp1-x86_64 -of qcow2


6.2 Check guest libvirtxml for libosinfo ID after finishing v2v conversion
# virsh dumpxml xen-hvm-sles12sp1-x86_64
<domain type='kvm'>
  <name>xen-hvm-sles12sp1-x86_64</name>
  <uuid>c59997a7-82e3-45c1-b174-49e5025ed9c9</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://suse.com/sles/12.1"/>
    </libosinfo:libosinfo>
....

6.3 Power on guest normally and checkpoints of guest are passed

Result6:
   There is libosinfo in the guest libvirtxml after converting a SLES guest from Xen by virt-v2v.


According to above test results, move the bug from ON_QA to VERIFIED
Comment 14 errata-xmlrpc 2019-08-06 12:44:11 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/RHEA-2019:2096