On 04/26/2010 04:46 PM, Anthony Liguori wrote:
(3) The system management application can certainly create whatever
context it wants to launch a vm from. It's comes down to who's
responsible for creating the context the guest runs under. I think
doing that at the libvirt level takes away a ton of flexibility from
the management application.
If you want to push the flexibility slider all the way to the right
you get bare qemu. It exposes 100% of qemu capabilities. And it's
not so bad these days. But it's not something that can be remoted.
As I mentioned earlier, remoting is not a very important use-case to me.
Does RHEV-M actually use the remote libvirt interface? I assume it'll
talk to vdsm via some protocol and vdsm will use the local libvirt API.
Yes.
I suspect most uses of libvirt are actually local uses.
I expect the same, though I'm sure a design goal was to make use of
libvirt be reasonable through the remote API. If we aren't able to
fulfil it, much of the value of libvirt goes away.
--
error compiling committee.c: too many arguments to function
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list