vaggeliskls / windows-in-docker-container

Deploy and manage a Windows OS (x64) seamlessly using Vagrant VM, libvirt, and docker-compose. This innovative approach integrates smoothly into existing workflows, providing an efficient way of containerizing Windows OS for better resource allocation and convenience.
MIT License
57 stars 9 forks source link

Unsupported configuration: 'virtiofs' requires shared memory #9

Open Krakoer opened 5 months ago

Krakoer commented 5 months ago

Firstly, thanks for the project. Built with the Dockerfile, running on debian 12, I got

win10-1  | ==> default: Configuring virtiofs devices for shared folders...
win10-1  | DEBUG virtiofs: Attaching Synced Folder device with XML:
win10-1  | <filesystem type="mount" accessmode="passthrough">
win10-1  |   <driver type="virtiofs"></driver>
win10-1  |   <source dir="/"></source>
win10-1  |   <target dir="6666cd76f96956469e7be39d750cc7d"></target>
win10-1  | </filesystem>
win10-1  | 
win10-1  |  INFO interface: error: could not attach device because: Call to virDomainAttachDeviceFlags failed: unsupported configuration: 'virtiofs' requires shared memory
win10-1  |  INFO interface: error: ==> default: could not attach device because: Call to virDomainAttachDeviceFlags failed: unsupported configuration: 'virtiofs' requires shared memory
win10-1  | ==> default: could not attach device because: Call to virDomainAttachDeviceFlags failed: unsupported configuration: 'virtiofs' requires shared memory
win10-1  | ERROR warden: Error occurred: Error while attaching new device to domain. Call to virDomainAttachDeviceFlags failed: unsupported configuration: 'virtiofs' requires shared memory

I edited the Dockerfile and Vagrantfile to use the dev tools box because I want to use the VM to build some visual studio project in CI

Ask for more info if needed! Many thx

vaggeliskls commented 5 months ago

Hello @Krakoer,

Thank you for your feedback.

After trying to get through the steps you took, I also saw the problem you mentioned. It seems that using the sig-windows-dev-tools/windows-2019 box is causing some issues.

VirtioFS normally helps virtual machines use a directory tree on the host. But I ran into issues when trying to use shared folders on a Windows guest.

From what I can tell, this vagrant box may be the main issue when it's used in a container as our project describes.

I also noticed that the box you suggest requires several vagrant plugins to be installed. It might be a good idea to make sure these plugins are updated according to the needs in the box repository.

Here are some things we could try:

  1. Follow the instructions for the box repository very closely and try again.
  2. Try to find a similar box that helps solve this issue.
  3. Think about making your test environment with PowerShell scripts (custom or mentioned box scripts) inside the recommended vagrant for this project.

By the way, were you able to run the official box of this project on your Debian 12 system?

Looking forward to hearing from you. Thanks again for your helpful feedback.

Krakoer commented 5 months ago

Thanks for the quick reply. I tried using the Dockerfile, Vagrantfile and .env file of the repo from a clean debian 12 and got the following error:

win10-1  | /root/.vagrant.d/gems/3.1.4/gems/fog-libvirt-0.12.0/lib/fog/libvirt/requests/compute/vm_action.rb:7:in `create': Call to virDomainCreate failed: unable to open '/sys/fs/cgroup/machine/qemu-1-default.libvirt-qemu/': No such file or directory (Libvirt::Error)
Krakoer commented 4 months ago

Quick update, I tested your official box and got the same error :)

imKota commented 4 months ago

Same error on debian 12

win10_1  | /root/.vagrant.d/gems/3.1.4/gems/fog-libvirt-0.12.0/lib/fog/libvirt/requests/compute/vm_action.rb:7:in `create': Call to virDomainCreate failed: unable to open '/sys/fs/cgroup/machine/qemu-1-default.libvirt-qemu/': No such file or directory (Libvirt::Error)

docker-compose.yml

version: "3.9"

services:
  win10:
    image: ghcr.io/vaggeliskls/windows-in-docker-container:latest
    env_file: .env
    stdin_open: true
    tty: true
    privileged: true
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup
    ports:
      - 3389:3389
vaggeliskls commented 4 months ago

@imKota @Krakoer I genuinely appreciate your feedback. I regret to hear that you're running into some issues.

This project is battle tested on Ubuntu Servers.

Unfortunately, I don't have a Debian 12 system on bare metal to test this project. Despite this, I believe we can work together to address your concerns.

To facilitate a better diagnosis of the issue you're encountering, I'd like to gather a bit more information:

  1. Docker Version: Could you kindly inform me of the Docker version currently in use?
  2. Hosting Environment: Are you operating Debian 12 within a Virtual Machine (VM), by any chance?

For testing purposes, I also propose that you try a modified Docker Compose configuration I've put together. The configuration is as follows:

version: "3.9"

services:
  win10:
    image: ghcr.io/vaggeliskls/windows-in-docker-container:latest
    env_file: .env
    stdin_open: true
    tty: true
    privileged: true
    ports:
      - 3389:3389

In this new configuration, I've intentionally left out the cgroup volume. I'm curious to see whether this change affects your situation.

Once you've had a chance to test this, please report back on whether the issue has been resolved, or if the problem behaviour continues. Your insights will be valuable in helping us refine our project further.

Your cooperation and contributions to the project are sincerely appreciated. Looking forward to your response.

webzit commented 3 months ago

Looks like I might face the same issue. Host system is Debian 6.1.90-1. Docker runs as root and no other unusual configuration.

Docker version 26.1.3, build b72abbb Docker Compose version v2.27.0

I get following error with the test docker-compose (i.e. without cgroup volume)

win10-1  | ==> default: Creating shared folders metadata...
win10-1  | ==> default: Updating domain definition due to configuration change
win10-1  | ==> default: Starting domain.
win10-1  | ==> default: Removing domain...
win10-1  | ==> default: Deleting the machine folder
win10-1  | /root/.vagrant.d/gems/3.1.4/gems/fog-libvirt-0.12.0/lib/fog/libvirt/requests/compute/vm_action.rb:7:in `create': Call to virDomainCreate failed: unable to open '/sys/fs/cgroup/machine/qemu-1-default.libvirt-qemu/': No such file or directory (Libvirt::Error)
win10-1  |  from /root/.vagrant.d/gems/3.1.4/gems/fog-libvirt-0.12.0/lib/fog/libvirt/requests/compute/vm_action.rb:7:in `vm_action'
win10-1  |  from /root/.vagrant.d/gems/3.1.4/gems/fog-libvirt-0.12.0/lib/fog/libvirt/models/compute/server.rb:76:in `start'
win10-1  |  from /root/.vagrant.d/gems/3.1.4/gems/vagrant-libvirt-0.12.2/lib/vagrant-libvirt/action/start_domain.rb:608:in `call'