| 2018-08-24 21:48:22 |
Mike Pontillo |
description |
When running a KVM pod inside a LXD container, newly-composed VMs with macvlan attachments fail to start. While errors that occur during this process are not yet surfaced appropriately in MAAS (see bug #1788910), they can be found in the syslog, or when a user attempts to manually start the composed VM using virsh or virt-manager. An example error is as follows:
342: error : virNetDevMacVLanTapOpen:477 : cannot open macvtap tap device /dev/tap11: No such file or directory
After speaking with @stgraber about this issue, it turns out this happens because, when creating a macvtap interface inside a container, macvtap creates a non-namespaced character device with a name matching /dev/tap*, whose major/minor number cannot be correlated in advance with the generated device file name. (On a non-container host, this works fine due to devtmpfs.)
It's not clear to me how this issue might be fixed, but I wanted to record it here for future reference. We cannot work around the issue in MAAS. |
When running a KVM pod inside a LXD container, newly-composed VMs with macvlan attachments fail to start. While errors that occur during this process are not yet surfaced appropriately in MAAS (see bug #1788910), they can be found in the syslog, or when a user attempts to manually start the composed VM using virsh or virt-manager. An example error is as follows:
342: error : virNetDevMacVLanTapOpen:477 : cannot open macvtap tap device /dev/tap11: No such file or directory
After speaking with @stgraber about this issue, it turns out this happens because, when creating a macvtap interface inside a container, macvtap creates a non-namespaced character device with a name matching /dev/tap*, whose major/minor number cannot be correlated in advance with the generated device file name. (On a non-container host, this works fine due to devtmpfs.)
It's not clear to me how this issue might be fixed, but I wanted to record it here for future reference. We cannot work around the issue in MAAS.
We could prevent such attachments from being created, but that would require knowing in advance that the KVM pod is running inside a container. Not only do we not currently have that information, but that would also make it so that MAAS would not work in the event that this bug can be fixed elsewhere in the stack. |
|
