Windows 10, kvm and iSCSI

Tempted to run Windows 10? Low on disk space? Have a NAS that supports iSCSI? Thinking what I’m thinking?

I found a really good tutorial on setting up iSCSI on a QNAP NAS, which got me most of the way there. But then I had to install Windows…

I spent some time fiddling with settings until it (mostly) worked, and thought to publish them here, in case they help anybody else who gets stuck. Here are the changes I had to make in virt-manager after following the above tutorial:

Overview:
Architecture: x86_64
Chipset: Q35                    (i440fx also works, see comments, thanks Kelvin!)
Emulator: qemu-system-x86_64

Processor: 2 CPUs
Memory: 2048MB

Boot options:
Enable Boot menu
[X] VirtIO Disk 1

CD-ROMs:
You'll need two CD-ROM drives:
- SCSI CDROM for the Windows install iso
- IDE CDROM for VirtIO drivers
You can change the disk bus under the "Advanced options".

Disk 1:
- Change Disk bus to VirtIO
- iSCSI should already be setup (see tutorial)

Controller SCSI:
Type: SCSI
Model: VirtIO SCSI

The remaining defaults are fine.
These worked for me, some of these may be sub-optimal though.

I used a SCSI CD-ROM drive for the Windows 10 install iso, because for some stranage reason KVM didn’t seem to like launching with multiple IDE devices. I would’ve liked to use the UEFI firmware rather than SeaBIOS, but by the time I thought about this it was too late to change that setting, so I’ll leave that for another time.

You’ll need the Fedora project’s Windows VirtIO drivers from this link, attach them to the IDE CD-ROM drive. You can get the Windows 10 Tech Preview iso from here.

During the installation, you’ll get some popups telling you that Windows can’t find the right drivers to access necessary hardware. First, you’ll need to use the “RedHat VirtIO SCSI pass-through controller” driver (to access the SCSI CD-ROM apparently), then later on the “RedHat VirtIO SCSI controller” one to access the disk.

VirtIO driver selection during Windows 10 Tech Preview installation.
VirtIO driver selection during Windows 10 Tech Preview installation.

One strange issue that I noticed was that after a reboot, booting from the HDD would fail; the VM would just go into a reboot loop. To work around this, I just used the “Force Off” power button option, and then started the VM again using the Play button – then the VM would boot again just fine.

Windows 10 kvm
The Windows 10 VM up and running

Oh, did I mention this is very slow? It’s probably at least partially my NAS’ fault, which only seems to do ~30MB/s read/write speeds over the network (RAID 1 – it’s mostly there for my critical data after all). But hey, it works. I’ll use it to debug some Windows client / Linux server stuff; it should be quicker than updating servers and rebooting to switch OSes.

18 Replies to “Windows 10, kvm and iSCSI”

  1. Hey, thanks for this…was struggling with KMODE_xxx error, the switch to using virtio for disk and rom seemed to solve the problem. Although I’ve only been able to complete the install using seabios…ovmf I am struggling to get to see the iso boot media! Did you ever make the switch to ovmf/efi?

    Just a note that the q35 chipset change is superfluous, ive just done both q35 and i440fx with no issues.

    Thanks K.

    1. Hi Kelvin,
      Thank you for your comment!

      No, I haven’t switched to ovmf yet, sorry. I updated the post to mention that the i440fx chipset also works, thank you for that nugget of information.
      Cheers,
      Michiel

    1. Hi Kelvin,

      I try to install Windows 10 OS on my Ubuntu server (with qemu + Webvirtmgr) but I had a issue.
      When the vm starts the system show a blu screen with the message:
      “Your PC ran into a problem and needs to restart. We’ll restart for you.
      if you’d like to know more, you can search online later for this error: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED”

      Could you please send me your xml file so I can check it?

      Thanks,
      Claudio

  2. Hi Michiel,

    Great article and tips.

    However, what exactly is the CLI command + arguments you are executing to get the installation going? I have following in a script:

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    #!/bin/sh

    ROOTDIR=/home/stack
    BOOTISO=${ROOTDIR}/J_CCSA_X64FRE_EN-GB_DV5.ISO
    VIRTISO=virtio-win-0.1.102.iso
    ROOTDISK=windisk.qcow2

    kvm -m 4096 -boot order=d -cdrom ${BOOTISO} -hda ${ROOTDISK} -drive file=${VIRTISO},index=3,media=cdrom -net nic,model=virtio -net user -nographic -vnc :3

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    And during the installation initial boot up I keep getting the blue screen with error
    SYSTEM_THREAD_EXCEPTION_NOT_HANDLED

    Is there anything I need to change with the way I start/execute kvm for installation?

    The above script works for WinXP and Win7 though.

    Thanks
    FXD

    1. Did you resolve this problem? If so, what did you do?

      Also, has anyone had trouble installing Win10 on real hardware and then AFTER installation switching to a virtual disk? In my configuration, I installed Win10 onto a physical partition and then I tried booting Win10 using the RedHat SCSI drivers with the hypervisor pointing to my previously installed Win10 image. This process works under win7. With win10, I get all the way through the real-mode boot process and then see a BSOD with an 0x7B error, “Inaccessible Boot Device”.

      Is it possible that the RedHat drivers only allow one to boot when Win10 is installed or upgraded using those drivers originally?

      Thanks for your advice and help.

  3. Has anyone had trouble installing Win10 on real hardware and then AFTER installation switching to a virtual disk? In my configuration, I installed Win10 onto a physical partition and then I tried booting Win10 using the RedHat SCSI drivers with the hypervisor pointing to my previously installed Win10 image. This process works under win7. With win10, I get all the way through the real-mode boot process and then see a BSOD with an 0x7B error, “Inaccessible Boot Device”.

    Is it possible that the RedHat drivers only allow one to boot when Win10 is installed or upgraded using those drivers originally?

    Thanks for your advice and help.

    1. Yeah, I think I had the same problem. While I don’t remember the exact error message, I couldn’t make booting a bare-metal-first installation work in a VM using the RedHat-signed drivers. I even tried to install the drivers manually (right-click .inf file, “install”), but that didn’t fix the problem. I figured that maybe Windows needs to actually know the device -> driver mapping for non-default drivers, so my workaround was to install Windows in the VM.

      At the time I didn’t find a solution for this via Google, but this Installing a Boot-Start Driver page looks good…

      1. Thank you for your reply. This was extremely helpful.

        I’m sorely tempted to doctor the Hypervisor to see if Win10 actually goes searching for the PCI device with which it was originally installed, just to see if our intuition is correct.

  4. After some further digging, finally got Windows 10 pro to install and boot up fine following some
    instructions here –> http://ubuntuforums.org/showthread.php?t=2289210.

    My start up CLI (for both installation and normal boot up) looks like the following:

    sudo taskset -c 0-7 kvm -name windows-10-pro -pidfile ./windows-10-pro.pid -cpu host -smp 8,sockets=1,cores=4,threads=2 -enable-kvm -machine type=pc-i440fx-trusty,accel=kvm -global PIIX4_PM.disable_s3=0 -m 16G -mem-path ./hugepages -mem-prealloc -balloon none -rtc clock=host,base=utc -soundhw hda -k en-us -boot order=c -drive id=disk0,if=none,cache=unsafe,format=qcow2,file=./win10disk.qcow2 -device driver=virtio-scsi-pci,id=scsi0 -device scsi-hd,drive=disk0 -drive id=cd0,if=none,format=raw,readonly,file=./WIN10PRO.ISO -device driver=ide-cd,bus=ide.0,drive=cd0 -drive id=virtiocd,if=none,format=raw,file=./virtio-win-0.1.102.iso -device driver=ide-cd,bus=ide.1,drive=virtiocd -monitor stdio -device piix3-usb-uhci -device usb-tablet -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 -vnc :10

    That runs fine as a standalone VM.

    However, after I add the system disk image win10disk.qcow2 to OpenStack and try to launch
    an instance (with sufficient vCPU, RAM & disk space to match) I start getting the same boot error
    again: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED.

    If anyone has had luck preparing Windows 10 Pro image to launch/run via OpenStack, please
    kindly advise.

    Thanks,
    FXD

    1. Sorry guys my real question how/what/where I need to make changes to have Nova
      firing up the Windows VM instances vs the standalone method I am doing now.

      Thanks,
      FXD

Leave a Reply

Your email address will not be published. Required fields are marked *