[libvirt] [Qemu-devel] Re: Libvirt debug API

[Daniel P. Berrange]

On Mon, Apr 26, 2010 at 09:26:55AM -0500, Anthony Liguori wrote:
> On 04/26/2010 08:58 AM, Daniel P. Berrange wrote:
> >On Mon, Apr 26, 2010 at 08:46:46AM -0500, Anthony Liguori wrote:
> >   
> >>On 04/26/2010 08:41 AM, Avi Kivity 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.
> >>     
> >NB, the "remote" protocol is no different from the "local" protocol
> >the unprivileged app uses to talk to the privileged daemon. The only
> >difference is unix sockets vs tcp sockets. We essentially get the
> >remote access capability for free as part of the protocol used between
> >the apps&  daemon.
> >   
> 
> I think Avi's concern is that if you expose direct launch, then that's 
> not really something you can usefully exploit in a remote protocol.
> 
> For instance, if you're local, you can call setuid() before invoking the 
> launch API whereas if you're remote, you will always launch guests as 
> the context of the remoting daemon.
> 
> This makes the remote API second-class in terms of functionality.

It is not entirely outside the realms of possibility to consider
making a way for libvirt to attach to a QEMU spawned by a 3rd
party. eg, 

    virsh qemu-attach /path/to/monitor PID

Converting the QEMU config back into Libvirt XML is not trivial,
but neither is it impossible. Particularly now we have the custom
<qemu:arg> syntax for things libvirt can't represent, we can 
simply use that for bits we can't reverse map to XML. There's also
the UUID/name uniqueness, but we could fail the attach operation 
if that wwas violated. This would let you use most of the other 
libvirt APIs remotely from any app, even if the VM was spawned by
another one.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|