vng, run: add --root-guesttools option#472
Conversation
|
Hello, Thank you for this patch. The modification looks good to me, but I wonder if we cannot do better. Small detail: usually, we try not to modify the external rootfs. Here, it should be fine because the option is explicit. But maybe that can be a source of issues: "polluting the rootfs"? After this modification, 9p can still be used in other places, for some options, e.g. for the cache, |
|
Thanks, that makes sense. The current patch was intentionally narrow, it simply fixes the RHEL/no-9p case we hit by avoiding the guesttools 9p mount for external rootfs boots. Initially I considered a broader and more systematic approach that would avoid 9p completely unless forced, but I was a bit intimidated by the amount of hard-coded 9p mounts and the fact that I didn't fully understand all of them. So I need to look at this a bit more carefully, because cache, guesttools, busybox, and initmounts currently all go through the 9p path, and the existing virtiofs helper also wires shared memory/NUMA state for the rootfs export. I'll give it a try! |
Virtiofs exports need a shared guest memory backend, but that backend is a VM-level resource rather than a property of a single exported path. Move the memory backend setup into a small stateful helper and keep VirtioFSConfig focused on one virtiofs export. This preserves the current rootfs behavior while making it possible to add more virtiofs exports without trying to configure the same memory backend multiple times. Signed-off-by: Ralf Lici <ralf@mandelbit.com>
|
Hello, I dropped the The updated series keeps the rootfs virtiofs path unchanged, factors the shared memory setup so multiple virtiofs exports can reuse it, and switches the internal helper exports to virtiofs when 9p is not forced. This now covers guesttools, cache, busybox, initmounts, and vsockmount. |
External rootfs boots still uses 9p for the internal cache, guesttools and busybox exports even when the rootfs itself is exported through virtiofs. Add a helper that exports these internal host directories through virtiofs when virtiofs is available, falling back to 9p otherwise. Generate the matching guest mount command from the selected filesystem type, and keep the existing 9p path for --force-9p and virtiofs startup failures. This keeps guesttools, cache and busybox on the same no-9p path as the rootfs without changing the separate initmount and vsockmount handling yet. Signed-off-by: Ralf Lici <ralf@mandelbit.com>
Initmounts created from --rodir/--rwdir and the generated console script mount still use 9p even when virtiofs is otherwise available. Export these host directories through the shared hostfs helper so they use virtiofs when possible and fall back to 9p otherwise. Pass the selected filesystem type and access mode through mount-specific kernel arguments, and teach both guest init implementations to consume those arguments while preserving the existing 9p defaults. Older command lines that do not provide the new metadata continue to use the existing 9p defaults, and --force-9p still keeps the explicit 9p-only path. Signed-off-by: Ralf Lici <ralf@mandelbit.com>
|
Pylint was unhappy with the number of positional arguments in two helper call sites, so I updated the branch to silence that locally with targeted |
While testing kernel modules in distro root filesystems with virtme-ng, I hit a boot failure with AlmaLinux/RHEL-style kernels: the rootfs itself could be exposed without 9p, but virtme-ng still tried to mount its guest tools through 9p before starting
virtme-init.Those kernels do not provide 9p support, so the guest panicked before userspace could run, even though the root filesystem transport was otherwise usable.
This PR adds an explicit
--root-guesttools[=PATH]option for external-root users. It copies virtme’s guest tools into the rootfs and runs them from there, avoiding the extra 9p guesttools mount while leaving the current default behavior unchanged.