It is indeed possible with KVM (reproduced below). You will need an UEFI implementation which you can download and there are a bunch of options you need to set for
qemu. The following should work on Intel chipsets with sound. You probably want to test without sound and networking first.
WARNING: do not attempt to boot your host OS or its drive in the VM or bad things will happen!
sudo qemu-system-x86_64 --enable-kvm -cpu host -m 2048 -smp 3 -mem-path /dev/hugepages \
-display sdl -vga qxl \
-device qemu-xhci,id=xhci \
-device virtio-tablet,wheel-axis=true \
-soundhw hda \
-netdev user,id=vmnic,smb=/temp \
-device virtio-net,netdev=vmnic \
-drive file=/usr/share/ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive file=$HOME/.config/qemu-windows.nvram,if=pflash,format=raw,unit=1 \
-drive file=/dev/sdb,index=0,media=disk,driver=raw \
For now I use sudo, because QEMU needs to access raw partitions from
/dev/sdb. The other, better way would be assigning a group to
/dev/sdb, setting up proper group permissions and adding me to that
-m 2048 -smp 3 says to allocate 2GB of RAM for the guest and use 3 CPU cores
-mem-path /dev/hugepages is better described in Arch wiki.
-display sdl -vga qxl Use SDL for rendering and window management in the host and QXL GPU device in the guest (there are QXL drivers for
-device qemu-xhci,id=xhci Enable USB3 support by emulating an XHCI controller
-device virtio-tablet,wheel-axis=true Emulate a tablet pointing device with mouse scroll support
-soundhw hda Emulate Intel HD Audio
netdev stuff Is for setting up network interface
This is a very important part. It loads OVMF UEFI firmware read-only
as the first Flash device. This firmware implements a UEFI bios and
allows running UEFI Shell or booting .efi bootloader for Windows
(bootmgfw.efi). This OVMF can be downloaded directly from the OVMF
project repo or if you are using Arch Linux, just install ovmf
-drive file=$HOME/.config/qemu-windows.nvram,if=pflash,format=raw,unit=1 this
loads a read-write NVRam flash image as the second virtual flash chip.
OVMF firmware uses this to store UEFI variables, .efi boot order, etc.
The default image can be copied from the OVMF setup (at
/usr/share/ovmf/x64/OVMF_VARS.fd in ovmf Arch linux package). It must
be a writable copy.
-drive file=/dev/sdb,index=0,media=disk,driver=raw Attaches my raw sdb block device to the virtual machine. That is used as a HDD for the
guest, it has Windows pre-installed there together with EFI partition.
-cdrom /opt/UefiShell.iso UEFI shell iso as a CDROM. Before OVMF nvram is properly configured to boot Windows by default, this will result in
booting into the EFI shell which allows to run .efi executables
manually. Windows can be run by just navigating into the EFI partition
and running the Windows efi loader –
I don’t know how to force Windows to write UEFI boot order. There
doesn’t seem to be a tool like efibootmgr on Windows. :D Windows would
set the UEFI boot order up randomly during some Windows Updates
(mostly when you don’t want it to touch your EFI setup). It eventually
set the EFI config up for me itself quite quickly. But if it fails,
you can try pressing ESC during TianoCore EFI boot to get to boot
menu. Or you can always boot Linux using the -cdrom command and use
efibootmgr to force the OVMF to boot the Windows loader entry for this
virtual machine by default. Usage of the efibootmgr command is out of
scope of this article and can be found in many online resources