Bug 1650415 - [RFE] Add libosinfo id to virt-v2v output
Summary: [RFE] Add libosinfo id to virt-v2v output
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: libguestfs
Version: 8.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: 8.0
Assignee: Libvirt Maintainers
QA Contact: Virtualization Bugs
URL:
Whiteboard: V2V
Depends On: 1544842 1560935 1666113
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-16 06:23 UTC by tingting zheng
Modified: 2020-11-14 19:13 UTC (History)
12 users (show)

Fixed In Version: libguestfs-1.40.1-1.module+el8+2708+fbd828c6
Doc Type: Enhancement
Doc Text:
Clone Of: 1560935
Environment:
Last Closed: 2019-05-29 16:04:08 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:1293 0 None None None 2019-05-29 16:04:20 UTC

Comment 5 Richard W.M. Jones 2018-12-07 08:55:45 UTC
However this particular bug is (almost) a 1-liner.  It just adds
some debugging output which is picked up by the current KubeVirt:

https://github.com/libguestfs/libguestfs/commit/ea49d75d0dd7ef05614f21f575fb27371f60782f

In future this should be replaced with an ‘-o kubevirt’ mode
as we discussed with the team last week, but we've not implemented
that yet.

Comment 6 Karen Noel 2018-12-07 11:39:57 UTC
Tingting, Can you set qa_ack+ now? Thanks.

Comment 7 tingting zheng 2018-12-10 02:54:35 UTC
(In reply to Karen Noel from comment #6)
> Tingting, Can you set qa_ack+ now? Thanks.

Done.

Comment 9 Pino Toscano 2019-01-21 11:47:54 UTC
This bug will be fixed by the rebase scheduled for RHEL AV 8.0.1 , see bug 1666113.

Comment 10 Pino Toscano 2019-01-21 12:52:05 UTC
(In reply to Pino Toscano from comment #9)
> This bug will be fixed by the rebase scheduled for RHEL AV 8.0.1 , see bug
> 1666113.

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 12 mxie@redhat.com 2019-03-05 04:25:28 UTC
Verify the bug with builds:
virt:8.0.0:820190301161825:9edba152:x86_64
virt-v2v-1.40.2-1.module+el8+2781+dde9b93a.x86_64
libguestfs-1.40.2-1.module+el8+2781+dde9b93a.x86_64
libvirt-5.0.0-5.module+el8+2850+33063f9c.x86_64
qemu-kvm-3.1.0-18.module+el8+2834+fa8bb6e2.x86_64
nbdkit-1.4.2-4.module+el8+2587+09999a71.x86_64
virtio-win-1.9.7-3.el8.noarch
libguestfs-winsupport-8.0-2.module+el8+2179+85112f94.x86_64


Background:
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 incorrect which has been tracked by bug1685364 


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-GUI -ip /tmp/passwd

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


Result:
    There is libosinfo in the guest libvirtxml after virt-v2v converting to libvirt and local,so move the bug from ON_QA to VERIFIED

Comment 14 errata-xmlrpc 2019-05-29 16:04:08 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-2019:1293


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