Re: [Qemu-devel] [libvirt patch] qemu: adds support for virtfs 9p argument 'vii'

[Christian Schoenebeck]

On Dienstag, 7. Mai 2019 13:57:56 CEST Daniel P. Berrangé wrote:
> >       ...
> >       <filesystem type='mount' accessmode='mapped'>
> >       
> >         <source dir='/vm/fs'/>
> >         <target dir='root'/>
> >         <important path='/var/shares'/>
> >         <important path='/tmp'/>
> >       
> >       </filesystem>
> >     
> >     </devices>
> >   
> >   </domain>
> > 
> > Like with the vii qemu virtfs command line argument, the order of the
> > "important" tag defines which one gets the highest inode namespace
> > (smallest generated suffix) on guest side.
> 
> Do we think anyone is likely to use this feature in the real world ?

I don't know if other people need it, that's one of the reasons why I am 
asking for a coarse high level feedback of the current v3 patch set before 
getting into the details.

The only thing I can say right now is that I must use this feature when 
running Samba to avoid all kinds of serious problems. And I could imagine 
inode namespace control to become more of an issue once nested virtualization 
becomes more popular.

> I'm not really a fan of the representation, because this is affecting
> guest ABI via a side effect of the ordering which is the kind of thing
> that has got us in trouble before.  If we need control over the IDs
> used for each mount point, then I tend to think we need to represent
> it explicitly such that the mgmt app sets the exact ID used.
> 
>      <pathid dir="/var/shares" id="0x1"/>
>      <pathid dir="/tmp" id="0x3"/>
> 
> this ensures that the IDs are still stable when adding or removing
> paths

Well, that would lead to the exact opposite of what you asked for. Because 
allowing admins to configure an exact ID (which I think you mean should be used 
as exact inode suffix by 9p then) would expose implementation details inside 
9pfs to config space, which are subject to change, might collide with 
implementation details, and requires implementation knowledge and extreme care 
by admins so they would pick appropriate IDs with "suffix-free" property which 
are guaranteed to create unique numbers in all cases:

https://en.wikipedia.org/wiki/Prefix_code

Also keep in mind that one fs device might end up having multiple suffixes.

Hence my suggestion was to only expose the bare minimum to config space 
regarding this issue: Asking (if required at all) admins which ones are the 
most critical pathes regarding inode namespace for their use cases, and 9p 
would then automatically generate appropriate suffixes for those mentioned by 
admin to achieve the highest inode namespace appropriately and in a safe way.

Plus for the "important path=" semantics I suggested you don't have have to 
use mount points BTW. You can use subdirs and even individual files and 9pfs 
would then automatically resolve the appropriate fs device of the given path. 
So e.g. when using nested virtualization, an admin inside a lower level guest 
does not even need to know the exact mount points on a higher level / host.

Best regards,
Christian Schoenebeck