Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/24/2010 12:17 AM, Avi Kivity wrote:
On 03/23/2010 08:00 PM, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
I thought the monitor protocol *was* our API. If not, why not?

It is. But our API is missing key components like guest enumeration. So the fundamental topic here is, do we introduce these missing components to allow people to build directly to our interface or do we make use of the functionality that libvirt already provides if they can plumb our API directly to users.


Guest enumeration is another API.

Over the kvm call I suggested a qemu concentrator that would keep track of all running qemus, and would hand out monitor connections to users. It can do the enumeration (likely using qmp). Libvirt could talk to that, like it does with other hypervisors.


To elaborate

qemud
  - daemonaizes itself
  - listens on /var/lib/qemud/guests for incoming guest connections
  - listens on /var/lib/qemud/clients for incoming client connections
  - filters access according to uid (SCM_CREDENTIALS)
  - can pass a new monitor to client (SCM_RIGHTS)
  - supports 'list' command to query running guests
  - async messages on guest startup/exit

Then guests run with the wrong security context.

Regards,

Anthony Liguori

qemu
  - with -qemud option, connects to qemud (or maybe automatically?)

qemudc
  - command-line client, can access qemu human monitor


--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]