With the promise that Qemu might have less overhead than Hyper-V or VirtualBox (indeed it observably is), I tried installing Qemu on Windows host and it turned out to be a frustrating nightmare. <\/p>\n\n\n\n
RANT: Linux is not free in the sense of free beer. The geniuses did the most sophisticated work for free but users pay time and energy cleaning after them (aka a support network dealing with daily frustrations) to make these inventions usable. There’s a company that does the clean up to make BSD (same umbrella as Linux\/Unix) usable and made a lot of money: it’s called Apple Computers (since Steve Jobs’ return). <\/span><\/p>\n\n\n\n qemu is just the core components. System integration (simplifying common use cases) is practically non-existent. Think of them as the one who produced an ASIC (chip) and the end-user happens to be the application engineers. There’s a few tutorials on qemu Linux hosts for moderately complex scenarios, but you are pretty much on your own trying to piece it altogether for Windows because there are some conceptual and terminology differences. The man page I stupidly went down the rabbit hole and drained my time on qemu. So I documented the quirks to help the next poor sap who has to get qemu running on Windows 10 host efficiently over Bridged-Adapter (VirtualBox lingo) networking mode<\/em>. <\/p>\n\n\n\n I typically want Bridged-Adapter<\/em> option from VirtualBox, which means the virtual NIC plugs into the same router as the host and just appears as another computer on the same network as host. This is broken into a few components in qemu and you have to manage them separately. Great for learning about how Bridged-Adapter<\/em> really works, but a lot of swearwords coming from people who just want to get basic things done.<\/p>\n\n\n\n Networking in QEMU is another can of worms if you deviate from the default SLIRP (user mode). I figured out how to work it, but the network bridge is faulty and it keeps crashing my windows with BSOD on bridge.sys with varying error tag. I have short glimpse of it working if I move very fast. Looks like the TAP driver is corrupting the memory as the bridge became very erratic that I see error messages deleting it and have persistent BSOD when the bridge starts after the VM hanged at the TAP bridge on boot. <\/p>\n\n\n\n I listed the steps below to show what should have been done to get the Bridge-Adapter (VirtualBox) equivalent function if there are no bugs in the software, but hell I’m throwing qemu for Windows to trash as it’s half-baked. <\/p>\n\n\n\n First, of all, you need to install OpenVPN to steal its TAP-Win32 virtual network card. It’s not VMware or Virtualbox that it’s part of the package. Qemu didn’t care to tightly integrate or test this driver properly.<\/p>\n\n\n\n Then you’ll need to bridge the “TAP-Windows Adapter (V#) for OpenVPN” with the network interface you want it to piggy back on.<\/p>\n\n\n\n The name of the TAP adapter is what you enter as You are not done yet! The bridged network (seen as one logical interface) is confused and it won’t be able to configure with your physical network card’s DHCP client. You’ll have to go to the properties of the Network Bridge and configure the IPv4 with static IP. <\/p>\n\n\n\n You can use After these are all set up the parameter to add to qemu call is:<\/p>\n\n\n\n There are complicated settings like Then welcome to the world of Windows 10 It’s like a damn research project finding out something is technically feasible but definitely not ready for production. Welcome to the FOSS jungle!<\/p>\n\n\n\n Postscript: I put Hyper-V back and realized it’s insanely slow with Linux Mint as it does not support hardware graphics acceleration. It’s night and day of a difference. Qemu is fast, but it crashes on Windows 10 if I bridge the adapters!<\/p>\n--help<\/code> for the qemu’s Windows host’s VM engine was blindly copied from the Linux hosts counterpart, so it tells you about qemu-bridge-helper<\/code> which is missing.<\/p>\n\n\n\n-accel hax<\/code><\/li><\/ul><\/li>qemu-system-{architecture name}.exe<\/code> is what runs the show<\/li>qemu-system-{architecture name}w<\/span>.exe<\/code> is the silent version of the above engine. Won’t give you a clue if something fails (like invalid parameters)<\/li>qemu-img create -f<\/code> {format such as vhd\/qcow2} {hard drive image name} {size like 10G}<\/li><\/ul><\/li>w<\/code><\/span> suffix) engine, likely to avoid a lingering command window, it also won’t tell you shit and why if something fails. It just ignores you when you press the start button unless all the stars align (you got everything right)<\/li><\/ul><\/li>-m 10G<\/code><\/li>-smp %NUMBER_OF_PROCESSORS%<\/code><\/li>-smp $(nproc)<\/code><\/li><\/ul><\/li>-hda<\/code> {virtual hard drive file name}<\/li>-cdrom<\/code> {iso file}<\/li><\/ul><\/li><\/ul>\n\n\n\n
\n\n\n\n![\"\"](\"https:\/\/wonghoi.humgar.com\/blog\/wp-content\/uploads\/2021\/05\/image.png\")
<\/figure>\n\n\n\nifname=<\/code> parameter of the tap interface in qemu command line. You have to tell qemu specifically which interface you want to engage in. I named the virtual network card as ‘TAP’ above. After bridging it looks like this:<\/p>\n\n\n\n![\"\"](\"https:\/\/wonghoi.humgar.com\/blog\/wp-content\/uploads\/2021\/05\/Bridge_TAP_Example-1.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/wonghoi.humgar.com\/blog\/wp-content\/uploads\/2021\/05\/Network-Bridge-Properties.png\")
<\/figure><\/li>![\"\"](\"https:\/\/wonghoi.humgar.com\/blog\/wp-content\/uploads\/2021\/05\/Internet-Protocol-Version-4-TCP_IPv4-Properties.png\")
<\/figure><\/li><\/ul><\/figure>\n\n\n\nipconfig \/all<\/code> to find out the relevant adapters acquired DHCP settings and enter it as static IP. Coordinate with the network administrator (can be yourself) to make sure you own that IP address so you won’t run into IP conflict if you reboot and somebody took your IP.<\/p>\n\n\n\n-nic tap,ifname=TAP<\/pre>\n\n\n\n
-net nic<\/code> and -netdev -device<\/code>. These are old ways to do it and have bloated abstractions. -nic<\/code> switch combined them into one switch.<\/p>\n\n\n\nbridge.sys<\/code> crashing frequently and you might get a short window of opportunity that it boots and ifconfig<\/code> acquire the IP address settings from your router (or network the physical adapter is on)’s DHCP server. <\/p>\n\n\n\n