Upgrading Windows 10 on KVM vCPU bug?

[Gilbert Wilson]

The internet is telling me, and my experience just now seems to confirm, that in order to do a significant upgrade to Windows 10 (like the anniversary upgrade) you need to reduce the system from multiple vCPUs to 1 vCPU. Otherwise, you get the following error or other misbehavior:

0xC19000101 - 0x20017
The installation failed in the SAFE_OS phase with an error during BOOT operation.

I saw that error if I tried to install the update using the iso from Microsoft. If I used software update the system would just reboot and then tell me that the update failed to install on login without any error diagnostic codes. Event log wasn’t helpful, either. If the system tried to autoupdate and restart itself the VM would lock up (that’s how I initially discovered the issue). Event log wasn’t helpful here, either.

This seems kind of crazy to me. Do you really need to go through this process to upgrade Windows 10 running on KVM? (Note that regular, small updates haven’t presented any issues)

1. Shutdown VM
2. Reduce it’s vCPU assignments to 1
3. Boot VM
4. Do the update(s)
5. Shutdown VM
6. Re-assign additional vCPUs
7. Boot VM

If this is not the case, can someone point me at the right technique or documentation on troubleshooting this kind of issue? I’m not new to virtual machines, but I am new to hosting them on CentOS with KVM. Any pointers or other wisdom appreciated.

Gil

[Jason Healy]

On Feb 16, 2017, at 2:12 PM, Gilbert Wilson <gil...@watchhouse.org> wrote:
>
> If this is not the case, can someone point me at the right technique or documentation on troubleshooting this kind of issue? I’m not new to virtual machines, but I am new to hosting them on CentOS with KVM. Any pointers or other wisdom appreciated.

Don't know about the vCPU count, but we just got bitten last week trying to install Windows 10 on our (older) KVM cluster. The issue was that KVM by default uses a virtual CPU type (qemu64) that papers over the differences between processors (like AMD vs Intel). Thus, it's missing several processor features when the OS queries it. Here's a trimmed example (note the Model):

root@failbowl:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 2
model name : QEMU Virtual CPU version 1.1.2
flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni cx16 popcnt hypervisor lahf_lm
address sizes : 40 bits physical, 48 bits virtual

Windows 10 wants a machine that has certain features, so you have to tell KVM to either pass along a different fake CPU version, or (in newer versions of KVM), pass through the native processor used by the "host". Some of the posts I read said that this check only happens in the installer, so it's possible that's why you're seeing it on upgrade. I haven't tested that; I just fixed the cpu type and went with that as the permanent config.

Using a better definition is only a risk if you support live migration between VM hosts; if you have different hardware then a live migrate would screw up the guest when it suddenly realizes its running on a different type of processor. In our case, our VM hosts are homogenous so it's not a problem.

Run `kvm -cpu ?` to get a list of supported processor types and pick the best one that's supported by all VM hosts. In our case, we had to patch Ganeti (our hypervisor management) to use "-cpu SandyBridge" for the default as the argument pass-through wasn't available in the version we were running. You'll have to find a way to pass the option in depending on what tool you're using (raw arguments, a config file, etc).

Hope that helps!

Jason