Bug 737600
| Summary: | virt-v2v windows xp - machine dies BSOD - processr,sys - workaround provided | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Grant Williamson <grant_williamson> | ||||||
| Component: | virt-v2v | Assignee: | Matthew Booth <mbooth> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
| Severity: | urgent | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 6.1 | CC: | ngalvin, rjones, rwu, tzheng, walicki, yupzhang | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | virt-v2v-0.8.6-1.el6 | Doc Type: | Bug Fix | ||||||
| Doc Text: |
Cause
The user attempts to convert a Windows guest. The guest is configured with a CPU or chipset driver which malfunctions when the CPU/chipset is not present. (We have only seen this with P2V conversions, but it is not impossible in a V2V conversion.)
Consequence
The converted Windows XP guest crashes with a STOP error when booted.
Fix
During the conversion process, the registry keys relating to certain services known to cause problems are deleted.
Result
The converted guest will boot normally after the conversion process.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2012-06-20 12:41:32 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Can the changes to the registry keys be manipulated via libguestfs after the migration but before the WinXP image starts? Created attachment 522891 [details]
Windows reg entry to be merged with virt-win-reg
Windows reg entry to be merged with virt-win-reg.
This ensures machine will boot.
Deletes the 2 offending trees which are not required in the VM.
(In reply to comment #2) > Can the changes to the registry keys be manipulated via libguestfs after the > migration but before the WinXP image starts? Yes, using virt-win-reg (see http://libguestfs.org/virt-win-reg.1.html and possibly bug 737944). Reproduced the bug on virt-v2v-0.8.3-4.el6.x86_64 1.Install a XEN Windows XP SP3 guest,the disk type is sparse. Copy the image and xml file of Windows XP SP3 to local machine. 2.Use virt-v2v to convert the guest. # virt-v2v -i libvirtxml -of raw -oa sparse xen-hvm-winxp-i386-test.xml -b rhevm -os default 3.Boot the guest. When booting XP KVM I get a BSOD shortly after desktop appears as the bug descripted. Solutions: 1.Use virt-win-reg to check the keys of the guest. # virt-win-reg xen-hvm-winxp-i386-test 'HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\intelppm' [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\intelppm] "DisplayName"=hex(1):49,00,6e,00,74,00,65,00,6c,00,20,00,50,00,72,00,6f,00,63,00,65,00,73,00,73,00,6f,00,72,00,20,00,44,00,72,00,69,00,76,00,65,00,72,00,00,00 "ErrorControl"=dword:00000001 "Group"=hex(1):45,00,78,00,74,00,65,00,6e,00,64,00,65,00,64,00,20,00,42,00,61,00,73,00,65,00,00,00 "ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,52,00,49,00,56,00,45,00,52,00,53,00,5c,00,69,00,6e,00,74,00,65,00,6c,00,70,00,70,00,6d,00,2e,00,73,00,79,00,73,00,00,00 "Start"=dword:00000004 "Tag"=dword:00000003 "Type"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\intelppm\Security] "Security"=hex(3):01,00,14,80,90,00,00,00,9c,00,00,00,14,00,00,00,30,00,00,00,02,00,1c,00,01,00,00,00,02,80,14,00,ff,01,0f,00,01,01,00,00,00,00,00,01,00,00,00,00,02,00,60,00,04,00,00,00,00,00,14,00,fd,01,02,00,01,01,00,00,00,00,00,05,12,00,00,00,00,00,18,00,ff,01,0f,00,01,02,00,00,00,00,00,05,20,00,00,00,20,02,00,00,00,00,14,00,8d,01,02,00,01,01,00,00,00,00,00,05,0b,00,00,00,00,00,18,00,fd,01,02,00,01,02,00,00,00,00,00,05,20,00,00,00,23,02,00,00,01,01,00,00,00,00,00,05,12,00,00,00,01,01,00,00,00,00,00,05,12,00,00,00 # virt-win-reg xen-hvm-winxp-i386-test 'HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Processor' \ControlSet001\Services\Processor: path not found in this hive at /usr/bin/virt-win-reg line 259 2.Seen from step2,there is no keys as Processor presented,change the registry keys via libguestfs after the migration but before the WinXP image starts. # cat test001-processor.reg [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Processor] "Start"=dword:00000004 # virt-win-reg --merge xen-hvm-winxp-i386-test test001-processor.reg 3.After change the keys,check it again: # virt-win-reg xen-hvm-winxp-i386-test 'HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Processor' [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Processor] "Start"=dword:00000004 4.Boot the guest. When first boot the guest,the guest present a black screen. After you shutdown it and boot the guest again,then the guest can boot. More info: 1.When delete the HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Processor item after login,the guest can still login. # virt-win-reg xen-hvm-winxp-i386-test 'HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Processor' \ControlSet001\Services\Processor: path not found in this hive at /usr/bin/virt-win-reg line 259 2.When I set the start value to 1 in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Processor,the guest can boot successfully also. 3.When I use virt-v2v to convert a XEN Windows XP SP3 guest with the disk type preallocated,the guest can boot without BSOD. This link seems to be relevant: http://support.microsoft.com/kb/953356 It looks like virt-v2v needs an extra conversion step on Windows where "troublesome" registry keys and/or services can be disabled or deleted, starting with this one. I've push a patch upstream which deletes the service keys rather than attempting to disable the service. Unfortunately I can't reproduce this locally, so I'm trusting that this resolves the issue. I can still reproduce the bug with virt-v2v-0.8.6-1.el6.x86_64. After converted with virt-v2v,winxp guest will BSOD.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cause
The user attempts to convert a Windows guest. The guest is configured with a CPU or chipset driver which malfunctions when the CPU/chipset is not present. (We have only seen this with P2V conversions, but it is not impossible in a V2V conversion.)
Consequence
The converted Windows XP guest crashes with a STOP error when booted.
Fix
During the conversion process, the registry keys relating to certain services known to cause problems are deleted.
Result
The converted guest will boot normally after the conversion process.
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. http://rhn.redhat.com/errata/RHBA-2012-0788.html |
Created attachment 522734 [details] PNG showing the Blue Screen Of Death Description of problem: Red Hat 6.1 virt-v2v 0.8.3 Using dd created a raw image of a T41 running Windows XP SP3. Image is created with dd if=/dev/sda of=/mnt/usbdisk/xp.raw A stub file is created for the new guest and virt-v2v is run to import the image to the default pool. virt-v2v -i libvirtxml -of raw -oa sparse xp.xml -os default When booting XP KVM I get a BSOD shortly after desktop appears, see attachment bsod.png On closer inspection the following registry key is present "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Intelppm" The start value is set correctly to "4". There seems to be 2 possible workarounds/solutions 1) Adding the following key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Processor" Ensure the start value is set to "4". or 2) Delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Intelppm" and if present "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Processor" Version-Release number of selected component (if applicable): Red Hat 6.1 virt-v2v 0.8.3