12:47 p.m.
Hi,
I was wondering if multiple remote agents can access the same libvirtd. How
do we prevent conflicting commands from the different agents. Can different
access permission be set for the agents? (The documentation usually goes
over the case where one agent can access multiple libvirtd and not this
case)
Thanks
Arvind
3:08 p.m.
On 11.04.2013 19:47, arvind viswanathan wrote:
Hi,
I was wondering if multiple remote agents can access the same libvirtd.
How do we prevent conflicting commands from the different agents. Can
different access permission be set for the agents? (The documentation
usually goes over the case where one agent can access multiple libvirtd
and not this case)
Thanks
Arvind
Currently, there is no way to assign several permission bits to
different users. The only division we have is RO vs RW connection. In RO
connection users can just gather info about domains/networks/etc. while
in RW they can do anything. However, the ACLs have been requested
several times and they are being worked on. But it's a huge amount of
work so I don't really know the exact date when they're released. In
fact, it's Dan Berrange who's working on it so he has some more details.
Michal
4 a.m.
On Thu, Apr 11, 2013 at 10:08:31PM +0200, Michal Privoznik wrote:
On 11.04.2013 19:47, arvind viswanathan wrote:
> Hi,
> I was wondering if multiple remote agents can access the same libvirtd.
> How do we prevent conflicting commands from the different agents. Can
> different access permission be set for the agents? (The documentation
> usually goes over the case where one agent can access multiple libvirtd
> and not this case)
> Thanks
> Arvind
>
Currently, there is no way to assign several permission bits to
different users. The only division we have is RO vs RW connection. In RO
connection users can just gather info about domains/networks/etc. while
in RW they can do anything. However, the ACLs have been requested
several times and they are being worked on. But it's a huge amount of
work so I don't really know the exact date when they're released. In
fact, it's Dan Berrange who's working on it so he has some more details.
I hope to have some work proposed for merge in this release cycle,
though it wouldn't neccessarily be accepted in time.
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 :|
5 p.m.
On 04/11/2013 11:47 AM, arvind viswanathan wrote:
Hi,
I was wondering if multiple remote agents can access the same libvirtd. How
do we prevent conflicting commands from the different agents. Can different
access permission be set for the agents? (The documentation usually goes
over the case where one agent can access multiple libvirtd and not this
case)
Yes, multiple connections can access the same libvirtd (up to
max_clients in /etc/libvirt/libvirtd.conf), whether local or remote. In
fact, for some APIs, such as migration, you HAVE to have two connections
if you want to track progress of a long-running command (the second
connection can issue non-blocking queries while the first connection is
still blocked). Conflict between connection is prevented by using
proper mutex locking around critical sections within libvirtd.
As for differing permissions per connection, we aren't quite there yet.
Daniel Berrange is working on a patch series that will add fine-grained
ACL (access control list) permissions per connection, but it is not yet
complete; read the libvir-list(a)redhat.com archives for more details on
what will be added sometime in the future.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
5:18 p.m.
On 04/11/2013 04:00 PM, Eric Blake wrote:
On 04/11/2013 11:47 AM, arvind viswanathan wrote:
> Hi,
> I was wondering if multiple remote agents can access the same libvirtd. How
> do we prevent conflicting commands from the different agents. Can different
> access permission be set for the agents? (The documentation usually goes
> over the case where one agent can access multiple libvirtd and not this
> case)
Yes, multiple connections can access the same libvirtd (up to
max_clients in /etc/libvirt/libvirtd.conf), whether local or remote. In
fact, for some APIs, such as migration, you HAVE to have two connections
if you want to track progress of a long-running command (the second
connection can issue non-blocking queries while the first connection is
still blocked). Conflict between connection is prevented by using
proper mutex locking around critical sections within libvirtd.
If you are asking what happens if two competing connections attempt to
make to contradictory changes to a domain, the result is the same as
what happens when two processes try to modify the same file in the file
system. One of them will get there first. But while the end result may
not be predictable (it's hard to say which thread the OS scheduler will
wake up first), it is at least consistent (libvirtd should never crash
due to parallel API requests; and if the two requests are both to modify
the domain, the final state will match one of the requests, and either
both requests succeeded or the second one gracefully failed).
You already have to be prepared for errors, because any running guest
can decide that it is ready to shutdown, even without you asking it to.
No matter how careful you are, even if you have just a single
connection, you can hit races where one API says a domain is running,
and the next API fails because the domain is not running. [In fact,
races like these is why we added the virConnectListAllDomains API, so
that you can get more information with fewer API calls, and at least
minimize the number of points where you have to deal with such races].
Your code should always check for errors, no matter how many connections
are attempting to do things in parallel.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
4123
days inactive
4124
days old
4 comments
4 participants
participants (4)
-
arvind viswanathan -
Daniel P. Berrange -
Eric Blake -
Michal Privoznik