On 8/4/2020 at 12:46 PM, cleggypdc said:

Thanks for the help in this post, works fantastically. TL;DR of original, here's a step by step guide for creating a mount on VM creation (as of unraid 6.8.3).

1. In the "Unraid Share" section, select the unraid folder that you want to make mountable. This can be an individual share or a parent directory of the share for multiple. e.g `/mnt/user`
2. In the "Unraid Mount tag" section, enter a tag name, this can be anything and will be passed to the VM. e.g `myMountTag`
3. Complete VM setup, power on and install your VM OS or normal. The following steps require root/sudo user.
4. Make a backup copy of fstab in case you mess up your configuration `sudo cp /etc/fstab /etc/fstab.orig` 
5. Create a target mount directory where you want to mount your share e.g. `sudo mkdir /path/to/myMountedDir`
6. Edit `/etc/fstab` config by adding the following line to the end of the file, (change tag & path to your needs)
7. `myMountTag    /path/to/myMountedDir    9p    trans=virtio,version=9p2000.L,_netdev,rw    0    0`
8. Save fstab file and run `sudo mount -a` to check your mount works (there should be no output for on success)
9. You should now have a mounted share in your VM

Futher detail

For anyone new to unraid, looking for an explanation as to what the fstab values are, here is an explanation

<device>: myMountTag
<mount point>: /path/to/myMountedDir  
<file system type>: 9P (The protocol that QEMU uses for a VirtFS)
<options>: 
    trans=virtio,version=9p2000.L (our transport for this share will be over virtio, and we specify the 9P version (2000.L) because the default for QEMU is 2000.U. "L" has better support for ACLs, file locking and more efficient directory listing, deletion edge cases etc)
    _netdev (tells the system that this mount relies on the network, and to delay the mount until a network is enabled)
    rw (mount as read/write)
<dump>: 0 (disables backup via the dump command)
<pass num>: 0 (disable any error checking)

 

Cheers!

Is it normal that following this guide it asks me root permissions to delete or create files?

 

What is the best way to mount shares in a VM?
If the 9p protocol is not supposed to be good.

How can I mount the shares via SMB ?

They have "fixed" 9p performance in kernel 5.15 by increasing msize by default from 8kb to 128kb, but you can also use increased msize inside mount command like msize=262144.

Currently on arch linux vm kernel 5.15 i have speeds at 300mb/s which is what i have internally also so almost no loss in speed.

On 12/29/2021 at 1:51 PM, twiikker said:

They have "fixed" 9p performance in kernel 5.15 by increasing msize by default from 8kb to 128kb, but you can also use increased msize inside mount command like msize=262144.

Currently on arch linux vm kernel 5.15 i have speeds at 300mb/s which is what i have internally also so almost no loss in speed.

can you elaborate on this and perhaps give and stab example? I'm getting terrible performance like 12mb/s

 

8 hours ago, calmasacow said:

can you elaborate on this and perhaps give and stab example? I'm getting terrible performance like 12mb/s

 

I have been also running into issues with this again. Had this success but some transfer methods does not work with full speed. like if i transfer stuff with normal "cp" or "mv" commands its like 30-40MB/s but it i do it with rclone and disable server side moving with it then it works full speed.

 

for fstab i just have it without any msize parameters because latest kernel.

 

Im waiting for virtio-fs to be implemented in unraid to get it working easily.

Currently i just move smaller files with GUI with those 30MB/s speeds and larger files i use rclone.

Elaborating on what was posted above, 9p can be much faster than both NFS and SMB in my experience. For example, on a Debian 11.3 VM running on UnRAID, I mounted my iso share as ISO and did a quick test. The results on my NVME were not steller:
 

root@debian:/iso# dd if=/dev/zero of=/iso/output bs=8k count=1000k status=progress; rm -f /tmp/output
1024000+0 records in
1024000+0 records out
8388608000 bytes (8.4 GB, 7.8 GiB) copied, 84.6152 s, 99.1 MB/s

This is equivalent to ~max speed for a 1Gbps NIC. Not great.

After doing some reading though, I found that increasing the maximum bytes for the packet payload greatly improves performance and ultimately outstrips NFS & SMB. Reading the QEMU docs, I mounted as follows:

 

mount -t 9p -o trans=virtio ISO /iso -oversion=9p2000.L,posixacl,msize=104857600,cache=loose

 

Using fstab:

 

ISO             /iso            9p              trans=virtio,version=9p2000.L,posixacl,msize=104857600,cache=loose,_netdev,noauto,nobootwait,rw 0 0

 

 

Mount output (it seems 512k is the max msize in kernel 5.10.)

root@debian:/iso# mount | grep ISO
ISO on /iso type 9p (rw,relatime,dirsync,loose,access=client,posixacl,msize=512000,trans=virtio,_netdev)

 

The results (tested a few times):

 

root@debian:/iso# dd if=/dev/zero of=/iso/output bs=8k count=1000k status=progress; rm -f /iso/output
1024000+0 records in
1024000+0 records out
8388608000 bytes (8.4 GB, 7.8 GiB) copied, 6.66122 s, 1.3 GB/s

Note: This is completely anecdotal and your results may vary. For example, I used the `cache=loose` option, which is not intended for this use case and may have skewed my results. Also,

 

Additionally, the default msize in kernel 5.15+ is 128KiB, which should yield better performance. See links below.

 

Update: More recent results have been less favorable, with NFS shares averaging 313MB/s (1Gbps) and 9p performing at 191MB/s on average--all on the same array used as before. My initial findings were likely a fluke.

 

Further reading:

https://www.kernel.org/doc/Documentation/filesystems/9p.txt
https://wiki.qemu.org/Documentation/9psetup

https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg01003.html

Edited May 28, 20224 yr by utopianwrestler
Updated my comments with status=progress for realtime stats on the copy and acknowledge prior posts with similar info. Fixed CLI output formatting.

The following config in '/etc/fstab' is work for me, I'm using Alpine Linux VM,

 

Quote

harbor          /apps           9p      trans=virtio,version=9p2000.L,rw 0 0

 

If I add param '_netdev', the VM will not mount share dir

@utopianwrestler Hi, thank you very much for that! I can only confirm what was written. My share performance is great now, although I've removed the `cache` flag.

Edited October 14, 20223 yr by sjmller

Figured out how to fix loosing network access to the VM after adding a "Unraid Share" and "Unraid Mount Tag"

Before adding the Unraid Share and Mount Tag, switch to XML View and copy your "interface type..." section to notepad.
 

    <interface type='bridge'>
      <mac address='52:54:00:7e:XX:XX'/>
      <source bridge='br0'/>
      <target dev='vnet7'/>
      <model type='virtio-net'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

Note your "target dev", "alias name", and "address type" lines.

 

These 3 lines get omitted after configuring the Unraid Share and Unraid Mount Tag. Resulting in the loss of network connectivity (can't SSH to the VM)

 

My example: 
Unraid Share: /mnt/user/share
Unraid Mount Tag: UnraidShare

 

Add your Share and Mount tag.

After you add your edited your VM goto the XML View and look for "filesystem"
 

    <filesystem type='mount' accessmode='passthrough'>
      <source dir='/mnt/user/share/'/>
      <target dir='UnraidShare'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </filesystem>

 

Cut the entire "address type" line out of the "filesystem" section

      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>

That line belongs in the "interface type" xml block just below the "filesystem type". 
 

    <interface type='bridge'>
      <mac address='52:54:00:7e:XX:XX'/>
      <source bridge='br0'/>       
      <model type='virtio-net'/>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>   
    </interface>

 

Paste the "address type" from "filesystem" over the "address type" in "interface".
In my example the "bus" value goes from 0x03 to the 0x01.

 

From your notepad, copy the "target dev" line and paste below "source bridge" line.

 

From your notepad, copy the "alias name" line and paste below "model type" line.

It should look similar to this now:
 

    <filesystem type='mount' accessmode='passthrough'>
      <source dir='/mnt/user/share/'/>
      <target dir='UnraidShare'/>
    </filesystem>
    <interface type='bridge'>
      <mac address='52:54:00:7e:XX:XX'/>
      <source bridge='br0'/>
      <target dev='vnet9'/>
      <model type='virtio-net'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

 

Save changes.

 

Start your VM. You should have network access now.

If you go back into XML View on your running VM, you will notice two more new lines under "filesystem". 
"address type" and "alias name" now show up. Note that bus type is 0x03 now instead on 0x01. 
Unlcear for me if that even matters, but this does fix the network issue on Unraid 6.11.1
 

    <filesystem type='mount' accessmode='passthrough'>
      <source dir='/mnt/user/share/'/>
      <target dir='UnraidShare'/>
      <alias name='fs0'/>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </filesystem>
    <interface type='bridge'>
      <mac address='52:54:00:7e:XX:XX'/>
      <source bridge='br0'/>
      <target dev='vnet9'/>
      <model type='virtio-net'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

 

 

On 5/14/2018 at 7:09 PM, BobPhoenix said:

Then I added the following to fstab and rebooted:

unraid        /unraid            9p         trans=virtio,version=9p2000.L,_netdev,rw 0 0

I have no idea how or why but this still works perfectly. Thanks! Does it mount the disks correctly? I don't want to access them over slow SMB...

For anyone who uses virtiofs, use

tag  path/in/vm   virtiofs rw 0 0

instead. Do not forget to use `sudo chmod 777 path/in/vm` to let all users have the permission to r/w it.