** Summary changed: - [FFe] Should we drop the mknod for /dev/kvm in qemu-kvm-init + [FFe] Drop the mknod for /dev/kvm in qemu-kvm-init
** Description changed:
+ Summary / Rationale
+ -------------------
+
+ debian/qemu-kvm-init currently tries to create and set up the /dev/kvm
+ device node by hand whenever it detects it is running inside a container:
+
+ if systemd-detect-virt --quiet --container; then
+ mknod /dev/kvm c 10 232 || true
+ chown root:kvm /dev/kvm || true
+ chmod g+rw /dev/kvm || true
+ fi
+
+ This is an Ubuntu-specific delta originally introduced for LP #1370199 to
+ help containers that did not manage the KVM device node themselves.
+
+ It is no longer useful and is actively misleading today:
+
+ - Modern container runtimes (Docker, LXD, and others) set up the /dev/kvm
+ node automatically when the container is given access to the host's KVM
+ device, so the manual mknod is redundant.
+
+ - In common container types (e.g. LXD system containers) the mknod call
+ simply fails and does nothing useful, emitting confusing errors on boot:
+
+ qemu-kvm-init[2901]: mknod: Operation not permitted (os error 1)
+ qemu-kvm-init[2902]: chown: cannot dereference '/dev/kvm': No such file
or directory
+ qemu-kvm-init[2903]: chmod: cannot access '/dev/kvm': No such file or
directory
+
+ The correct way to expose KVM is to configure the container runtime
+ (e.g. `lxc config device add <name> kvm unix-char path=/dev/kvm`, or
+ `docker run --device /dev/kvm ...`), after which the node is present with
+ the right ownership without any help from qemu-kvm-init.
+
+ Removing the block deletes an obsolete Ubuntu delta and removes spurious
+ error output on container boots.
+
+ Scope of the change
+ -------------------
+
+ The change is minimal - it removes the 6-line code block to create the node
/dev/kvm
+
+ No other files, packaging behaviour, dependencies, or maintainer scripts
+ are affected. The change is entirely Ubuntu-specific and does not need to be
+ forwarded to Debian.
+
+ Test plan / verification
+ ------------------------
+
+ - Container with KVM correctly exposed (LXD unix-char device / Docker
+ --device /dev/kvm): /dev/kvm is present with correct ownership
+ (root:kvm, crw-rw----) created by the runtime; QEMU/KVM works.
+
+ - Container without KVM access: no change in functionality (KVM was never
+ usable there), and the misleading mknod/chown/chmod errors on boot are
+ gone.
+
+ Regression potential
+ --------------------
+
+ Low. The only environments that relied on the manual mknod were containers
+ where it either already worked (and where the runtime now provides the node
+ anyway) or where it failed silently with `|| true`. Any container that
+ correctly exposes /dev/kvm via its runtime continues to work; any container
+ that did not expose it was already unable to use KVM. Module loading
+ behaviour on non-container hosts is unchanged.
+
+ ---Original bug report---
+
This was introduced for bug 1370199 ages ago, I would expect this to no
more be functional - at least depending on the container type.
debian/qemu-kvm-init:
- 50 if systemd-detect-virt --quiet --container; then
- 51 mknod /dev/kvm c 10 232 || true
- 52 chown root:kvm /dev/kvm || true
- 53 chmod g+rw /dev/kvm || true
- 54 fi
+ 50 if systemd-detect-virt --quiet --container; then
+ 51 mknod /dev/kvm c 10 232 || true
+ 52 chown root:kvm /dev/kvm || true
+ 53 chmod g+rw /dev/kvm || true
+ 54 fi
At least in LXD system containers it will fail and do nothing useful
Jun 23 07:50:21 s qemu-kvm-init[2901]: mknod: Operation not permitted (os
error 1)
Jun 23 07:50:21 s qemu-kvm-init[2902]: chown: cannot dereference '/dev/kvm':
No such file or directory
Jun 23 07:50:21 s qemu-kvm-init[2903]: chmod: cannot access '/dev/kvm': No
such file or directory
In LXD you'd nowadays add a profile to expose it
- kvm:
- path: /dev/kvm
- type: unix-char
-
+ kvm:
+ path: /dev/kvm
+ type: unix-char
Would this still be helpful in other container types?
Or is this a relic from pre LXD and no more needed?
-
How does that look in other solutions?
Is it still worth to be kept?
** Description changed:
- Summary / Rationale
+ Summary / Rationale
-------------------
-
- debian/qemu-kvm-init currently tries to create and set up the /dev/kvm
- device node by hand whenever it detects it is running inside a container:
-
- if systemd-detect-virt --quiet --container; then
- mknod /dev/kvm c 10 232 || true
- chown root:kvm /dev/kvm || true
- chmod g+rw /dev/kvm || true
- fi
-
- This is an Ubuntu-specific delta originally introduced for LP #1370199 to
- help containers that did not manage the KVM device node themselves.
-
- It is no longer useful and is actively misleading today:
-
- - Modern container runtimes (Docker, LXD, and others) set up the /dev/kvm
- node automatically when the container is given access to the host's KVM
- device, so the manual mknod is redundant.
- - In common container types (e.g. LXD system containers) the mknod call
- simply fails and does nothing useful, emitting confusing errors on boot:
-
- qemu-kvm-init[2901]: mknod: Operation not permitted (os error 1)
- qemu-kvm-init[2902]: chown: cannot dereference '/dev/kvm': No such file
or directory
- qemu-kvm-init[2903]: chmod: cannot access '/dev/kvm': No such file or
directory
-
- The correct way to expose KVM is to configure the container runtime
- (e.g. `lxc config device add <name> kvm unix-char path=/dev/kvm`, or
- `docker run --device /dev/kvm ...`), after which the node is present with
- the right ownership without any help from qemu-kvm-init.
-
- Removing the block deletes an obsolete Ubuntu delta and removes spurious
- error output on container boots.
-
- Scope of the change
- -------------------
-
- The change is minimal - it removes the 6-line code block to create the node
/dev/kvm
-
- No other files, packaging behaviour, dependencies, or maintainer scripts
- are affected. The change is entirely Ubuntu-specific and does not need to be
- forwarded to Debian.
-
- Test plan / verification
- ------------------------
+ debian/qemu-kvm-init currently tries to create and set up the /dev/kvm
+ device node by hand whenever it detects it is running inside a container:
- - Container with KVM correctly exposed (LXD unix-char device / Docker
- --device /dev/kvm): /dev/kvm is present with correct ownership
- (root:kvm, crw-rw----) created by the runtime; QEMU/KVM works.
+ if systemd-detect-virt --quiet --container; then
+ mknod /dev/kvm c 10 232 || true
+ chown root:kvm /dev/kvm || true
+ chmod g+rw /dev/kvm || true
+ fi
- - Container without KVM access: no change in functionality (KVM was never
- usable there), and the misleading mknod/chown/chmod errors on boot are
- gone.
-
- Regression potential
- --------------------
-
- Low. The only environments that relied on the manual mknod were containers
- where it either already worked (and where the runtime now provides the node
- anyway) or where it failed silently with `|| true`. Any container that
- correctly exposes /dev/kvm via its runtime continues to work; any container
- that did not expose it was already unable to use KVM. Module loading
- behaviour on non-container hosts is unchanged.
-
+ This is an Ubuntu-specific delta originally introduced for LP #1370199 to
+ help containers that did not manage the KVM device node themselves.
+
+ It is no longer useful and is actively misleading today:
+
+ - Modern container runtimes (Docker, LXD, and others) set up the /dev/kvm
+ node automatically when the container is given access to the host's KVM
+ device, so the manual mknod is redundant.
+
+ - In common container types (e.g. LXD system containers) the mknod call
+ simply fails and does nothing useful, emitting confusing errors on boot:
+
+ qemu-kvm-init[2901]: mknod: Operation not permitted (os error 1)
+ qemu-kvm-init[2902]: chown: cannot dereference '/dev/kvm': No such file
or directory
+ qemu-kvm-init[2903]: chmod: cannot access '/dev/kvm': No such file or
directory
+
+ The correct way to expose KVM is to configure the container runtime
+ (e.g. `lxc config device add <name> kvm unix-char path=/dev/kvm`, or
+ `docker run --device /dev/kvm ...`), after which the node is present with
+ the right ownership without any help from qemu-kvm-init.
+
+ Removing the block deletes an obsolete Ubuntu delta and removes spurious
+ error output on container boots.
+
+ Scope of the change
+ -------------------
+
+ The change is minimal - it removes the 6-line code block to create the
+ node /dev/kvm
+
+ No other files, packaging behaviour, dependencies, or maintainer scripts
+ are affected. The change is entirely Ubuntu-specific and does not need to be
+ forwarded to Debian.
+
+ Test plan / verification
+ ------------------------
+
+ - Container with KVM correctly exposed (LXD unix-char device / Docker
+ --device /dev/kvm): /dev/kvm is present with correct ownership
+ (root:kvm, crw-rw----) created by the runtime; QEMU/KVM works.
+
+ - Container without KVM access: no change in functionality (KVM was never
+ usable there), and the misleading mknod/chown/chmod errors on boot are
+ gone.
+
+ The test build is available at:
+ https://launchpad.net/~hectorcao/+archive/ubuntu/lp2157949
+
+ I tested it in various containers Docker/LXD and do not see any
+ regression.
+
+ Regression potential
+ --------------------
+
+ Low. The only environments that relied on the manual mknod were containers
+ where it either already worked (and where the runtime now provides the node
+ anyway) or where it failed silently with `|| true`. Any container that
+ correctly exposes /dev/kvm via its runtime continues to work; any container
+ that did not expose it was already unable to use KVM. Module loading
+ behaviour on non-container hosts is unchanged.
+
---Original bug report---
This was introduced for bug 1370199 ages ago, I would expect this to no
more be functional - at least depending on the container type.
debian/qemu-kvm-init:
50 if systemd-detect-virt --quiet --container; then
51 mknod /dev/kvm c 10 232 || true
52 chown root:kvm /dev/kvm || true
53 chmod g+rw /dev/kvm || true
54 fi
At least in LXD system containers it will fail and do nothing useful
Jun 23 07:50:21 s qemu-kvm-init[2901]: mknod: Operation not permitted (os
error 1)
Jun 23 07:50:21 s qemu-kvm-init[2902]: chown: cannot dereference '/dev/kvm':
No such file or directory
Jun 23 07:50:21 s qemu-kvm-init[2903]: chmod: cannot access '/dev/kvm': No
such file or directory
In LXD you'd nowadays add a profile to expose it
kvm:
path: /dev/kvm
type: unix-char
Would this still be helpful in other container types?
Or is this a relic from pre LXD and no more needed?
How does that look in other solutions?
Is it still worth to be kept?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2157949
Title:
[FFe] Drop the mknod for /dev/kvm in qemu-kvm-init
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2157949/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
