Framework for libxl interfacing with qemu monitor

Framework for libxl interfacing with qemu monitor

[Chun Yan Liu]

Hi, list,

Is there any plan to add a framework for libxl interfacing with qemu monitor 
(like what libvrit does)? What's the status now?

Thanks,
Chunyan

Re: Framework for libxl interfacing with qemu monitor

[Ian Campbell]

On Tue, 2011-06-07 at 03:33 +0100, Chun Yan Liu wrote:
> Hi, list,
> 
> Is there any plan to add a framework for libxl interfacing with qemu monitor 
> (like what libvrit does)? What's the status now?

With the upstream qemu the plan is to use QMP to communicate with qemu
from libxl. Anthony Perard posted an early version of his patch to do
this yesterday.

For the qemu-xen tree most such communication is done via xenstore and
there is no current plan to integrate with the monitor (nor any need
AFAIK).

What are you trying to achieve?

Ian.

Re: Framework for libxl interfacing with qemu monitor

[Jim Fehlig]

Ian Campbell wrote:
> On Tue, 2011-06-07 at 03:33 +0100, Chun Yan Liu wrote:
>   
>> Hi, list,
>>
>> Is there any plan to add a framework for libxl interfacing with qemu monitor 
>> (like what libvrit does)? What's the status now?
>>     
>
> With the upstream qemu the plan is to use QMP to communicate with qemu
> from libxl. Anthony Perard posted an early version of his patch to do
> this yesterday.
>
> For the qemu-xen tree most such communication is done via xenstore and
> there is no current plan to integrate with the monitor (nor any need
> AFAIK).
>
> What are you trying to achieve?
>   

Plumb change-vnc-password through libxl IIRC.

Regards,
Jim

Re: Framework for libxl interfacing with qemu monitor

[Chun Yan Liu]

On Wednesday, June 08, 2011 02:54:33 AM Jim Fehlig wrote:
> Ian Campbell wrote:
> > On Tue, 2011-06-07 at 03:33 +0100, Chun Yan Liu wrote:
> >> Hi, list,
> >> 
> >> Is there any plan to add a framework for libxl interfacing with qemu
> >> monitor (like what libvrit does)? What's the status now?
> > 
> > With the upstream qemu the plan is to use QMP to communicate with qemu
> > from libxl. Anthony Perard posted an early version of his patch to do
> > this yesterday.
> > 
> > For the qemu-xen tree most such communication is done via xenstore and
> > there is no current plan to integrate with the monitor (nor any need
> > AFAIK).
> > 
> > What are you trying to achieve?
> 
> Plumb change-vnc-password through libxl IIRC.

Yes, we want to support change vnc password while VM is running. qemu monitor 
already has that part of code, if libxl will have interface with qemu monitor, 
then we can do change vnc password through libxl easily.

Thanks,
Chunyan

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Framework for libxl interfacing with qemu monitor

[Ian Campbell]

On Wed, 2011-06-08 at 07:24 +0100, Chun Yan Liu wrote:
> On Wednesday, June 08, 2011 02:54:33 AM Jim Fehlig wrote:
> > Ian Campbell wrote:
> > > On Tue, 2011-06-07 at 03:33 +0100, Chun Yan Liu wrote:
> > >> Hi, list,
> > >> 
> > >> Is there any plan to add a framework for libxl interfacing with qemu
> > >> monitor (like what libvrit does)? What's the status now?
> > > 
> > > With the upstream qemu the plan is to use QMP to communicate with qemu
> > > from libxl. Anthony Perard posted an early version of his patch to do
> > > this yesterday.
> > > 
> > > For the qemu-xen tree most such communication is done via xenstore and
> > > there is no current plan to integrate with the monitor (nor any need
> > > AFAIK).
> > > 
> > > What are you trying to achieve?
> > 
> > Plumb change-vnc-password through libxl IIRC.
> 
> Yes, we want to support change vnc password while VM is running. qemu monitor 
> already has that part of code, if libxl will have interface with qemu monitor, 
> then we can do change vnc password through libxl easily.

For upstream qemu the QMP interface is the right way to do this.

For qemu-xen we don't have an interface to the monitor and I think we do
not want to add one at this point. The way this works there is to add
support for a command via xenstore.c (see
xenstore_process_dm_command_event).

It's not clear that we want to keep adding new features to the qemu-xen
tree (the intention is that it becomes an essentially unchanging caompat
option once we move to uptream qemu) but this one seems useful enough?
What do the other maintainers think?

Ian.

Re: Framework for libxl interfacing with qemu monitor

[Stefano Stabellini]

On Wed, 8 Jun 2011, Ian Campbell wrote:
> On Wed, 2011-06-08 at 07:24 +0100, Chun Yan Liu wrote:
> > On Wednesday, June 08, 2011 02:54:33 AM Jim Fehlig wrote:
> > > Ian Campbell wrote:
> > > > On Tue, 2011-06-07 at 03:33 +0100, Chun Yan Liu wrote:
> > > >> Hi, list,
> > > >> 
> > > >> Is there any plan to add a framework for libxl interfacing with qemu
> > > >> monitor (like what libvrit does)? What's the status now?
> > > > 
> > > > With the upstream qemu the plan is to use QMP to communicate with qemu
> > > > from libxl. Anthony Perard posted an early version of his patch to do
> > > > this yesterday.
> > > > 
> > > > For the qemu-xen tree most such communication is done via xenstore and
> > > > there is no current plan to integrate with the monitor (nor any need
> > > > AFAIK).
> > > > 
> > > > What are you trying to achieve?
> > > 
> > > Plumb change-vnc-password through libxl IIRC.
> > 
> > Yes, we want to support change vnc password while VM is running. qemu monitor 
> > already has that part of code, if libxl will have interface with qemu monitor, 
> > then we can do change vnc password through libxl easily.
> 
> For upstream qemu the QMP interface is the right way to do this.
> 
> For qemu-xen we don't have an interface to the monitor and I think we do
> not want to add one at this point. The way this works there is to add
> support for a command via xenstore.c (see
> xenstore_process_dm_command_event).
> 
> It's not clear that we want to keep adding new features to the qemu-xen
> tree (the intention is that it becomes an essentially unchanging caompat
> option once we move to uptream qemu) but this one seems useful enough?
> What do the other maintainers think?

I think it is not worth it: after all if didn't have this feature before
I don't think we should add it now that we froze the tree.