Blame SOURCES/0081-v2v-Add-documentation-about-what-to-do-about-BSOD-0x.patch

0d20ef
From 81928e20d592ff7a30caf4c636cb851965a39b31 Mon Sep 17 00:00:00 2001
0d20ef
From: "Richard W.M. Jones" <rjones@redhat.com>
0d20ef
Date: Fri, 5 Dec 2014 15:04:03 +0000
0d20ef
Subject: [PATCH] v2v: Add documentation about what to do about BSOD 0x0000007B
0d20ef
 (RHBZ#1161333).
0d20ef
0d20ef
After a very long and trying episode with a Windows guest that refused
0d20ef
to boot after conversion, we managed to successfully boot it by
0d20ef
disabling Windows Group Policy.  It appears that Group Policy
0d20ef
prevented the virtio driver from being used.
0d20ef
0d20ef
Document this in the manual.
0d20ef
0d20ef
(cherry picked from commit be73b1750f3ce52ea137014083ed51d3b64f53a5)
0d20ef
---
0d20ef
 v2v/virt-v2v.pod | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
0d20ef
 1 file changed, 56 insertions(+)
0d20ef
0d20ef
diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod
0d20ef
index 5c97984..5f4d42e 100644
0d20ef
--- a/v2v/virt-v2v.pod
0d20ef
+++ b/v2v/virt-v2v.pod
0d20ef
@@ -623,6 +623,62 @@ below.
0d20ef
  Windows        Drivers are installed from /usr/share/virtio-win
0d20ef
                 if present
0d20ef
 
0d20ef
+=head1 WINDOWS
0d20ef
+
0d20ef
+=head2 Boot failure: 0x0000007B
0d20ef
+
0d20ef
+This boot failure is caused by Windows being unable to find or load
0d20ef
+the right disk driver (eg. C<viostor.sys>).  If you experience this
0d20ef
+error, here are some things to check:
0d20ef
+
0d20ef
+=over 4
0d20ef
+
0d20ef
+=item *
0d20ef
+
0d20ef
+First ensure that the guest boots on the source hypervisor before
0d20ef
+conversion.
0d20ef
+
0d20ef
+=item *
0d20ef
+
0d20ef
+Check you have the Windows virtio drivers available in
0d20ef
+C</usr/share/virtio-win>, and that virt-v2v did not print any warning
0d20ef
+about not being able to install virtio drivers.
0d20ef
+
0d20ef
+On S<Red Hat Enterprise Linux 7>, you will need to install the signed
0d20ef
+drivers available in the C<virtio-win> package.  If you do not have
0d20ef
+access to the signed drivers, then you will probably need to disable
0d20ef
+driver signing in the boot menus.
0d20ef
+
0d20ef
+=item *
0d20ef
+
0d20ef
+Check that you are presenting a virtio-blk interface (B<not>
0d20ef
+virtio-scsi and B<not> ide) to the guest.  On the qemu/KVM command
0d20ef
+line you should see something similar to this:
0d20ef
+
0d20ef
+ ... -drive file=windows-sda,if=virtio ...
0d20ef
+
0d20ef
+In libvirt XML, you should see:
0d20ef
+
0d20ef
+ <target dev='vda' bus='virtio'/>
0d20ef
+
0d20ef
+=item *
0d20ef
+
0d20ef
+Check that Windows Group Policy does not prevent the driver from being
0d20ef
+installed or used.  Try deleting Windows Group Policy before
0d20ef
+conversion.
0d20ef
+
0d20ef
+=item *
0d20ef
+
0d20ef
+Check there is no anti-virus or other software which implements Group
0d20ef
+Policy-like prohibitions on installing or using new drivers.
0d20ef
+
0d20ef
+=item *
0d20ef
+
0d20ef
+Enable boot debugging and check the C<viostor.sys> driver is being
0d20ef
+loaded.
0d20ef
+
0d20ef
+=back
0d20ef
+
0d20ef
 =head1 NETWORKS AND BRIDGES
0d20ef
 
0d20ef
 Guests are usually connected to one or more networks, and when
0d20ef
-- 
0d20ef
1.8.3.1
0d20ef