[libvirt-users] Accessing libvirtd from multiple agents

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

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

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 :|

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@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

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
participants (4)
-
arvind viswanathan
-
Daniel P. Berrange
-
Eric Blake
-
Michal Privoznik