Created attachment 1197111 [details]
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):
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
As above description
Process status shows normal in windows guest after converted from kvm to rhev by virt-v2v
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://firstname.lastname@example.org/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
Created attachment 1197112 [details]
Created attachment 1197113 [details]
Created attachment 1197114 [details]
Created attachment 1197115 [details]
My suspicion is because we are deleting two nodes from the registry.
See this code in old virt-v2v:
New virt-v2v does the same.
Assuming that really is the issue, I posted this patch:
The patch is upstream (56e566af38c893e30f4dec1e079a9fc31eaf5104)
so this should be fixed by the rebase.
Verify the bug with builds:
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"
1.CPU status of win7,win2008r2, win8 guest are normal after converting from kvm to rhv by virt-v2v
Just win10 guest's cpu status has some problem, could you help check this ?
Created attachment 1262370 [details]
Created attachment 1262371 [details]
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
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'>
But the converted OVF has something more generic:
<Info>1 CPU, 1024 Memory</Info>
<rasd:Caption>1 virtual cpu</rasd:Caption>
<rasd:Description>Number of virtual CPU</rasd:Description>
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.
Please open a bug on RHEV regarding the warning icon you see when importing VM from export domain.
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
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.
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.