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 737600 - virt-v2v windows xp - machine dies BSOD - processr,sys - workaround provided
Summary: virt-v2v windows xp - machine dies BSOD - processr,sys - workaround provided
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-v2v
Version: 6.1
Hardware: x86_64
OS: Linux
high
urgent
Target Milestone: rc
: ---
Assignee: Matthew Booth
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-12 16:48 UTC by Grant Williamson
Modified: 2018-11-29 21:26 UTC (History)
6 users (show)

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.
Clone Of:
Environment:
Last Closed: 2012-06-20 12:41:32 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
PNG showing the Blue Screen Of Death (69.48 KB, image/png)
2011-09-12 16:48 UTC, Grant Williamson 		no flags Details
Windows reg entry to be merged with virt-win-reg (656 bytes, text/plain)
2011-09-13 11:02 UTC, Grant Williamson 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0788 0 normal SHIPPED_LIVE virt-v2v bug fix and enhancement update 2012-06-19 20:34:39 UTC

Description Grant Williamson 2011-09-12 16:48:56 UTC 
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
Comment 2 John Walicki 2011-09-12 17:35:53 UTC 
Can the changes to the registry keys be manipulated via libguestfs after the
migration but before the WinXP image starts?
Comment 3 Grant Williamson 2011-09-13 11:02:58 UTC 
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.
Comment 4 Richard W.M. Jones 2011-09-13 13:12:07 UTC 
(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).
Comment 5 tingting zheng 2011-09-15 07:26:57 UTC 
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.
Comment 6 Richard W.M. Jones 2011-09-15 08:38:42 UTC 
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.
Comment 8 Matthew Booth 2012-01-24 16:09:54 UTC 
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.
Comment 9 tingting zheng 2012-02-06 09:14:27 UTC 
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.
Comment 12 Matthew Booth 2012-04-10 15:02:30 UTC 
    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.
Comment 14 errata-xmlrpc 2012-06-20 12:41:32 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.

http://rhn.redhat.com/errata/RHBA-2012-0788.html
Note You need to log in before you can comment on or make changes to this bug.