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


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


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2023 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@10.66.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.