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 1372668 - Process status is not normal in windows guest after converted from kvm to rhev by virt-v2v
Summary: Process status is not normal in windows guest after converted from kvm to rhe...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs
Version: 7.3
Hardware: x86_64
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard: V2V
Depends On: 1359086
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-02 10:28 UTC by mxie@redhat.com
Modified: 2017-08-01 22:08 UTC (History)
9 users (show)

Fixed In Version: libguestfs-1.36.1-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 22:08:55 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
kvm-win10-cpu-debug.log (426.81 KB, text/plain)
2016-09-02 10:28 UTC, mxie@redhat.com 		no flags Details
vmware-win10-cpu-debug.log (430.52 KB, text/plain)
2016-09-02 10:28 UTC, mxie@redhat.com 		no flags Details
original-windows-on-kvm (94.51 KB, image/png)
2016-09-02 10:29 UTC, mxie@redhat.com 		no flags Details
kvm-windows-rhev (100.14 KB, image/png)
2016-09-02 10:30 UTC, mxie@redhat.com 		no flags Details
vmware-windows-rhev (86.75 KB, image/png)
2016-09-02 10:30 UTC, mxie@redhat.com 		no flags Details
win10-rhv-1.36.png (172.48 KB, image/png)
2017-03-13 09:20 UTC, mxie@redhat.com 		no flags Details
virt-v2v-win10-cpu-1.36.log (396.58 KB, text/plain)
2017-03-13 09:22 UTC, mxie@redhat.com 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2023 0 normal SHIPPED_LIVE libguestfs bug fix and enhancement update 2017-08-01 19:32:01 UTC

Description mxie@redhat.com 2016-09-02 10:28:11 UTC 
Created attachment 1197111 [details]
kvm-win10-cpu-debug.log

Description of problem:
Process status is not normal in windows guest after converted from kvm to rhev by virt-v2v


Version-Release number of selected component (if applicable):
libguestfs-1.32.7-3.el7.x86_64
virt-v2v-1.32.7-3.el7.x86_64
libguestfs-winsupport-7.2-1.el7.x86_64
virtio-win-1.8.0-5.el7.noarch
qemu-kvm-rhev-2.6.0-22.el7.x86_64
libvirt-2.0.0-6.el7.x86_64
RHEVM:3.6.7.2-0.1.el6

How reproducible:
100%

Steps to Reproduce:
1.Prepare a windows guest on kvm which has cpu:Intel Xenon E312xx (Sandy Bridge) and cpu status is normal, pls refer to screenshot "original-windows-on-kvm"

2.Convert this windows guest from kvm to rhev by virt-v2v
#virt-v2v -o rhev -os 10.73.72.63:/home/nfs_export kvm-win10-x86_64 -v -x |& tee > kvm-win10-cpu-debug.log

3.After conversion, import the guest from export domain to data domain at rhev and power on the guest "kvm-win10-x86_64"

4.Check cpu status for guest and find that cpu has yellow bang and the status shows incomplete or damaged, pls refer to screenshot "kvm-windows-rhev"

5.Update driver for cpu by manaul, the status shows "the best driver software for your device is already installed", then reboot the guest and check cpu status of guest is still not normal as step4

Actual results:
As above description

Expected results:
Process status shows normal in windows guest after converted from kvm to rhev by virt-v2v

Additional info:
1.Can't reproduce this problem when convert the windows guest from vmware to rhev by virt-v2v, pls refer to screenshot"vmware-windows-rhev"
#virt-v2v -ic vpx://root.145.47/data/10.66.144.40/?no_verify=1 --password-file /tmp/passwd esx6.0-win10-x86_64 -o rhev -os 10.73.72.63:/home/nfs_export -v -x |& tee > vmware-win10-cpu-debug.log

2.Can reproduce this problem when convert win7 guest and win8 guest from kvm to rhev by virt-v2v
Comment 1 mxie@redhat.com 2016-09-02 10:28:49 UTC 
Created attachment 1197112 [details]
vmware-win10-cpu-debug.log
Comment 2 mxie@redhat.com 2016-09-02 10:29:30 UTC 
Created attachment 1197113 [details]
original-windows-on-kvm
Comment 3 mxie@redhat.com 2016-09-02 10:30:23 UTC 
Created attachment 1197114 [details]
kvm-windows-rhev
Comment 4 mxie@redhat.com 2016-09-02 10:30:58 UTC 
Created attachment 1197115 [details]
vmware-windows-rhev
Comment 5 Richard W.M. Jones 2016-09-02 11:07:27 UTC 
My suspicion is because we are deleting two nodes from the registry.

See this code in old virt-v2v:

https://git.fedorahosted.org/cgit/virt-v2v.git/tree/lib/Sys/VirtConvert/Converter/Windows.pm#n634

New virt-v2v does the same.
Comment 7 Richard W.M. Jones 2016-09-02 11:28:17 UTC 
Assuming that really is the issue, I posted this patch:

https://www.redhat.com/archives/libguestfs/2016-September/msg00012.html
Comment 8 Richard W.M. Jones 2017-02-22 13:08:46 UTC 
The patch is upstream (56e566af38c893e30f4dec1e079a9fc31eaf5104)
so this should be fixed by the rebase.
Comment 10 mxie@redhat.com 2017-03-13 09:20:06 UTC 
Verify the bug with builds:
virt-v2v-1.36.2-1.el7.x86_64
libguestfs-1.36.2-1.el7.x86_64
libvirt-3.1.0-2.el7.x86_64
qemu-kvm-rhev-2.8.0-6.el7.x86_64
libguestfs-winsupport-7.2-2.el7.x86_64
virtio-win-1.9.0-3.el7.noarch

Steps:
1.Prepare a win10 guest on kvm which has cpu:Intel Xenon E312xx (Sandy Bridge) and cpu status is normal

2.Convert this windows guest from kvm to rhv by virt-v2v
# virt-v2v kvm-win10-x86_64-qcow2 -o rhv -os 10.73.131.91:/tmp/nfs_export

3.After conversion, import the guest from export domain to data domain at rhv and power on the guest

4.Check cpu status of the guest, but cpu status still has problem, pls refer to screenshot "win10-rhv-1.36.png" and log "virt-v2v-win10-cpu-1.36"

Additional info:
1.CPU status of win7,win2008r2, win8 guest are normal after converting from kvm to rhv by virt-v2v

Hi rjones,

Just win10 guest's cpu status has some problem, could you help check this ?
Comment 11 mxie@redhat.com 2017-03-13 09:20:59 UTC 
Created attachment 1262370 [details]
win10-rhv-1.36.png
Comment 12 mxie@redhat.com 2017-03-13 09:22:52 UTC 
Created attachment 1262371 [details]
virt-v2v-win10-cpu-1.36.log
Comment 13 Richard W.M. Jones 2017-03-13 16:53:06 UTC 
Did you see that the error is different.

In the original bug report, the Windows error was:

  "Windows cannot start this hardware device because its
   configuration information (in the registry) is incomplete
   or damaged (Code 19)"

In your verification, the error changed to:

  "Currently this hardware device is not connected to the
   computer (Code 45).
   To fix this problem, reconnect the hardware device to the
   computer."

I think the original problem (corrupted registry) is fixed.

The new problem is because we don't pass through the exact
CPU type to RHEV.  The source CPU is Sandybridge:

  <cpu mode='custom' match='exact'>
    <model fallback='allow'>SandyBridge</model>
  </cpu>

But the converted OVF has something more generic:

    <Section xsi:type='ovf:VirtualHardwareSection_Type'>
      <Info>1 CPU, 1024 Memory</Info>
      <Item>
        <rasd:Caption>1 virtual cpu</rasd:Caption>
        <rasd:Description>Number of virtual CPU</rasd:Description>
        <rasd:InstanceId>1</rasd:InstanceId>
        <rasd:ResourceType>3</rasd:ResourceType>
        <rasd:num_of_sockets>1</rasd:num_of_sockets>
        <rasd:cpu_per_socket>1</rasd:cpu_per_socket>
      </Item>

I don't believe there's any way to specify exact CPU types
to RHV (or even if this is desirable).  I will ask someone
on the RHV team for comment.
Comment 14 Shahar Havivi 2017-03-14 07:43:15 UTC 
Please open a bug on RHEV regarding the warning icon you see when importing VM from export domain.
Comment 15 mxie@redhat.com 2017-03-15 07:10:23 UTC 
According to comment14, file bug 1432329

Because have bug 1432329 to track the problem "win10 guest's cpu status is abnormal on rhv, this bug has been fixed, move the bug from ON_QA to VERIFIED
Comment 16 Richard W.M. Jones 2017-03-16 18:58:20 UTC 
I posted a patch series upstream which could fix this by
passing through CPU vendor, model and topology to the
target.  However it won't fix this bug because I couldn't
work out how to pass this information to RHV.

https://www.redhat.com/archives/libguestfs/2017-March/msg00181.html
Comment 17 errata-xmlrpc 2017-08-01 22:08:55 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-2017:2023
Note You need to log in before you can comment on or make changes to this bug.