Lucas Grosche · 8 min read

Windows 11 on Cloud Hypervisor

Ever wondered why the Cloud Hypervisor only supports Windows Server? In a recent project targeting Windows 11 VMs, we decided to test out the statement and evaluate Windows 11 support on Cloud Hypervisor.

Windows 11 on Cloud Hypervisor

Following Cloud Hypervisors documentation about Windows support, one can easily discern a few questions that arise in this undertaking.

  1. Can Windows 11 be installed with qemu?
    1. Can we find the correct drivers to do so?
    2. How to handle the TPM 2.0 requirement?
  2. Are there significant changes in the minimal requirements between Windows 11 and Server versions?
  3. How to handle the Windows Special Administration Console (SAC), that is only pre-installed on Windows server?
  4. If working, can this be applied to Windows 10 too?

In this blog, we are going to analyze these questions step by step and, foreshadowing the result, teach you how to install and use Windows 11 VMs running on Cloud Hypervisor.

Preparations

The requirements listed in the documentation for the Windows support are unphased: the host needs to have KVM enabled and the Windows guest image needs to be UEFI capable and use VirtIO drivers.

This is were we encountered the first difference between the tutorial and our demonstrator. Using the newest VirtIO driver ISO did not work under Windows 11. No driver was shown as compatible, and we therefore couldn’t add a drive for the installation. A bit of research led us to a few similar issues: one on VirtualBox, one with Windows Server 2025, and a more generalized issue that contains the current workaround: using the virtio-win11-attestation bundle. We created an ISO out of the amd64 files like so:

mkisofs -o virtio-win11.iso -J -R virtio-win11-attestation-0.1-258/amd64/

The second difference we encountered is the disk size image. After finishing the documentation guide to install Windows with using a 30GB image, our remaining disk image size was only about 7GBs, 12GB less than on the previously used Windows 11 VM on VirtualBox and without having anything else installed. This might have been a one-off issue, but in the case of the demonstrator it lead to issues with the guest application. In the end, we were able to increase the disk size and the partition. We recommend doing that from the start, since Windows 11 itself declares a minimal required 64GB of storage anyway.

Qemu installation process

With all the prerequisites set, we can start the qemu installation process. Since one of Windows 11 prerequisites is TPM 2.0 support, swtpm is needed during the installation process. The following commands can be executed to start a swtpm daemon:

nix-shell -p swtpm
# Create state directory
mkdir -p /tmp/mytpm1
# Start swtpm daemon for TPM 2.0 support
swtpm socket \
    --tpm2 \
    --ctrl type=unixio,path=/tmp/swtpm-sock \
    --tpmstate dir=/tmp/mytpm1 \
    --flags startup-clear \
    --log level=20 \
    --log file=/tmp/swtpm.log \
    --daemon

Like in the Windows support documentation mentioned above, we saved all image paths and directories as variables and executed the qemu command:

IMG_FILE=windows-disk.raw
WIN_ISO_FILE=26100.1742.240906-0331.ge_release_svc_refresh_CLIENT_IOT_LTSC_EVAL_x64FRE_en-us.iso
OVMF_DIR=./FV
VIRTIO_ISO_FILE=virtio-win11.iso

qemu-system-x86_64 \
    -machine q35,accel=kvm \
    -cpu host \
    -m 4G \
    -bios ./$OVMF_DIR/OVMF.fd \
    -cdrom ./$WIN_ISO_FILE \
    -drive file=./$VIRTIO_ISO_FILE,index=0,media=cdrom \
    -drive if=none,id=root,file=./$IMG_FILE \
    -device virtio-blk-pci,drive=root,disable-legacy=on \
    -device virtio-net-pci,netdev=mynet0,disable-legacy=on \
    -netdev user,id=mynet0 \
    -vga std \
    -smp 4 \
    -chardev socket,id=chrtpm,path=/tmp/swtpm-sock \
    -tpmdev emulator,id=tpm0,chardev=chrtpm \
    -device tpm-tis,tpmdev=tpm0

Here, additional differences to the original command are needed:

  • OVMF.fd instead of OVMF_CODE.fd, to avoid the following error: qemu: could not load PC BIOS '././FV/OVMF_CODE.fd'
  • -smp 4: we specify 4 cores, since the Windows 11 minimal requirement is 2 or more cores
  • the last three lines: TPM 2.0 support

Right after the start of qemu, it will ask you to press any key. If you miss the timing, the installation process will timeout and you need to try it again. After that, the normal Windows installation process will take place.

There are two things to remember here. Firstly, like mentioned in the Preparations chapter, you need to use the attestation drivers to be able to select a drive for the installation. You even need to navigate to the viostor directory, to be able to display and install them. Secondly, you should not load the network driver, if you don’t want to be forced to login into or create a Microsoft account. Simply click I don't have internet for now.

Configuring the Windows VM

Right after the installation, at the first boot still with qemu, you can configure the VM as wanted. Since Cloud Hypervisor does not have graphical support yet, it is recommended to at least configure network, SAC, RDP and/or SSH access. We will work through the first two in the next sub chapter and the latter two later on.

Network and SAC

Configuring the network is done by using the Device Manager. You should see an unknown network device. Using the CD you will be able to install the NetKvm driver.

For the internet to be working, which is needed for installing the SAC, you need to setup the DNS server on the guest and traffic forwarding on the host:

guest> netsh interface ipv4 set dns name="<interface name>" static 8.8.8.8
host> NET_DEV=<interface name>
host> sudo sysctl -w net.ipv4.ip_forward=1
host> sudo iptables -t nat -A POSTROUTING -o $NET_DEV -j MASQUERADE

When the network is working, you need to download and install the SAC. It is only pre-installed on server versions. This can be done via the Optional features in Windows. It is used to configure the IP for the Windows VM when running on Cloud Hypervisor.

RDP and SSH

Since Cloud Hypervisor doesn’t support video output, configuring RDP and/or SSH is necessary. It works exactly the same as written in the documentation. Depending on your needs, to be able to ping and ssh into the VM, there are still two things missing:

  • Allow ICMP from host to guest for ping:
netsh advfirewall firewall add rule \
    name="Allow ICMPv4" \
    protocol=icmpv4:8,any \
    dir=in \
    action=allow
  • Open the firewall for ssh:
New-NetFirewallRule `
    -Name sshd `
    -DisplayName "OpenSSH Server" `
    -Enabled True `
    -Direction Inbound `
    -Protocol TCP `
    -Action Allow `
    -LocalPort 22

Now you are good to go for Windows 11 on Cloud Hypervisor!

Windows 11 on Cloud Hypervisor

Now that the SAC is working, we can finally start the Windows 11 VM with Cloud Hypervisor. The command is similar to the one mentioned in the documentation, but the --tpm option is new:

cloud-hypervisor \
    --kernel $CH_OVMF_DIR/CLOUDHV.fd \
    --disk path=./$IMG_FILE \
    --cpus boot=1,kvm_hyperv=on \
    --memory size=4G \
    --serial tty \
    --console off \
    --net tap= \
    --tpm socket="/tmp/swtpm-sock"

Unfortunately, this panicked when executed for our demonstrator:

thread 'vcpu0' panicked at devices/src/tpm.rs:419:40:
range end index 4 out of range for slice of length 1
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
cloud-hypervisor: 4.723967s: <vcpu0> ERROR:vmm/src/cpu.rs:1182 -- vCPU thread panicked

Luckily, the Windows 11 VM boots without the --tmp option as well, so we continue without it for now.

If the setup was done correctly, you should boot into the SAC. There you can configure the guest just as described in the documentation:

SAC>i
<response with device index>
SAC>i <device-index> 192.168.249.2 255.255.255.0 192.168.249.1

With that, you can now RDP or SSH into the VM at 192.168.249.2.

CPU amount bug

The command to boot the VM with Cloud Hypervisor only provides 1 CPU. Especially when using RDP, you will figure out how sluggish this will feel. When trying to increase this value, we couldn’t boot anymore. Updating OVMF to the newest version fixed this issue.

Applicability to Windows 10

Even though the support for Windows 10 ends in a few months, the applicability of this guide to Windows 10 is still an interesting question. For now, we can only provide a few input points, since we didn’t run the test up until the end:

  • Normal VirtIO drivers can be used
  • No TPM 2.0 support needed
  • SAC can be installed as well
  • There is no RDP support for Windows 10 Home!

So if you don’t need RDP, or choose a different Windows 10 version, there is theoretically everything in line for Windows 10 running on Cloud Hypervisor as well!

Summary and future work

We followed the Cloud Hypervisors Windows Support documentation and adjusted it to work with Windows 11. We found answers to all the questions we asked at the beginning:

  1. Can Windows 11 be installed with qemu?
    • Yes, with the help of swtpm and the attestation drivers
  2. Are there significant changes in the minimal requirements between Windows 11 and Server versions?
    • Minimal, not significant: you need at least 2 cores and TPM 2.0
  3. How to handle the Windows Special Administration Console (SAC), that is only pre-installed on Windows server?
    • You can simply install and enable it via the Optional features even on Windows 11
  4. If working, can this be applied to Windows 10 too?
    • Maybe, we figured out some pointers, but did not see this till the end

For now, we opened up a PR on GitHub to the Windows Support documentation for Windows 11.

In the near future, we want to look into the TPM issue on Cloud Hypervisor, as well as automating as much as possible of this guide with the help of nix.

Feel free to reach out if you have any questions or pointers to the issues we are phasing!

Share: