Sharing directories with virtual machines and libvirt

Let's say you want to make the directory /opt/test on your desktop machine visible to a virtual machine you are running with libvirt.

All you have to do is:

  • virsh edit myvmname, edit the XML of the VM to have something like:

    <domains ...>
      <devices ...>
        <filesystem type='mount' accessmode='passthrough'>
          <source dir='/opt/test'/>
          <target dir='testlabel'/>

    where /opt/test is the path you want to share with the VM, and testlabel is just a mnemonic of your choice.

    Make sure to set accessmode to something reasonable for your use case. According to the libvirt documentation, you can use:

    To have files created and accessed as the user running kvm/qemu. Uses extended attributes to store the original user credentials.
    To have files created and accessed as the user within kvm/qemu.
    Like passthrough, except failures in privileged operations are ignored.

    More details are provided in the next section. For now, just ensure that the new <filesystem> blobs are under <domains> and <devices>, order does not matter. Make also sure to save and exit.

  • Now start your virtual machine, with virsh start myvmname, and get a console.

  • Append a few lines to /etc/modules, to make sure the right modules are loaded:

     $ sudo -s
     # cat >>/etc/modules <<EOF
  • As a root user, load those modules:

     # service kmod start
  • Now you should be ready to mount the file system:

     # mount testlabel /opt/test -t 9p -o trans=virtio
  • et voila! If you cd /opt/test you should be able to see the files in your host physical machine.

  • if you want the file system to be automatically mounted at boot time, you can add something like:

     testlabel /opt/test            9p             trans=virtio    0       0

    to your /etc/fstab file.


If you get access denied to your files in /opt/test or can't write in the directory, the problem is generally related to the accessmode you picked, and the user your VM is running as.

Don't forget that at the end of the day a Virtual Machine is just another process on your host operating system. This process is running with the privileges of a particular user, and only able to change and touch the files that the specific user is given access to.

If you run ps aux |grep kvm or ps aux |grep qemu on your host system, you will most likely see that a system VM is running as user libvirt-qemu on Debian, while it is running as yourself if it is a session VM. If you are confused about system or session VMs, you should read this article.

This means that kvm/qemu will be able to read or write files or directories either as you, or as the libvirt-qemu user. Make sure that file privileges and directories are set accordingly.

To change the uid under which system VMs are run, you need to:

  • edit /etc/libvirt/qemu.conf
  • modify the parameters user and group to have the desired value.
  • restart libvirt daemons, with service restart libvirt-bin and service restart libvirt-guests.
  • it may also be necessary to restart any VM that is still running, to pick up the new user and group.

Alternatively, you may want to change accessmode to mapped or none.

Other posts

  • From PDF to interactive map Let's say you are thinking about moving to Rome in the near future. Let's say you have family, and you want to find all daycares within 30 mins by pu...
  • Using CLANG to generate HTML files Did you know that you can generate nicely formatted HTML file from your source code with clang ? I just noticed this by peeking in the source code, t...
  • SSL Certificates, Debian, and Java Recently, I tried to run a Java application on my Debian workstation that needed to establish SSL / HTTPs connections. But... as soon as a connection...
  • Getting started with VoIP I have been living in different countries for the last 10 years. Although I can get in touch with friends and family using gtalk, skype, or you name i...
  • The pitfalls of using ssh-agent, or how to use an agent safely In a previous article we talked about how to use ssh keys and an ssh agent . Unfortunately for you, we promised a follow up to talk about the securit...