search

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

chown: cannot access '/dev/kvm': No such file or directory #3

Closed singhragvendra503 closed 9 months ago

singhragvendra503 commented 9 months ago

Successfully built 126d21846d82 Successfully tagged windows-in-docker-container_win10:latest Creating windows-in-docker-container_win10_1 ... done Attaching to windows-in-docker-container_win10_1 win10_1 | chown: cannot access '/dev/kvm': No such file or directory windows-in-docker-container_win10_1 exited with code 1 When i am comment out this line "chown root:kvm /dev/kvm" in startup.sh file I got error

Successfully built 399b4fa3089d Successfully tagged windows-in-docker-container_win10:latest Recreating windows-in-docker-container_win10_1 ... done Attaching to windows-in-docker-container_win10_1 win10_1 | Bringing machine 'default' up with 'libvirt' provider... win10_1 | ==> default: Checking if box 'peru/windows-server-2022-standard-x64-eval' version '20231001.01' is up to date... win10_1 | ==> default: Created volume larger than box defaults, will require manual resizing of win10_1 | ==> default: filesystems to utilize. win10_1 | ==> default: Uploading base box image as volume into Libvirt storage... ==> default: Creating image (snapshot of base box volume). win10_1 | ==> default: Creating domain with the following settings... win10_1 | ==> default: -- Name: _default win10_1 | ==> default: -- Description: Source: /Vagrantfile win10_1 | ==> default: -- Domain type: kvm win10_1 | ==> default: -- Cpus: 4 win10_1 | ==> default: -- Feature: acpi win10_1 | ==> default: -- Feature: apic win10_1 | ==> default: -- Feature: pae win10_1 | ==> default: -- Feature (HyperV): name=relaxed, state=on win10_1 | ==> default: -- Feature (HyperV): name=synic, state=on win10_1 | ==> default: -- Feature (HyperV): name=vapic, state=on win10_1 | ==> default: -- Feature (HyperV): name=vpindex, state=on win10_1 | ==> default: -- Clock offset: utc win10_1 | ==> default: -- Memory: 6000M win10_1 | ==> default: -- Base box: peru/windows-server-2022-standard-x64-eval win10_1 | ==> default: -- Storage pool: default win10_1 | ==> default: -- Image(vda): /var/lib/libvirt/images/_default.img, virtio, 100G win10_1 | ==> default: -- Disk driver opts: cache='default' win10_1 | ==> default: -- Graphics Type: spice win10_1 | ==> default: -- Graphics Websocket: win10_1 | ==> default: -- Graphics Port:
win10_1 | ==> default: -- Graphics IP:
win10_1 | ==> default: -- Graphics Password: Not defined win10_1 | ==> default: -- Video Type: qxl win10_1 | ==> default: -- Video VRAM: 16384 win10_1 | ==> default: -- Video 3D accel: false win10_1 | ==> default: -- Sound Type: ich6 win10_1 | ==> default: -- Keymap: en-us win10_1 | ==> default: -- TPM Backend: passthrough win10_1 | ==> default: -- INPUT: type=mouse, bus=ps2 win10_1 | ==> default: -- CHANNEL: type=spicevmc, mode= win10_1 | ==> default: -- CHANNEL: target_type=virtio, target_name=com.redhat.spice.0 win10_1 | ==> default: -- CHANNEL: type=unix, mode= win10_1 | ==> default: -- CHANNEL: target_type=virtio, target_name=org.qemu.guest_agent.0 win10_1 | ==> default: -- RNG device model: random

win10_1  | Error while creating domain: Error saving the server: Call to virDomainDefineXML failed: invalid argument: could not get preferred machine for /usr/bin/qemu-system-x86_64 type=kvm
ubuntu@instance-2:~$ docker-compose up
Creating network "ubuntu_default" with the default driver
Pulling win10 (ghcr.io/vaggeliskls/windows-in-docker-container:latest)...
latest: Pulling from vaggeliskls/windows-in-docker-container
aece8493d397: Pull complete
144679710325: Pull complete
619e9e7c184b: Pull complete
72a0c82c9b93: Pull complete
4895bb91dfcb: Pull complete
4a1083947222: Pull complete
4d5e7a535a97: Pull complete
Digest: sha256:d9915868b86f5415f008e9411d4582af8b000b56c5ecd75c94a8a5966730f5c0
Status: Downloaded newer image for ghcr.io/vaggeliskls/windows-in-docker-container:latest
Creating ubuntu_win10_1 ... done
Attaching to ubuntu_win10_1
win10_1  | chown: cannot access '/dev/kvm': No such file or directory
ubuntu_win10_1 exited with code 1
vaggeliskls commented 9 months ago

Thank you for reaching out, and I appreciate your feedback!

Based on the error log, it seems like you might be running the project on a Red Hat operating system. To ensure the project runs smoothly, it's essential to enable virtualization, specifically KVM (KVM kernel module).

Here are some references for further reading:

P.S. I've successfully battle-tested this project on Ubuntu servers. If you have any specific questions or encounter further issues, feel free to ask for assistance. Good luck with your project!

singhragvendra503 commented 9 months ago

i am running this container in ubuntu 20.04 lts GCP vm. I am using your docker image ghcr.io/vaggeliskls/windows-in-docker-container:latest i got same error Question: Is KVM package install in my host machine

@vaggeliskls Thanks for responding

vaggeliskls commented 9 months ago

As of my last knowledge, cloud providers generally did not widely support nested virtualization on virtual machines (VMs). Nested virtualization refers to the ability to run virtual machines within virtual machines. This feature is more commonly associated with running virtualization hypervisors, such as VMware ESXi or Microsoft Hyper-V, libvirt (current project), etc, within a virtual machine.

If you are specifically interested in nested virtualization on VMs in a cloud environment, I recommend checking the documentation and the latest updates from the specific cloud provider you are using (GCP). The level of support may vary based on the hypervisor technology used by the cloud provider and the type of virtual machine instances they offer.

PS. I can also verify that shared virtualization is also not supported on AWS ec2 instances. That is the reason that face issue when you tried to deploy this project

singhragvendra503 commented 9 months ago

i am build a docker image from your repo after that i am run that on ubuntu 22.04 lts

ragvendra@Macmini:~/Demo_project/windows-in-docker-container$ 

docker run     --env-file .env     --privileged     --cap-add NET_ADMIN     --cap-add SYS_ADMIN     --volume /sys/fs/cgroup:/sys/fs/cgroup     --device /dev/kvm     --device /dev/net/tun     --publish 3389:3389     --name win10     --interactive     --tty     window10:latest

<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:85:in require': cannot load such file -- winrm (LoadError) from <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:85:inrequire' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/plugins/communicators/winrm/shell.rb:9:in block in <top (required)>' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/util/silence_warnings.rb:8:insilence!' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/plugins/communicators/winrm/shell.rb:8:in <top (required)>' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/plugins/communicators/winrm/communicator.rb:6:inrequire_relative' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/plugins/communicators/winrm/communicator.rb:6:in <top (required)>' from <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:85:inrequire' from <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:85:in require' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/plugins/communicators/winrm/plugin.rb:15:inblock in ' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/registry.rb:27:in get' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/machine.rb:267:incommunicate' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/machine.rb:149:in initialize' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/vagrantfile.rb:81:innew' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/vagrantfile.rb:81:in machine' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/environment.rb:716:inmachine' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/plugin/v2/command.rb:180:in block in with_target_vms' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/plugin/v2/command.rb:204:inblock in with_target_vms' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/plugin/v2/command.rb:186:in each' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/plugin/v2/command.rb:186:inwith_target_vms' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/plugins/commands/up/command.rb:87:in execute' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/cli.rb:67:inexecute' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/lib/vagrant/environment.rb:290:in cli' from /usr/share/rubygems-integration/all/gems/vagrant-2.2.19/bin/vagrant:226:in<top (required)>' from /usr/bin/vagrant:25:in load' from /usr/bin/vagrant:25:in

'

vaggeliskls commented 9 months ago

Try providing more details about your running system (OS). You mention that you try to run from Ubuntu22, but I see that your hostname called MacMini.

  1. Is the ubuntu 22.04 lts version a VM ?
  2. What your host OS, Architecture (example: Ubuntu/Linux, amd64) ?
  3. Did you tried building from the provided Dockerfile ?
singhragvendra503 commented 9 months ago
  1. DISTRIB_ID=Ubuntu DISTRIB_RELEASE=22.04 DISTRIB_CODENAME=jammy DISTRIB_DESCRIPTION="Ubuntu 22.04.2 LTS"
  2. x86_64
  3. Yes i am building using provided Dockerfile
vaggeliskls commented 9 months ago

Thank you for your valuable feedback.

Upon investigating the issue you reported, I was able to replicate the problem and understand that it emerged after the Dockerfile upgrade was carried out to be compatible with Ubuntu 22.04 (Jammy).

The current issue seemed to stem from a version that is packaged in the official Ubuntu repository, interfering with the generation of the VM.

To resolve the issue, I have manually installed the most recent version of Vagrant. This should have effectively fixed the problem.

Please give it a try and inform me if you continue to face any difficulties.

Thanks again for making me aware of the issue.

Release: https://github.com/vaggeliskls/windows-in-docker-container/releases/tag/0.3.0 PR: https://github.com/vaggeliskls/windows-in-docker-container/pull/5