From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: qemu-devel@nongnu.org,
Antonios Motakis <antonios.motakis@huawei.com>,
Greg Kurz <groug@kaod.org>
Subject: Re: [Qemu-devel] [libvirt patch] qemu: adds support for virtfs 9p argument 'vii'
Date: Tue, 7 May 2019 13:57:56 +0100 [thread overview]
Message-ID: <20190507125756.GP27205@redhat.com> (raw)
In-Reply-To: <1895198.u98Sn5qOsY@silver>
On Mon, May 06, 2019 at 07:58:28PM +0200, Christian Schoenebeck via Qemu-devel wrote:
> This is the counter part patch against latest libvirt git master head to
> support the 'vii' feature of patch 5, which introduces the XML config
> XML tag "important" on libvirt side.
>
> To stick with the previous example mentioned with patch 5, likewise
> libvirt XML configuration might then look like this:
>
> <domain type='kvm'>
> ...
> <devices>
> ...
> <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'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
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2019-05-07 12:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 14:37 [Qemu-devel] [PATCH v3 0/5] 9p: Fix file ID collisions Christian Schoenebeck via Qemu-devel
2019-04-23 11:30 ` [Qemu-devel] [PATCH v3 1/5] 9p: mitigates most QID path collisions Christian Schoenebeck via Qemu-devel
2019-05-07 12:42 ` Daniel P. Berrangé
2019-05-07 13:11 ` Christian Schoenebeck via Qemu-devel
2019-05-07 13:13 ` Daniel P. Berrangé
2019-04-23 11:35 ` [Qemu-devel] [PATCH v3 2/5] 9P: trivial cleanup of QID path collision mitigation Christian Schoenebeck via Qemu-devel
2019-05-07 12:43 ` Daniel P. Berrangé
2019-04-23 11:41 ` [Qemu-devel] [PATCH v3 3/5] 9p: persistency of QID path beyond reboots / suspensions Christian Schoenebeck via Qemu-devel
2019-05-03 14:51 ` [Qemu-devel] [PATCH v3 4/5] 9p: use variable length suffixes for inode mapping Christian Schoenebeck via Qemu-devel
2019-05-05 21:41 ` [Qemu-devel] [PATCH v3 5/5] 9p: adds virtfs 'vii' device parameter Christian Schoenebeck via Qemu-devel
2019-05-06 17:58 ` [Qemu-devel] [libvirt patch] qemu: adds support for virtfs 9p argument 'vii' Christian Schoenebeck via Qemu-devel
2019-05-07 9:55 ` Greg Kurz
2019-05-07 12:23 ` Christian Schoenebeck via Qemu-devel
2019-05-07 15:42 ` Greg Kurz
2019-05-07 16:16 ` Christian Schoenebeck via Qemu-devel
2019-05-17 8:40 ` Christian Schoenebeck via Qemu-devel
2019-05-17 12:30 ` Greg Kurz
2019-05-17 13:23 ` Christian Schoenebeck via Qemu-devel
2019-05-17 14:47 ` Greg Kurz
2019-05-17 20:53 ` Christian Schoenebeck via Qemu-devel
2019-05-20 14:05 ` Greg Kurz
2019-05-22 16:03 ` Christian Schoenebeck via Qemu-devel
2019-06-03 6:57 ` Greg Kurz
2019-06-03 9:17 ` Christian Schoenebeck via Qemu-devel
2019-05-07 12:57 ` Daniel P. Berrangé [this message]
2019-05-07 13:48 ` Christian Schoenebeck via Qemu-devel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190507125756.GP27205@redhat.com \
--to=berrange@redhat.com \
--cc=antonios.motakis@huawei.com \
--cc=groug@kaod.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).