Windows host support

[ciarancourtney]

This project could fill a contentious gap for cross-platform development. On Windows, many devs are now using WSL2 as a Linux dev environment with all the advantages that are usually lost when developing in a Linux guest i.e. automatic file sharing, networking etc.

When you enable WSL2 on Windows 10, you must enable the hyper-v hypervisor, this is what the actual WSL2 VM runs on. But this causes complications and performance issues when using other hypervisors like VirtualBox and VMware. Using vagrant-libvirt inside WSL2 is possible on Windows 11 (and through live patching on Win10) but the created networks aren't available in Windows and port forwarding doesn't work.

On Windows, its possible to install a msys2 compiled variant of QEMU from https://qemu.weilnetz.de/ which can use the 'whpx' accelerator on Windows, think KVM for Windows. Android devs would be familiar with this since that's what Android Studio uses to emulate and accelerate (x86 only) android devices.

But as of v0.1.9 of this plugin, it uses at least two features that the Windows version of QEMU doesn't support, namely:

1. The -nodaemonize arg
2. Use of unix sockets

So in combination with vagrant-sshfs for folder sync, this plugin could be a truly portable, non-root solution for vagrant on Mac, Windows and Linux.
Another win for this approach, is the seamless cross-arch support that it implies i.e. arm-on-x86 and vice-versa

Please consider this a placeholder ticket for others who hit this issue, and as a possible launch point from where these issues can be resolved.

[ppggff]

plan:

• add "control_port", "debug_port" to use tcp socket instead of unix socket (if set)
• use ruby's build-in socket support, remove the dependency on "nc"
• skip the "-nodaemonize" arg for Windows

[ciarancourtney]

Since my opening comment I've learned two additional data points:

1. Vagrant is planning on migrating to golang for v3.0 and they've already embedded a prototype binary along with the recently released v2.3, so I wonder what the future viability for Ruby plugins is...perhaps they will be parsed in some way, along with the planned HCL format.
2. Lima recently integrated barebones Windows host support, more info here [Windows Please] lima-vm/lima#909

I think their may still be room for this plugin, and if it aligns with Vagrant's v3 golang migration plan, it will be ready for that key cross-platform, cross-arch use case.

[ppggff]

Please try 0.3.0
See "Windows host" in Readme as example
I will reopen this issue if there still problem

[ciarancourtney]

Thanks @ppggff I tested 0.3.1 and got further, qemu is running in background but it looks like getpgid() is not implemented on Windows.

2: from C:/Users/admin/.vagrant.d/gems/2.7.6/gems/vagrant-qemu-0.3.1/lib/vagrant-qemu/driver.rb:27:in `get_current_state'
         1: from C:/Users/admin/.vagrant.d/gems/2.7.6/gems/vagrant-qemu-0.3.1/lib/vagrant-qemu/driver.rb:170:in `running?'
C:/Users/admin/.vagrant.d/gems/2.7.6/gems/vagrant-qemu-0.3.1/lib/vagrant-qemu/driver.rb:170:in `getpgid': getpgid() function is unimplemented on this machine (NotImplementedError)

[ppggff]

Thanks a lot.

Please try 0.3.2, I replaced getpgid() with kill(0, ) to check wether qemu process is running.

[ciarancourtney]

Yes my VM will boot in 0.3.2, it can set the hostname and ssh works, but with some caveats:

1. Needed to set cpu as qemu64 since default 'host' raised unable to find CPU model 'host' on Windows. Might be better to not set this at all, and let qemu infer it from machine type
2. Had some issues related to UEFI EDK2 firmware that are known issues on Windows, at least as of v7.1.0. Worked around this by rebuilding VM using default BIOS. Maybe using pflash for x86_64 like you do for aarch64 instead of -bios extra arg might fix this (untested)
3. Needed to comment out hardcoded -vga none I guess my VM (CentOS 6) requires a video card to boot, but difficult to diagnose without console! I think an option to easily enable GUI is needed soon.

Some initial bugs remaining, destroy fails with:

2: from C:/Users/admin/scoop/apps/vagrant/2.3.0/embedded/mingw64/lib/ruby/2.7.0/fileutils.rb:1474:in `platform_support'
         1: from C:/Users/admin/scoop/apps/vagrant/2.3.0/embedded/mingw64/lib/ruby/2.7.0/fileutils.rb:1460:in `block in remove_dir1'
C:/Users/admin/scoop/apps/vagrant/2.3.0/embedded/mingw64/lib/ruby/2.7.0/fileutils.rb:1460:in `rmdir': Directory not empty @ dir_s_rmdir - C:/Users/admin/git/packer/.vagrant/machines/c6/qemu/b0CWnXJBZSs (Errno::ENOTEMPTY)

[ppggff]

It's good news that it can boot. Please provide your Vagrantfile, I thinks I need to find a Windows machine to fix remained problems.

[ciarancourtney]

Heres the snippet of config I'm using for this plugin:

    config.vm.provider "qemu" do |qe,override|
        qe.arch = "x86_64"
        qe.machine = "type=q35,accel=whpx"
        qe.smp = "1"
        qe.memory = "1G"
        # default 'host' causes qemu-system-x86_64: unable to find CPU model 'host' on windows
        qe.cpu = "qemu64"  # max causes 'Unexpected VP exit code 4'
#         qe.extra_qemu_args = %w(-bios c:/Users/admin/scoop/apps/qemu/current/share/edk2-x86_64-code.fd)
        qe.net_device = "virtio-net-pci"
        qe.qemu_dir = "c:\\Users\\admin\\scoop\\apps\\qemu\\current\\share"
        qe.no_daemonize = true
        qe.control_port = 33333
        qe.debug_port = 33334
        override.vm.synced_folder ".", "/vagrant", type: 'sshfs'
      end

Sorry I won't be able to share the complete Vagrantfile since its internal, I'll setup a generic example perhaps using the stock CentOS 7 box like in your example. You could possibly use Github Actions to test functionality on all platforms, although without acceleration.