From: "Daniel P. Berrange" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: quintela@redhat.com, qemu-devel@nongnu.org,
"Michael R. Hines" <mrhines@linux.vnet.ibm.com>,
owasserm@redhat.com, onom@us.ibm.com, abali@us.ibm.com,
mrhines@us.ibm.com, gokul@us.ibm.com, pbonzini@redhat.com,
chegu_vinod@hp.com
Subject: Re: [Qemu-devel] [PATCH v3 for-1.7] rdma: rename 'x-rdma' => 'rdma'
Date: Sat, 16 Nov 2013 10:32:45 +0000 [thread overview]
Message-ID: <20131116103245.GC9975@redhat.com> (raw)
In-Reply-To: <5286752A.4010105@redhat.com>
On Fri, Nov 15, 2013 at 12:25:30PM -0700, Eric Blake wrote:
> On 11/15/2013 10:40 AM, Michael R. Hines wrote:
> >
> > This is unrelated to RDMA - accessing the /dev/infiniband
> > device nodes is already supported by libvirt my modifying
> > the configuration file in /etc and that works just fine.
>
> http://wiki.qemu.org/Features/RDMALiveMigration states that you modify
> the .conf file to expose /dev/infiniband/rdma_cm and friends. Are all
> of these devices read/write accessible to non-root? Or is there going
> to be a problem if using user="qemu" group="qemu"? (That is, merely
> exposing the devices through cgroup device ACL checking may be
> insufficient if you can't access the devices when not running root/root).
>
> Libvirt can be patched so that the .conf file does not have to be edited
> (ie. change the defaults so that if cgroup_device_acl is not present in
> the conf file, the defaults could still let a domainaccess the
> /dev/infiniband devices).
There's also an SELinux question to deal with there. If multiple QEMUs
need concurrent access we can't do a selective grant of the device just
when migration is running - we would have to give all QEMU's access
all the time. This would be a case where doing FD passing of the
pre-opened devices might be a better option. It depends on what the
downsides are to giving QEMU access to the devices unconditionally.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
next prev parent reply other threads:[~2013-11-16 10:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-06 18:59 [Qemu-devel] [PATCH v3 for-1.7] rdma: rename 'x-rdma' => 'rdma' mrhines
2013-11-06 19:04 ` Eric Blake
2013-11-15 17:06 ` Daniel P. Berrange
2013-11-15 17:40 ` Michael R. Hines
2013-11-15 19:25 ` Eric Blake
2013-11-15 19:44 ` Michael R. Hines
2013-11-15 19:49 ` Eric Blake
2013-11-16 10:32 ` Daniel P. Berrange [this message]
2013-11-22 16:50 ` Paolo Bonzini
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=20131116103245.GC9975@redhat.com \
--to=berrange@redhat.com \
--cc=abali@us.ibm.com \
--cc=chegu_vinod@hp.com \
--cc=eblake@redhat.com \
--cc=gokul@us.ibm.com \
--cc=mrhines@linux.vnet.ibm.com \
--cc=mrhines@us.ibm.com \
--cc=onom@us.ibm.com \
--cc=owasserm@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.