FS#79224 - [lxd] cannot locate virtiofsd
Attached to Project:
Arch Linux
Opened by Alexandre Sicard (libricoleur) - Thursday, 27 July 2023, 22:19 GMT
Last edited by Toolybird (Toolybird) - Friday, 28 July 2023, 23:09 GMT
Opened by Alexandre Sicard (libricoleur) - Thursday, 27 July 2023, 22:19 GMT
Last edited by Toolybird (Toolybird) - Friday, 28 July 2023, 23:09 GMT
|
Details
Description:
LXD will only enable virtiofs for a shared folder if it can locate the virtiofsd binary in either: * /usr/lib/qemu/ which was used by the previous QEMU implementation of virtiofsd * /usr/libexec/ which is the default path for the new rust implementation Since Arch does not use /usr/libexec/, the current virtiofsd package installs the binary in /usr/lib/. As a result, the detection fails and LXD falls back to using a 9p mount, which is much slower. From my understanding, using /usr/libexec/ or patching LXD in Arch is not desirable, so the only way to fix this would be to request a change from upstream. Should I go and open a bug report? Additional info: * offending upstream code: https://github.com/canonical/lxd/blob/e43139513b457e95f40abe55a5b234009d122817/lxd/device/device_utils_disk.go#L443 Steps to reproduce: * create a LXD virtual machine eg. # lxc launch images:archlinux/current foobar --vm -s default # lxc config set foobar security.secureboot=false * add a shared folder to it eg. # lxc config device add foobar home disk source=/home path=/home * start the virtual machine eg. # lxc start foobar * check the filesystem used by the shared folder eg. # lxc exec foobar mount | grep /home Filesystem will be '9p' instead of 'virtiofs'. |
This task depends upon
Closed by Toolybird (Toolybird)
Friday, 28 July 2023, 23:09 GMT
Reason for closing: Upstream
Additional comments about closing: Thanks for that. Probably not worth a backport seeing as we'll reap the benefit next pkgver bump. Meanwhile, a symlink could workaround it.
Friday, 28 July 2023, 23:09 GMT
Reason for closing: Upstream
Additional comments about closing: Thanks for that. Probably not worth a backport seeing as we'll reap the benefit next pkgver bump. Meanwhile, a symlink could workaround it.
[1] https://www.phoronix.com/news/LXD-Maintainership-Canonical
Let's not be too pessimistic. LXD is a great tool and Canonical has put a lot of work and money into it, and seems to be committed to continuing doing so.