Bug: Hardcoded `virtiofsd` socket path `/tmp/vhostqemu` causes startup and concurrency failures in chrooted environments

[singhshresth26]

Description

When spawning a unikernel using the virtiofs shared filesystem, urunc starts the virtiofsd daemon on the host and configures the Virtual Machine Monitor (VMM) to connect to it via a Unix domain socket.

However, the socket path is hardcoded to /tmp/vhostqemu on the host, which introduces two major issues:

1. Chroot/Mount Namespace Isolation Failures: The VMM (QEMU or Cloud Hypervisor) is executed inside a chrooted/pivoted root directory (MonRootfs) where a private tmpfs is mounted at /tmp. Since the host-side virtiofsd creates the socket in the host's /tmp/vhostqemu, the chrooted VMM cannot find or connect to it at <MonRootfs>/tmp/vhostqemu, causing startup failure.
2. Concurrency Collisions: Since the path is globally static, multiple containers attempting to use virtiofs concurrently will collide on /tmp/vhostqemu.

---

Detailed Problem Breakdown

1. Chroot Isolation & Access Failure

In pkg/unikontainers/shared_fs.go (around line 59), a new isolated tmpfs is mounted under /tmp inside the monitor's root directory:

mounts = append(mounts, tmpfsMount("/tmp", tmpfsSize))

Later in the same file (around line 82), the virtiofsd daemon is spawned on the host (outside the VMM's chroot/mount namespace) and told to create its socket at /tmp/vhostqemu:

args := []string{
    "--socket-path=/tmp/vhostqemu",
    "--shared-dir",
    s.sharedPath,
}

Because virtiofsd runs on the host, it creates the socket file at /tmp/vhostqemu in the host's root filesystem.

Meanwhile, the VMM is executed inside the chrooted environment (MonRootfs) and told to connect to /tmp/vhostqemu:

• QEMU: "-chardev", "socket,id=char0,path=/tmp/vhostqemu" (pkg/unikontainers/hypervisors/qemu.go around line 140)
• Cloud Hypervisor: "--fs", "tag=fs0,socket=/tmp/vhostqemu" (pkg/unikontainers/hypervisors/cloud_hypervisor.go around line 135)

Inside the chroot, /tmp/vhostqemu refers to <MonRootfs>/tmp/vhostqemu. Since the socket was created on the host's /tmp/vhostqemu, the VMM fails to find the socket file and halts startup.

2. Concurrency Race Conditions

If multiple unikernel containers are started concurrently with virtiofs, they will all attempt to bind virtiofsd to the same socket path /tmp/vhostqemu on the host. This causes address-in-use errors, socket hijacking, and failed file sharing.

---

Affected Code

1. Spawning virtiofsd: pkg/unikontainers/shared_fs.go
2. QEMU CLI builder: pkg/unikontainers/hypervisors/qemu.go
3. Cloud Hypervisor CLI builder: pkg/unikontainers/hypervisors/cloud_hypervisor.go

---

Expected Behavior

urunc should create the socket file dynamically inside the container's own private monitor rootfs path (e.g. <MonRootfs>/tmp/vhostqemu), allowing the chrooted VMM to find it locally and enabling safe concurrent execution.

[cmainas]

Hello @singhshresth26 ,

as you mention everything takes place inside the monitor's rootfs execution environment. There is no shared socket and every monitor can connect to it.