[Qemu-devel] converging around a single guest agent

[Qemu-devel] converging around a single guest agent

[Barak Azulay]

Hi,

One of the breakout sessions during the ovirt workshop [1] was about the guest 
tools, and focused mainly on the ovirt-guest-agent [2]. 

One of the issues discussed there, was the various existing guest agents out 
there, and the need to converge the efforts to a single agent that will serve 
all. 

while 4 agents were mentioned (Matahari, vdagent, qemu-ga & ovirt-guest-agent) 
during that discussion, we narrowed it down to 2 candidates:  

qemu-ga (aka virt-agent):
-------------------------
- Qemu specific - it was aimed for specific qemu needs (mainly quiesce guest 
I/O)
- Communicates directly with qemu  (not implemented yet) 
- Supports ? 
- So far linux only
- written in C

Ovirt-guest-agent:
------------------
- Has been around for a long time (~5 years) - considered stable
- Started as rhevm specific but evolved a lot since then
- Currently the only fully functional guest agent available for ovirt
- Written in python 
- Some VDI related sub components are written in C & C++
- Supports a well defined list of message types / protocol [3]
- Supports the folowing guest OSs
  Linux: RHEL5, RHEL6 F15, F16(soon) 
  Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)

  
The need to converge is obvious, and now that ovirt-guest-agent is opensourced 
under the ovirt stack, and since it already produces value for enterprise 
installations, and is cross platform, I offer to join hands around ovirt-
guest-agent and formalize a single code base that will serve us all.

git @ git://gerrit.ovirt.org/ovirt-guest-agent

Thoughts ?

Thanks
Barak Azulay

[1] http://www.ovirt.org/news-and-events/workshop
[2] http://www.ovirt.org/wiki/File:Ovirt-guest-agent.odp
[3] http://www.ovirt.org/wiki/Ovirt_guest_agent

Re: [Qemu-devel] converging around a single guest agent

[Alon Levy]

On Tue, Nov 15, 2011 at 07:24:40PM +0200, Barak Azulay wrote:
> Hi,
> 
> One of the breakout sessions during the ovirt workshop [1] was about the guest 
> tools, and focused mainly on the ovirt-guest-agent [2]. 
> 
> One of the issues discussed there, was the various existing guest agents out 
> there, and the need to converge the efforts to a single agent that will serve 
> all. 
> 
> while 4 agents were mentioned (Matahari, vdagent, qemu-ga & ovirt-guest-agent) 
> during that discussion, we narrowed it down to 2 candidates:  
> 
> qemu-ga (aka virt-agent):
> -------------------------
> - Qemu specific - it was aimed for specific qemu needs (mainly quiesce guest 
> I/O)
> - Communicates directly with qemu  (not implemented yet) 
> - Supports ? 
> - So far linux only
> - written in C
> 
> Ovirt-guest-agent:
> ------------------
> - Has been around for a long time (~5 years) - considered stable
> - Started as rhevm specific but evolved a lot since then
> - Currently the only fully functional guest agent available for ovirt
> - Written in python 
> - Some VDI related sub components are written in C & C++
> - Supports a well defined list of message types / protocol [3]
> - Supports the folowing guest OSs
>   Linux: RHEL5, RHEL6 F15, F16(soon) 

Does it have a seperate system level and user level part in Linux? It
does in windows, right? This is a requirment for replacing
vdagent+vdservice and the linux spice-agent, they both need to be active
during login stage, and then launch a new session agent when the user is
logged in. This is true for both linux and windows, although we have
completely different code bases for them:

 http://cgit.freedesktop.org/spice/linux/vd_agent/
 http://cgit.freedesktop.org/spice/win32/vd_agent/

linux is C, windows is C++ btw.

>   Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)
> 
>   
> The need to converge is obvious, and now that ovirt-guest-agent is opensourced 
> under the ovirt stack, and since it already produces value for enterprise 
> installations, and is cross platform, I offer to join hands around ovirt-
> guest-agent and formalize a single code base that will serve us all.
> 
> git @ git://gerrit.ovirt.org/ovirt-guest-agent
> 
> Thoughts ?
> 
> Thanks
> Barak Azulay
> 
> [1] http://www.ovirt.org/news-and-events/workshop
> [2] http://www.ovirt.org/wiki/File:Ovirt-guest-agent.odp
> [3] http://www.ovirt.org/wiki/Ovirt_guest_agent
> 

Re: [Qemu-devel] converging around a single guest agent

[Gal Hammer]

On 15/11/2011 19:33, Alon Levy wrote:

> Does it have a seperate system level and user level part in Linux? It

No. The ovirt-guest-agent have only one instance running in the system 
level.

	Gal.

Re: [Qemu-devel] converging around a single guest agent

[Perry Myers]

On 11/15/2011 12:24 PM, Barak Azulay wrote:
> Hi,
> 
> One of the breakout sessions during the ovirt workshop [1] was about the guest 
> tools, and focused mainly on the ovirt-guest-agent [2]. 
> 
> One of the issues discussed there, was the various existing guest agents out 
> there, and the need to converge the efforts to a single agent that will serve 
> all. 
> 
> while 4 agents were mentioned (Matahari, vdagent, qemu-ga & ovirt-guest-agent) 
> during that discussion, we narrowed it down to 2 candidates:  
> 
> qemu-ga (aka virt-agent):
> -------------------------
> - Qemu specific - it was aimed for specific qemu needs (mainly quiesce guest 
> I/O)
> - Communicates directly with qemu  (not implemented yet) 
> - Supports ? 
> - So far linux only
> - written in C
> 
> Ovirt-guest-agent:
> ------------------
> - Has been around for a long time (~5 years) - considered stable
> - Started as rhevm specific but evolved a lot since then
> - Currently the only fully functional guest agent available for ovirt
> - Written in python 
> - Some VDI related sub components are written in C & C++
> - Supports a well defined list of message types / protocol [3]
> - Supports the folowing guest OSs
>   Linux: RHEL5, RHEL6 F15, F16(soon) 
>   Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)
> 
>   
> The need to converge is obvious, and now that ovirt-guest-agent is opensourced 
> under the ovirt stack, and since it already produces value for enterprise 
> installations, and is cross platform, I offer to join hands around ovirt-
> guest-agent and formalize a single code base that will serve us all.
> 
> git @ git://gerrit.ovirt.org/ovirt-guest-agent
> 
> Thoughts ?

+1

The only downside that I concretely heard from folks re:
ovirt-guest-agent was that it is written in Python.  Two thoughts there:

1. On Windows it is compiled to an executable, so no separate python
   stack needed

2. ovirt-guest-agent is not very large and does not bring in a lot
   (any?) additional python class dependencies above/beyond the core
   language and interpreter.  Given this, the chances of dealing with
   python stack issues are probably minimal and also the overhead of
   including _just_ the base python interpreter in a given guest OS is
   very lightweight.  Core python RPM in F16 is about 80k.

Perry

Re: [Qemu-devel] converging around a single guest agent

[Subhendu Ghosh]

On 11/15/2011 01:01 PM, Perry Myers wrote:
> On 11/15/2011 12:24 PM, Barak Azulay wrote:
>> Hi,
>>
>> One of the breakout sessions during the ovirt workshop [1] was about the guest
>> tools, and focused mainly on the ovirt-guest-agent [2].
>>
>> One of the issues discussed there, was the various existing guest agents out
>> there, and the need to converge the efforts to a single agent that will serve
>> all.
>>
>> while 4 agents were mentioned (Matahari, vdagent, qemu-ga&  ovirt-guest-agent)
>> during that discussion, we narrowed it down to 2 candidates:
>>
>> qemu-ga (aka virt-agent):
>> -------------------------
>> - Qemu specific - it was aimed for specific qemu needs (mainly quiesce guest
>> I/O)
>> - Communicates directly with qemu  (not implemented yet)
>> - Supports ?
>> - So far linux only
>> - written in C
>>
>> Ovirt-guest-agent:
>> ------------------
>> - Has been around for a long time (~5 years) - considered stable
>> - Started as rhevm specific but evolved a lot since then
>> - Currently the only fully functional guest agent available for ovirt
>> - Written in python
>> - Some VDI related sub components are written in C&  C++
>> - Supports a well defined list of message types / protocol [3]
>> - Supports the folowing guest OSs
>>    Linux: RHEL5, RHEL6 F15, F16(soon)
>>    Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)
>>
>>
>> The need to converge is obvious, and now that ovirt-guest-agent is opensourced
>> under the ovirt stack, and since it already produces value for enterprise
>> installations, and is cross platform, I offer to join hands around ovirt-
>> guest-agent and formalize a single code base that will serve us all.
>>
>> git @ git://gerrit.ovirt.org/ovirt-guest-agent
>>
>> Thoughts ?
>
> +1
>
> The only downside that I concretely heard from folks re:
> ovirt-guest-agent was that it is written in Python.  Two thoughts there:
>
> 1. On Windows it is compiled to an executable, so no separate python
>     stack needed
>
> 2. ovirt-guest-agent is not very large and does not bring in a lot
>     (any?) additional python class dependencies above/beyond the core
>     language and interpreter.  Given this, the chances of dealing with
>     python stack issues are probably minimal and also the overhead of
>     including _just_ the base python interpreter in a given guest OS is
>     very lightweight.  Core python RPM in F16 is about 80k.
>
> Perry

If you needed WMI enablement on Windows - could you support that with this arch?

Re: [Qemu-devel] converging around a single guest agent

[Perry Myers]

On 11/15/2011 01:08 PM, Subhendu Ghosh wrote:
> On 11/15/2011 01:01 PM, Perry Myers wrote:
>> On 11/15/2011 12:24 PM, Barak Azulay wrote:
>>> Hi,
>>>
>>> One of the breakout sessions during the ovirt workshop [1] was about
>>> the guest
>>> tools, and focused mainly on the ovirt-guest-agent [2].
>>>
>>> One of the issues discussed there, was the various existing guest
>>> agents out
>>> there, and the need to converge the efforts to a single agent that
>>> will serve
>>> all.
>>>
>>> while 4 agents were mentioned (Matahari, vdagent, qemu-ga& 
>>> ovirt-guest-agent)
>>> during that discussion, we narrowed it down to 2 candidates:
>>>
>>> qemu-ga (aka virt-agent):
>>> -------------------------
>>> - Qemu specific - it was aimed for specific qemu needs (mainly
>>> quiesce guest
>>> I/O)
>>> - Communicates directly with qemu  (not implemented yet)
>>> - Supports ?
>>> - So far linux only
>>> - written in C
>>>
>>> Ovirt-guest-agent:
>>> ------------------
>>> - Has been around for a long time (~5 years) - considered stable
>>> - Started as rhevm specific but evolved a lot since then
>>> - Currently the only fully functional guest agent available for ovirt
>>> - Written in python
>>> - Some VDI related sub components are written in C&  C++
>>> - Supports a well defined list of message types / protocol [3]
>>> - Supports the folowing guest OSs
>>>    Linux: RHEL5, RHEL6 F15, F16(soon)
>>>    Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)
>>>
>>>
>>> The need to converge is obvious, and now that ovirt-guest-agent is
>>> opensourced
>>> under the ovirt stack, and since it already produces value for
>>> enterprise
>>> installations, and is cross platform, I offer to join hands around
>>> ovirt-
>>> guest-agent and formalize a single code base that will serve us all.
>>>
>>> git @ git://gerrit.ovirt.org/ovirt-guest-agent
>>>
>>> Thoughts ?
>>
>> +1
>>
>> The only downside that I concretely heard from folks re:
>> ovirt-guest-agent was that it is written in Python.  Two thoughts there:
>>
>> 1. On Windows it is compiled to an executable, so no separate python
>>     stack needed
>>
>> 2. ovirt-guest-agent is not very large and does not bring in a lot
>>     (any?) additional python class dependencies above/beyond the core
>>     language and interpreter.  Given this, the chances of dealing with
>>     python stack issues are probably minimal and also the overhead of
>>     including _just_ the base python interpreter in a given guest OS is
>>     very lightweight.  Core python RPM in F16 is about 80k.
>>
>> Perry
> 
> If you needed WMI enablement on Windows - could you support that with
> this arch?

I'm not a WMI expert, but google search first result on 'python WMI'
turned up:

http://timgolden.me.uk/python/wmi/index.html

Re: [Qemu-devel] converging around a single guest agent

[Barak Azulay]

On Tuesday 15 November 2011 21:45:42 Perry Myers wrote:
> On 11/15/2011 01:08 PM, Subhendu Ghosh wrote:
> > On 11/15/2011 01:01 PM, Perry Myers wrote:
> >> On 11/15/2011 12:24 PM, Barak Azulay wrote:
> >>> Hi,
> >>> 
> >>> One of the breakout sessions during the ovirt workshop [1] was about
> >>> the guest
> >>> tools, and focused mainly on the ovirt-guest-agent [2].
> >>> 
> >>> One of the issues discussed there, was the various existing guest
> >>> agents out
> >>> there, and the need to converge the efforts to a single agent that
> >>> will serve
> >>> all.
> >>> 
> >>> while 4 agents were mentioned (Matahari, vdagent, qemu-ga&
> >>> ovirt-guest-agent)
> >>> during that discussion, we narrowed it down to 2 candidates:
> >>> 
> >>> qemu-ga (aka virt-agent):
> >>> -------------------------
> >>> - Qemu specific - it was aimed for specific qemu needs (mainly
> >>> quiesce guest
> >>> I/O)
> >>> - Communicates directly with qemu  (not implemented yet)
> >>> - Supports ?
> >>> - So far linux only
> >>> - written in C
> >>> 
> >>> Ovirt-guest-agent:
> >>> ------------------
> >>> - Has been around for a long time (~5 years) - considered stable
> >>> - Started as rhevm specific but evolved a lot since then
> >>> - Currently the only fully functional guest agent available for ovirt
> >>> - Written in python
> >>> - Some VDI related sub components are written in C&  C++
> >>> - Supports a well defined list of message types / protocol [3]
> >>> - Supports the folowing guest OSs
> >>> 
> >>>    Linux: RHEL5, RHEL6 F15, F16(soon)
> >>>    Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)
> >>> 
> >>> The need to converge is obvious, and now that ovirt-guest-agent is
> >>> opensourced
> >>> under the ovirt stack, and since it already produces value for
> >>> enterprise
> >>> installations, and is cross platform, I offer to join hands around
> >>> ovirt-
> >>> guest-agent and formalize a single code base that will serve us all.
> >>> 
> >>> git @ git://gerrit.ovirt.org/ovirt-guest-agent
> >>> 
> >>> Thoughts ?
> >> 
> >> +1
> >> 
> >> The only downside that I concretely heard from folks re:
> >> ovirt-guest-agent was that it is written in Python.  Two thoughts there:
> >> 
> >> 1. On Windows it is compiled to an executable, so no separate python
> >> 
> >>     stack needed
> >> 
> >> 2. ovirt-guest-agent is not very large and does not bring in a lot
> >> 
> >>     (any?) additional python class dependencies above/beyond the core
> >>     language and interpreter.  Given this, the chances of dealing with
> >>     python stack issues are probably minimal and also the overhead of
> >>     including _just_ the base python interpreter in a given guest OS is
> >>     very lightweight.  Core python RPM in F16 is about 80k.


The ovirt-guest-agent also depends on pywin32 package 
(http://sourceforge.net/projects/pywin32/files/) for windows platforms 


> >> 
> >> Perry
> > 
> > If you needed WMI enablement on Windows - could you support that with
> > this arch?
> 
> I'm not a WMI expert, but google search first result on 'python WMI'
> turned up:
> 
> http://timgolden.me.uk/python/wmi/index.html

As the ovirt-guest-agent the above package uses also pywin32.

Re: [Qemu-devel] converging around a single guest agent

[Anthony Liguori]

On 11/15/2011 11:24 AM, Barak Azulay wrote:
> Hi,
>
> One of the breakout sessions during the ovirt workshop [1] was about the guest
> tools, and focused mainly on the ovirt-guest-agent [2].
>
> One of the issues discussed there, was the various existing guest agents out
> there, and the need to converge the efforts to a single agent that will serve
> all.
>
> while 4 agents were mentioned (Matahari, vdagent, qemu-ga&  ovirt-guest-agent)
> during that discussion, we narrowed it down to 2 candidates:
>
> qemu-ga (aka virt-agent):
> -------------------------
> - Qemu specific - it was aimed for specific qemu needs (mainly quiesce guest
> I/O)
> - Communicates directly with qemu  (not implemented yet)
> - Supports ?
> - So far linux only

But very easy to port.  It also should work on just about any Unix since its 
only dependency is glib.  Also:

  - exists in the QEMU repository

> - written in C
>
> Ovirt-guest-agent:
> ------------------
> - Has been around for a long time (~5 years) - considered stable
> - Started as rhevm specific but evolved a lot since then
> - Currently the only fully functional guest agent available for ovirt
> - Written in python
> - Some VDI related sub components are written in C&  C++
> - Supports a well defined list of message types / protocol [3]
> - Supports the folowing guest OSs
>    Linux: RHEL5, RHEL6 F15, F16(soon)
>    Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)

The guest agent we use in QEMU exists to implement QEMU specific functionality. 
  I think one challenge that comes up here is that the ovirt guest agent has a 
very different scope than the QEMU agent.  The ovirt guest agent has a very 
ovirt-engine centric scope.

> The need to converge is obvious, and now that ovirt-guest-agent is opensourced
> under the ovirt stack, and since it already produces value for enterprise
> installations, and is cross platform, I offer to join hands around ovirt-
> guest-agent and formalize a single code base that will serve us all.

You are basically saying, stop what you guys are doing and work on our code 
because it's better.  That's not really convergence.

If you want to talk about convergence, the discussion should start around 
collecting requirements.  We can then figure out if the two sets of requirements 
are strictly overlapping or if there are any requirements that are fundamentally 
in opposition.

Regards,

Anthony Liguori

Re: [Qemu-devel] converging around a single guest agent

[Ayal Baron]

----- Original Message -----
> On 11/15/2011 11:24 AM, Barak Azulay wrote:
> > Hi,
> >
> > One of the breakout sessions during the ovirt workshop [1] was
> > about the guest
> > tools, and focused mainly on the ovirt-guest-agent [2].
> >
> > One of the issues discussed there, was the various existing guest
> > agents out
> > there, and the need to converge the efforts to a single agent that
> > will serve
> > all.
> >
> > while 4 agents were mentioned (Matahari, vdagent, qemu-ga&
> >  ovirt-guest-agent)
> > during that discussion, we narrowed it down to 2 candidates:
> >
> > qemu-ga (aka virt-agent):
> > -------------------------
> > - Qemu specific - it was aimed for specific qemu needs (mainly
> > quiesce guest
> > I/O)
> > - Communicates directly with qemu  (not implemented yet)
> > - Supports ?
> > - So far linux only
> 
> But very easy to port.  It also should work on just about any Unix
> since its
> only dependency is glib.  Also:
> 
>   - exists in the QEMU repository
> 
> > - written in C
> >
> > Ovirt-guest-agent:
> > ------------------
> > - Has been around for a long time (~5 years) - considered stable
> > - Started as rhevm specific but evolved a lot since then
> > - Currently the only fully functional guest agent available for
> > ovirt
> > - Written in python
> > - Some VDI related sub components are written in C&  C++
> > - Supports a well defined list of message types / protocol [3]
> > - Supports the folowing guest OSs
> >    Linux: RHEL5, RHEL6 F15, F16(soon)
> >    Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)
> 
> The guest agent we use in QEMU exists to implement QEMU specific
> functionality.
>   I think one challenge that comes up here is that the ovirt guest
>   agent has a
> very different scope than the QEMU agent.  The ovirt guest agent has
> a very
> ovirt-engine centric scope.
> 
> > The need to converge is obvious, and now that ovirt-guest-agent is
> > opensourced
> > under the ovirt stack, and since it already produces value for
> > enterprise
> > installations, and is cross platform, I offer to join hands around
> > ovirt-
> > guest-agent and formalize a single code base that will serve us
> > all.
> 
> You are basically saying, stop what you guys are doing and work on
> our code
> because it's better.  That's not really convergence.
> 
> If you want to talk about convergence, the discussion should start
> around
> collecting requirements.  We can then figure out if the two sets of
> requirements
> are strictly overlapping or if there are any requirements that are
> fundamentally
> in opposition.

Agreed.

So vdsm guest agent goal is to ease administration of VMs.  This is not saying much as it is quite broad so I will list what is provided today and some things we need to add:

Assistance in VM life-cycle:
"desktopShutdown" - Shuts the VM down gracefully from within the guest.
"quiesce" - does not exist today.  This is definitely a requirement for us.

SSO support for spice sessions (automatically login into guest OS using provided credentials):
"desktopLock" - lock current session, used when spice session gets disconnected / before giving a new user access to spice session
"desktopLogin"
"desktopLogoff"
In addition, guest reports relevant info (currently active user, session state)

Monitoring and inventory:
currently agent sends info periodically, which includes a lot of info which should probably be broken down and served upon request. Info includes - 
- memory usage
- NICs info (name, hw, inet, inet6)
- appslist (list of installed apps / rpms)
- OS type
- guest hostname
- internal file systems info (path, fs type, total space, used space)

Personally I think the above should become more generic and support user defined counters (using WMI or collectd in the guest to collect the info and passing it via the guest agent), but that might be a different discussion.


>From qemu wiki, the following info about qemu guest agent:

It's purpose: "Implement support for QMP commands and events that terminate and originate respectively within the guest using an agent built as part of QEMU. "
- ties it directly to qemu, but not to specific functionality.  ovirt guest agent definitely would need to support this

In general, I would say ovirt-guest-agent is scoped to do everything the qemu-guest-agent is and then some, so there is definitely a lot of overlap.


> 
> Regards,
> 
> Anthony Liguori
> _______________________________________________
> Arch mailing list
> Arch@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 

Re: [Qemu-devel] converging around a single guest agent

[Hans de Goede]

Hi,

On 11/15/2011 11:39 PM, Ayal Baron wrote:
>

<snip>

>> If you want to talk about convergence, the discussion should start
>> around
>> collecting requirements.  We can then figure out if the two sets of
>> requirements
>> are strictly overlapping or if there are any requirements that are
>> fundamentally
>> in opposition.
>
> Agreed.
>
> So vdsm guest agent goal is to ease administration of VMs.  This is not saying much as it is quite broad so I will list what is provided today and some things we need to add:
>
> Assistance in VM life-cycle:
> "desktopShutdown" - Shuts the VM down gracefully from within the guest.
> "quiesce" - does not exist today.  This is definitely a requirement for us.
>
> SSO support for spice sessions (automatically login into guest OS using provided credentials):
> "desktopLock" - lock current session, used when spice session gets disconnected / before giving a new user access to spice session
> "desktopLogin"
> "desktopLogoff"
> In addition, guest reports relevant info (currently active user, session state)
>
> Monitoring and inventory:
> currently agent sends info periodically, which includes a lot of info which should probably be broken down and served upon request. Info includes -
> - memory usage
> - NICs info (name, hw, inet, inet6)
> - appslist (list of installed apps / rpms)
> - OS type
> - guest hostname
> - internal file systems info (path, fs type, total space, used space)
>

<snip>

If we're gathering requirements and trying to come up with one agent to rule them all, don't forget
about VDI and the Spice agent. Currently the spice agent handles the following:

1) Paravirtual mouse (needed to get mouse coordinates right with multi monitor setups)
2) Send client monitor configuration, so that the guest os can adjust its resolution
    (and number and place of monitors) to match the client
3) Copy and paste in a platform neutral manner, if anyone wishes to add this to another agent
    please, please contact us (me) first. This is easy to get wrong (we went through 2 revisions
    of the protocol for this).
4) Allow the client to request the guest to tone down the bling (for low spec clients)

Notes:
1) All of these are client <-> guest communication, rather then the host <-> guest communication
which the other agents seem to focus on.

2) Getting copy paste right requires a system level guest agent process as well as a per user
session agent process.

Regards,

Hans

Re: [Qemu-devel] converging around a single guest agent

[Ayal Baron]

----- Original Message -----
> Hi,
> 
> On 11/15/2011 11:39 PM, Ayal Baron wrote:
> >
> 
> <snip>
> 
> >> If you want to talk about convergence, the discussion should start
> >> around
> >> collecting requirements.  We can then figure out if the two sets
> >> of
> >> requirements
> >> are strictly overlapping or if there are any requirements that are
> >> fundamentally
> >> in opposition.
> >
> > Agreed.
> >
> > So vdsm guest agent goal is to ease administration of VMs.  This is
> > not saying much as it is quite broad so I will list what is
> > provided today and some things we need to add:
> >
> > Assistance in VM life-cycle:
> > "desktopShutdown" - Shuts the VM down gracefully from within the
> > guest.
> > "quiesce" - does not exist today.  This is definitely a requirement
> > for us.
> >
> > SSO support for spice sessions (automatically login into guest OS
> > using provided credentials):
> > "desktopLock" - lock current session, used when spice session gets
> > disconnected / before giving a new user access to spice session
> > "desktopLogin"
> > "desktopLogoff"
> > In addition, guest reports relevant info (currently active user,
> > session state)
> >
> > Monitoring and inventory:
> > currently agent sends info periodically, which includes a lot of
> > info which should probably be broken down and served upon request.
> > Info includes -
> > - memory usage
> > - NICs info (name, hw, inet, inet6)
> > - appslist (list of installed apps / rpms)
> > - OS type
> > - guest hostname
> > - internal file systems info (path, fs type, total space, used
> > space)
> >
> 
> <snip>
> 
> If we're gathering requirements and trying to come up with one agent
> to rule them all, don't forget

I don't think we're trying to come up with one agent to rule them all, just avoid duplication of efforts if most of what the 2 agents are doing overlaps.
I think we can safely say that seeing as oVirt is KVM centric, ovirt-guest-agent wants to leverage qemu/kvm to the fullest which aligns with what qemu-guest-agent is doing.
However, ovirt-guest-agent is required to do a lot more, so we need to see if and how we resolve this.

> about VDI and the Spice agent. Currently the spice agent handles the
> following:
> 
> 1) Paravirtual mouse (needed to get mouse coordinates right with
> multi monitor setups)
> 2) Send client monitor configuration, so that the guest os can adjust
> its resolution
>     (and number and place of monitors) to match the client
> 3) Copy and paste in a platform neutral manner, if anyone wishes to
> add this to another agent
>     please, please contact us (me) first. This is easy to get wrong
>     (we went through 2 revisions
>     of the protocol for this).
> 4) Allow the client to request the guest to tone down the bling (for
> low spec clients)
> 
> Notes:
> 1) All of these are client <-> guest communication, rather then the
> host <-> guest communication
> which the other agents seem to focus on.
> 
> 2) Getting copy paste right requires a system level guest agent
> process as well as a per user
> session agent process.

Neither qemu-guest-agent nor ovirt-guest-agent is aligned with doing any of the above, so I'm not sure there is any justification in uniting the spice agent with the rest.

> 
> Regards,
> 
> Hans
> 

Re: [Qemu-devel] converging around a single guest agent

[Michael Roth]

On 11/16/2011 02:16 AM, Ayal Baron wrote:
>
>
> ----- Original Message -----
>> Hi,
>>
>> On 11/15/2011 11:39 PM, Ayal Baron wrote:
>>>
>>
>> <snip>
>>
>>>> If you want to talk about convergence, the discussion should start
>>>> around
>>>> collecting requirements.  We can then figure out if the two sets
>>>> of
>>>> requirements
>>>> are strictly overlapping or if there are any requirements that are
>>>> fundamentally
>>>> in opposition.
>>>
>>> Agreed.
>>>
>>> So vdsm guest agent goal is to ease administration of VMs.  This is
>>> not saying much as it is quite broad so I will list what is
>>> provided today and some things we need to add:
>>>
>>> Assistance in VM life-cycle:
>>> "desktopShutdown" - Shuts the VM down gracefully from within the
>>> guest.
>>> "quiesce" - does not exist today.  This is definitely a requirement
>>> for us.
>>>
>>> SSO support for spice sessions (automatically login into guest OS
>>> using provided credentials):
>>> "desktopLock" - lock current session, used when spice session gets
>>> disconnected / before giving a new user access to spice session
>>> "desktopLogin"
>>> "desktopLogoff"
>>> In addition, guest reports relevant info (currently active user,
>>> session state)
>>>
>>> Monitoring and inventory:
>>> currently agent sends info periodically, which includes a lot of
>>> info which should probably be broken down and served upon request.
>>> Info includes -
>>> - memory usage
>>> - NICs info (name, hw, inet, inet6)
>>> - appslist (list of installed apps / rpms)
>>> - OS type
>>> - guest hostname
>>> - internal file systems info (path, fs type, total space, used
>>> space)
>>>
>>
>> <snip>
>>
>> If we're gathering requirements and trying to come up with one agent
>> to rule them all, don't forget
>
> I don't think we're trying to come up with one agent to rule them all, just avoid duplication of efforts if most of what the 2 agents are doing overlaps.
> I think we can safely say that seeing as oVirt is KVM centric, ovirt-guest-agent wants to leverage qemu/kvm to the fullest which aligns with what qemu-guest-agent is doing.
> However, ovirt-guest-agent is required to do a lot more, so we need to see if and how we resolve this.
>
>> about VDI and the Spice agent. Currently the spice agent handles the
>> following:
>>
>> 1) Paravirtual mouse (needed to get mouse coordinates right with
>> multi monitor setups)
>> 2) Send client monitor configuration, so that the guest os can adjust
>> its resolution
>>      (and number and place of monitors) to match the client
>> 3) Copy and paste in a platform neutral manner, if anyone wishes to
>> add this to another agent
>>      please, please contact us (me) first. This is easy to get wrong
>>      (we went through 2 revisions
>>      of the protocol for this).
>> 4) Allow the client to request the guest to tone down the bling (for
>> low spec clients)
>>
>> Notes:
>> 1) All of these are client<->  guest communication, rather then the
>> host<->  guest communication
>> which the other agents seem to focus on.
>>
>> 2) Getting copy paste right requires a system level guest agent
>> process as well as a per user
>> session agent process.
>
> Neither qemu-guest-agent nor ovirt-guest-agent is aligned with doing any of the above, so I'm not sure there is any justification in uniting the spice agent with the rest.
>

copy/paste was actually one of the initial use cases motivating qemu-ga; 
it's just that the requirements (system+user-level agents) were so 
different from the more pressing use cases of things like reliable 
shutdown/reboot that it's been put off for now. At some point we had a 
basic plan on how to approach it, but that needs to be re-assessed.

>>
>> Regards,
>>
>> Hans
>>
>

Re: [Qemu-devel] converging around a single guest agent

[Alon Levy]

On Wed, Nov 16, 2011 at 08:59:35AM -0600, Michael Roth wrote:
> On 11/16/2011 02:16 AM, Ayal Baron wrote:
> >
> >
> >----- Original Message -----
> >>Hi,
> >>
> >>On 11/15/2011 11:39 PM, Ayal Baron wrote:
> >>>
> >>
> >><snip>
> >>
> >>>>If you want to talk about convergence, the discussion should start
> >>>>around
> >>>>collecting requirements.  We can then figure out if the two sets
> >>>>of
> >>>>requirements
> >>>>are strictly overlapping or if there are any requirements that are
> >>>>fundamentally
> >>>>in opposition.
> >>>
> >>>Agreed.
> >>>
> >>>So vdsm guest agent goal is to ease administration of VMs.  This is
> >>>not saying much as it is quite broad so I will list what is
> >>>provided today and some things we need to add:
> >>>
> >>>Assistance in VM life-cycle:
> >>>"desktopShutdown" - Shuts the VM down gracefully from within the
> >>>guest.
> >>>"quiesce" - does not exist today.  This is definitely a requirement
> >>>for us.
> >>>
> >>>SSO support for spice sessions (automatically login into guest OS
> >>>using provided credentials):
> >>>"desktopLock" - lock current session, used when spice session gets
> >>>disconnected / before giving a new user access to spice session
> >>>"desktopLogin"
> >>>"desktopLogoff"
> >>>In addition, guest reports relevant info (currently active user,
> >>>session state)
> >>>
> >>>Monitoring and inventory:
> >>>currently agent sends info periodically, which includes a lot of
> >>>info which should probably be broken down and served upon request.
> >>>Info includes -
> >>>- memory usage
> >>>- NICs info (name, hw, inet, inet6)
> >>>- appslist (list of installed apps / rpms)
> >>>- OS type
> >>>- guest hostname
> >>>- internal file systems info (path, fs type, total space, used
> >>>space)
> >>>
> >>
> >><snip>
> >>
> >>If we're gathering requirements and trying to come up with one agent
> >>to rule them all, don't forget
> >
> >I don't think we're trying to come up with one agent to rule them all, just avoid duplication of efforts if most of what the 2 agents are doing overlaps.
> >I think we can safely say that seeing as oVirt is KVM centric, ovirt-guest-agent wants to leverage qemu/kvm to the fullest which aligns with what qemu-guest-agent is doing.
> >However, ovirt-guest-agent is required to do a lot more, so we need to see if and how we resolve this.
> >
> >>about VDI and the Spice agent. Currently the spice agent handles the
> >>following:
> >>
> >>1) Paravirtual mouse (needed to get mouse coordinates right with
> >>multi monitor setups)
> >>2) Send client monitor configuration, so that the guest os can adjust
> >>its resolution
> >>     (and number and place of monitors) to match the client
> >>3) Copy and paste in a platform neutral manner, if anyone wishes to
> >>add this to another agent
> >>     please, please contact us (me) first. This is easy to get wrong
> >>     (we went through 2 revisions
> >>     of the protocol for this).
> >>4) Allow the client to request the guest to tone down the bling (for
> >>low spec clients)
> >>
> >>Notes:
> >>1) All of these are client<->  guest communication, rather then the
> >>host<->  guest communication
> >>which the other agents seem to focus on.
> >>
> >>2) Getting copy paste right requires a system level guest agent
> >>process as well as a per user
> >>session agent process.
> >
> >Neither qemu-guest-agent nor ovirt-guest-agent is aligned with doing any of the above, so I'm not sure there is any justification in uniting the spice agent with the rest.
> >
> 
> copy/paste was actually one of the initial use cases motivating
> qemu-ga; it's just that the requirements (system+user-level agents)
> were so different from the more pressing use cases of things like
> reliable shutdown/reboot that it's been put off for now. At some
> point we had a basic plan on how to approach it, but that needs to
> be re-assessed.
> 

I think for large opaque copies in/out to the guest, like image copy
paste, or guest<->guest copy paste (word OLE) it would be nice to
implemant a side channel scheme:
 message to allocate a channel
 message to deallocate a channel and signal successfull completion or
 error
 the channel is just another virtio-serial that is used for this
 communication only

The benefits would be:
 no need to slow down other operations
 no base64 conversion (both sides)

This of course means that this data is not being parsed by qemu, so it
can't benefit from any whitelisting / schema description. That's why it
should only be used for data that is undescribable - like the
aformentioned image/guest copy case (for instance for text copy it makes
possibly less sense - although again that's completely unstructured
text, so perhaps it makes sense as well).


> >>
> >>Regards,
> >>
> >>Hans
> >>
> >
> 
> 

Re: [Qemu-devel] converging around a single guest agent

[Alon Levy]

On Wed, Nov 16, 2011 at 08:53:45AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 11/15/2011 11:39 PM, Ayal Baron wrote:
> >
> 
> <snip>
> 
> >>If you want to talk about convergence, the discussion should start
> >>around
> >>collecting requirements.  We can then figure out if the two sets of
> >>requirements
> >>are strictly overlapping or if there are any requirements that are
> >>fundamentally
> >>in opposition.
> >
> >Agreed.
> >
> >So vdsm guest agent goal is to ease administration of VMs.  This is not saying much as it is quite broad so I will list what is provided today and some things we need to add:
> >
> >Assistance in VM life-cycle:
> >"desktopShutdown" - Shuts the VM down gracefully from within the guest.
> >"quiesce" - does not exist today.  This is definitely a requirement for us.
> >
> >SSO support for spice sessions (automatically login into guest OS using provided credentials):
> >"desktopLock" - lock current session, used when spice session gets disconnected / before giving a new user access to spice session
> >"desktopLogin"
> >"desktopLogoff"
> >In addition, guest reports relevant info (currently active user, session state)
> >
> >Monitoring and inventory:
> >currently agent sends info periodically, which includes a lot of info which should probably be broken down and served upon request. Info includes -
> >- memory usage
> >- NICs info (name, hw, inet, inet6)
> >- appslist (list of installed apps / rpms)
> >- OS type
> >- guest hostname
> >- internal file systems info (path, fs type, total space, used space)
> >
> 
> <snip>
> 
> If we're gathering requirements and trying to come up with one agent to rule them all, don't forget
> about VDI and the Spice agent. Currently the spice agent handles the following:
> 
> 1) Paravirtual mouse (needed to get mouse coordinates right with multi monitor setups)
> 2) Send client monitor configuration, so that the guest os can adjust its resolution
>    (and number and place of monitors) to match the client
> 3) Copy and paste in a platform neutral manner, if anyone wishes to add this to another agent
>    please, please contact us (me) first. This is easy to get wrong (we went through 2 revisions
>    of the protocol for this).
> 4) Allow the client to request the guest to tone down the bling (for low spec clients)
> 
As long as we are collecting requirements, even if as Ayal said merging
spice requirements is not the OP's intent:

 5) Window management - Agent can set location of windows, report
 existing running applications and locations, get notified when a new
 window is created. For exposing individual applications, this is a
 future requirement.

> Notes:
> 1) All of these are client <-> guest communication, rather then the host <-> guest communication
> which the other agents seem to focus on.
> 
> 2) Getting copy paste right requires a system level guest agent process as well as a per user
> session agent process.
> 

> Regards,
> 
> Hans
> 

Re: [Qemu-devel] converging around a single guest agent

[Dor Laor]

On 11/16/2011 02:07 PM, Alon Levy wrote:
> On Wed, Nov 16, 2011 at 08:53:45AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 11/15/2011 11:39 PM, Ayal Baron wrote:
>>>
>>
>> <snip>
>>
>>>> If you want to talk about convergence, the discussion should start
>>>> around
>>>> collecting requirements.  We can then figure out if the two sets of
>>>> requirements
>>>> are strictly overlapping or if there are any requirements that are
>>>> fundamentally
>>>> in opposition.
>>>
>>> Agreed.
>>>
>>> So vdsm guest agent goal is to ease administration of VMs.  This is not saying much as it is quite broad so I will list what is provided today and some things we need to add:
>>>
>>> Assistance in VM life-cycle:
>>> "desktopShutdown" - Shuts the VM down gracefully from within the guest.
>>> "quiesce" - does not exist today.  This is definitely a requirement for us.
>>>
>>> SSO support for spice sessions (automatically login into guest OS using provided credentials):
>>> "desktopLock" - lock current session, used when spice session gets disconnected / before giving a new user access to spice session
>>> "desktopLogin"
>>> "desktopLogoff"
>>> In addition, guest reports relevant info (currently active user, session state)
>>>
>>> Monitoring and inventory:
>>> currently agent sends info periodically, which includes a lot of info which should probably be broken down and served upon request. Info includes -
>>> - memory usage
>>> - NICs info (name, hw, inet, inet6)
>>> - appslist (list of installed apps / rpms)
>>> - OS type
>>> - guest hostname
>>> - internal file systems info (path, fs type, total space, used space)
>>>
>>
>> <snip>
>>
>> If we're gathering requirements and trying to come up with one agent to rule them all, don't forget
>> about VDI and the Spice agent. Currently the spice agent handles the following:
>>
>> 1) Paravirtual mouse (needed to get mouse coordinates right with multi monitor setups)
>> 2) Send client monitor configuration, so that the guest os can adjust its resolution
>>     (and number and place of monitors) to match the client
>> 3) Copy and paste in a platform neutral manner, if anyone wishes to add this to another agent
>>     please, please contact us (me) first. This is easy to get wrong (we went through 2 revisions
>>     of the protocol for this).
>> 4) Allow the client to request the guest to tone down the bling (for low spec clients)

I suggest we'll have a single protocol and serialization means (JSON) 
plus a common framework that manages permissions within the guest.
Beyond that, the agent should have various plugins for example the above 
spice related ones (could be also vnc ones) can be implemented as 
plugins that the ovirt agent will invoke.


>>
> As long as we are collecting requirements, even if as Ayal said merging
> spice requirements is not the OP's intent:
>
>   5) Window management - Agent can set location of windows, report
>   existing running applications and locations, get notified when a new
>   window is created. For exposing individual applications, this is a
>   future requirement.
>
>> Notes:
>> 1) All of these are client<->  guest communication, rather then the host<->  guest communication
>> which the other agents seem to focus on.
>>
>> 2) Getting copy paste right requires a system level guest agent process as well as a per user
>> session agent process.
>>
>
>> Regards,
>>
>> Hans
>>
>

Re: [Qemu-devel] converging around a single guest agent

[Anthony Liguori]

On 11/16/2011 06:07 AM, Alon Levy wrote:
> On Wed, Nov 16, 2011 at 08:53:45AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 11/15/2011 11:39 PM, Ayal Baron wrote:
>>>
>>
>> <snip>
>>
>>>> If you want to talk about convergence, the discussion should start
>>>> around
>>>> collecting requirements.  We can then figure out if the two sets of
>>>> requirements
>>>> are strictly overlapping or if there are any requirements that are
>>>> fundamentally
>>>> in opposition.
>>>
>>> Agreed.
>>>
>>> So vdsm guest agent goal is to ease administration of VMs.  This is not saying much as it is quite broad so I will list what is provided today and some things we need to add:
>>>
>>> Assistance in VM life-cycle:
>>> "desktopShutdown" - Shuts the VM down gracefully from within the guest.
>>> "quiesce" - does not exist today.  This is definitely a requirement for us.
>>>
>>> SSO support for spice sessions (automatically login into guest OS using provided credentials):
>>> "desktopLock" - lock current session, used when spice session gets disconnected / before giving a new user access to spice session
>>> "desktopLogin"
>>> "desktopLogoff"
>>> In addition, guest reports relevant info (currently active user, session state)
>>>
>>> Monitoring and inventory:
>>> currently agent sends info periodically, which includes a lot of info which should probably be broken down and served upon request. Info includes -
>>> - memory usage
>>> - NICs info (name, hw, inet, inet6)
>>> - appslist (list of installed apps / rpms)
>>> - OS type
>>> - guest hostname
>>> - internal file systems info (path, fs type, total space, used space)
>>>
>>
>> <snip>
>>
>> If we're gathering requirements and trying to come up with one agent to rule them all, don't forget
>> about VDI and the Spice agent. Currently the spice agent handles the following:
>>
>> 1) Paravirtual mouse (needed to get mouse coordinates right with multi monitor setups)

I thought there was wide agreement that pv mouse should be extracted from the 
guest agent into its own driver.

>> 2) Send client monitor configuration, so that the guest os can adjust its resolution
>>     (and number and place of monitors) to match the client

I also wonder if this should be part of QXL?

Regards,

Anthony Liguori

>> 3) Copy and paste in a platform neutral manner, if anyone wishes to add this to another agent
>>     please, please contact us (me) first. This is easy to get wrong (we went through 2 revisions
>>     of the protocol for this).
>> 4) Allow the client to request the guest to tone down the bling (for low spec clients)
>>
> As long as we are collecting requirements, even if as Ayal said merging
> spice requirements is not the OP's intent:
>
>   5) Window management - Agent can set location of windows, report
>   existing running applications and locations, get notified when a new
>   window is created. For exposing individual applications, this is a
>   future requirement.
>
>> Notes:
>> 1) All of these are client<->  guest communication, rather then the host<->  guest communication
>> which the other agents seem to focus on.
>>
>> 2) Getting copy paste right requires a system level guest agent process as well as a per user
>> session agent process.
>>
>
>> Regards,
>>
>> Hans
>>
>

Re: [Qemu-devel] converging around a single guest agent

[Hans de Goede]

Hi,

On 11/16/2011 02:47 PM, Anthony Liguori wrote:
> On 11/16/2011 06:07 AM, Alon Levy wrote:
>> On Wed, Nov 16, 2011 at 08:53:45AM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 11/15/2011 11:39 PM, Ayal Baron wrote:
>>>>
>>>
>>> <snip>
>>>
>>>>> If you want to talk about convergence, the discussion should start
>>>>> around
>>>>> collecting requirements. We can then figure out if the two sets of
>>>>> requirements
>>>>> are strictly overlapping or if there are any requirements that are
>>>>> fundamentally
>>>>> in opposition.
>>>>
>>>> Agreed.
>>>>
>>>> So vdsm guest agent goal is to ease administration of VMs. This is not saying much as it is quite broad so I will list what is provided today and some things we need to add:
>>>>
>>>> Assistance in VM life-cycle:
>>>> "desktopShutdown" - Shuts the VM down gracefully from within the guest.
>>>> "quiesce" - does not exist today. This is definitely a requirement for us.
>>>>
>>>> SSO support for spice sessions (automatically login into guest OS using provided credentials):
>>>> "desktopLock" - lock current session, used when spice session gets disconnected / before giving a new user access to spice session
>>>> "desktopLogin"
>>>> "desktopLogoff"
>>>> In addition, guest reports relevant info (currently active user, session state)
>>>>
>>>> Monitoring and inventory:
>>>> currently agent sends info periodically, which includes a lot of info which should probably be broken down and served upon request. Info includes -
>>>> - memory usage
>>>> - NICs info (name, hw, inet, inet6)
>>>> - appslist (list of installed apps / rpms)
>>>> - OS type
>>>> - guest hostname
>>>> - internal file systems info (path, fs type, total space, used space)
>>>>
>>>
>>> <snip>
>>>
>>> If we're gathering requirements and trying to come up with one agent to rule them all, don't forget
>>> about VDI and the Spice agent. Currently the spice agent handles the following:
>>>
>>> 1) Paravirtual mouse (needed to get mouse coordinates right with multi monitor setups)
>
> I thought there was wide agreement that pv mouse should be extracted from the guest agent into its own driver.

Yes AFAIK there is, but no-one has done that yet. I was merely listening what the spice
agent is doing today, hopefully tomorrow

>
>>> 2) Send client monitor configuration, so that the guest os can adjust its resolution
>>> (and number and place of monitors) to match the client
>
> I also wonder if this should be part of QXL?

That is not really practically since this is something between the client and the guest,
where as the QXL device does communication between the hypervisor (qemu) and the guest.
Also there is a 1 head per QXL device relation, so that would mean that a single qxl dev
needs to be aware of other QXL devices in order to communicate the relative position of
its head to the other heads.

Regards,

Hans

Re: [Qemu-devel] converging around a single guest agent

[Alon Levy]

On Wed, Nov 16, 2011 at 06:55:06PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 11/16/2011 02:47 PM, Anthony Liguori wrote:
> >On 11/16/2011 06:07 AM, Alon Levy wrote:
> >>On Wed, Nov 16, 2011 at 08:53:45AM +0100, Hans de Goede wrote:
> >>>Hi,
> >>>
> >>>On 11/15/2011 11:39 PM, Ayal Baron wrote:
> >>>>
> >>>
> >>><snip>
> >>>
> >>>>>If you want to talk about convergence, the discussion should start
> >>>>>around
> >>>>>collecting requirements. We can then figure out if the two sets of
> >>>>>requirements
> >>>>>are strictly overlapping or if there are any requirements that are
> >>>>>fundamentally
> >>>>>in opposition.
> >>>>
> >>>>Agreed.
> >>>>
> >>>>So vdsm guest agent goal is to ease administration of VMs. This is not saying much as it is quite broad so I will list what is provided today and some things we need to add:
> >>>>
> >>>>Assistance in VM life-cycle:
> >>>>"desktopShutdown" - Shuts the VM down gracefully from within the guest.
> >>>>"quiesce" - does not exist today. This is definitely a requirement for us.
> >>>>
> >>>>SSO support for spice sessions (automatically login into guest OS using provided credentials):
> >>>>"desktopLock" - lock current session, used when spice session gets disconnected / before giving a new user access to spice session
> >>>>"desktopLogin"
> >>>>"desktopLogoff"
> >>>>In addition, guest reports relevant info (currently active user, session state)
> >>>>
> >>>>Monitoring and inventory:
> >>>>currently agent sends info periodically, which includes a lot of info which should probably be broken down and served upon request. Info includes -
> >>>>- memory usage
> >>>>- NICs info (name, hw, inet, inet6)
> >>>>- appslist (list of installed apps / rpms)
> >>>>- OS type
> >>>>- guest hostname
> >>>>- internal file systems info (path, fs type, total space, used space)
> >>>>
> >>>
> >>><snip>
> >>>
> >>>If we're gathering requirements and trying to come up with one agent to rule them all, don't forget
> >>>about VDI and the Spice agent. Currently the spice agent handles the following:
> >>>
> >>>1) Paravirtual mouse (needed to get mouse coordinates right with multi monitor setups)
> >
> >I thought there was wide agreement that pv mouse should be extracted from the guest agent into its own driver.
> 
> Yes AFAIK there is, but no-one has done that yet. I was merely listening what the spice
> agent is doing today, hopefully tomorrow
> 
> >
> >>>2) Send client monitor configuration, so that the guest os can adjust its resolution
> >>>(and number and place of monitors) to match the client
> >
> >I also wonder if this should be part of QXL?
> 
> That is not really practically since this is something between the client and the guest,
> where as the QXL device does communication between the hypervisor (qemu) and the guest.
> Also there is a 1 head per QXL device relation, so that would mean that a single qxl dev
> needs to be aware of other QXL devices in order to communicate the relative position of
> its head to the other heads.

We do want to allow multiple heads on a single qxl device, since it
would make RandR work.

This only relates to the second point, Hans first point is still valid.
> 
> Regards,
> 
> Hans
> 

Re: [Qemu-devel] converging around a single guest agent

[Anthony Liguori]

On 11/15/2011 04:39 PM, Ayal Baron wrote:
>> If you want to talk about convergence, the discussion should start
>> around
>> collecting requirements.  We can then figure out if the two sets of
>> requirements
>> are strictly overlapping or if there are any requirements that are
>> fundamentally
>> in opposition.
>
> Agreed.
>
> So vdsm guest agent goal is to ease administration of VMs.  This is not saying much as it is quite broad so I will list what is provided today and some things we need to add:
>
> Assistance in VM life-cycle:
> "desktopShutdown" - Shuts the VM down gracefully from within the guest.
> "quiesce" - does not exist today.  This is definitely a requirement for us.
>
> SSO support for spice sessions (automatically login into guest OS using provided credentials):
> "desktopLock" - lock current session, used when spice session gets disconnected / before giving a new user access to spice session
> "desktopLogin"
> "desktopLogoff"
> In addition, guest reports relevant info (currently active user, session state)
>
> Monitoring and inventory:
> currently agent sends info periodically, which includes a lot of info which should probably be broken down and served upon request. Info includes -
> - memory usage
> - NICs info (name, hw, inet, inet6)
> - appslist (list of installed apps / rpms)
> - OS type
> - guest hostname
> - internal file systems info (path, fs type, total space, used space)
>
> Personally I think the above should become more generic and support user defined counters (using WMI or collectd in the guest to collect the info and passing it via the guest agent), but that might be a different discussion.
>
>
>  From qemu wiki, the following info about qemu guest agent:
>
> It's purpose: "Implement support for QMP commands and events that terminate and originate respectively within the guest using an agent built as part of QEMU. "
> - ties it directly to qemu, but not to specific functionality.  ovirt guest agent definitely would need to support this
>
> In general, I would say ovirt-guest-agent is scoped to do everything the qemu-guest-agent is and then some, so there is definitely a lot of overlap.

We have another requirement.  We need to embed the source for the guest agent in 
the QEMU release tarball.  This is for GPL compliance since we want to include 
an ISO (eventually) that contains binaries.

This could be as simple as doing a git submodule but it would mean that the 
guest agent would have to live in its own git repository.  Do you all see a 
problem with this?

Regards,

Anthony Liguori

>
>
>>
>> Regards,
>>
>> Anthony Liguori
>> _______________________________________________
>> Arch mailing list
>> Arch@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>

Re: [Qemu-devel] converging around a single guest agent

[Dor Laor]

On 11/16/2011 03:36 PM, Anthony Liguori wrote:
> On 11/15/2011 04:39 PM, Ayal Baron wrote:
>>> If you want to talk about convergence, the discussion should start
>>> around
>>> collecting requirements. We can then figure out if the two sets of
>>> requirements
>>> are strictly overlapping or if there are any requirements that are
>>> fundamentally
>>> in opposition.
>>
>> Agreed.
>>
>> So vdsm guest agent goal is to ease administration of VMs. This is not
>> saying much as it is quite broad so I will list what is provided today
>> and some things we need to add:
>>
>> Assistance in VM life-cycle:
>> "desktopShutdown" - Shuts the VM down gracefully from within the guest.
>> "quiesce" - does not exist today. This is definitely a requirement for
>> us.
>>
>> SSO support for spice sessions (automatically login into guest OS
>> using provided credentials):
>> "desktopLock" - lock current session, used when spice session gets
>> disconnected / before giving a new user access to spice session
>> "desktopLogin"
>> "desktopLogoff"
>> In addition, guest reports relevant info (currently active user,
>> session state)
>>
>> Monitoring and inventory:
>> currently agent sends info periodically, which includes a lot of info
>> which should probably be broken down and served upon request. Info
>> includes -
>> - memory usage
>> - NICs info (name, hw, inet, inet6)
>> - appslist (list of installed apps / rpms)
>> - OS type
>> - guest hostname
>> - internal file systems info (path, fs type, total space, used space)
>>
>> Personally I think the above should become more generic and support
>> user defined counters (using WMI or collectd in the guest to collect
>> the info and passing it via the guest agent), but that might be a
>> different discussion.
>>
>>
>> From qemu wiki, the following info about qemu guest agent:
>>
>> It's purpose: "Implement support for QMP commands and events that
>> terminate and originate respectively within the guest using an agent
>> built as part of QEMU. "
>> - ties it directly to qemu, but not to specific functionality. ovirt
>> guest agent definitely would need to support this
>>
>> In general, I would say ovirt-guest-agent is scoped to do everything
>> the qemu-guest-agent is and then some, so there is definitely a lot of
>> overlap.
>
> We have another requirement. We need to embed the source for the guest
> agent in the QEMU release tarball. This is for GPL compliance since we
> want to include an ISO (eventually) that contains binaries.
>
> This could be as simple as doing a git submodule but it would mean that
> the guest agent would have to live in its own git repository. Do you all
> see a problem with this?

Not that I object of placing the code within qemu but I doubt this is a 
requirement, we can settle w/ GPL license for the code.

A requirement of having the agent code reside within qemu is similar to 
some neighbors idea about kvm-tool and the kernel ...

>
> Regards,
>
> Anthony Liguori
>
>>
>>
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>> _______________________________________________
>>> Arch mailing list
>>> Arch@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>
>>
>
>

Re: [Qemu-devel] converging around a single guest agent

[Anthony Liguori]

On 11/16/2011 07:39 AM, Dor Laor wrote:
> On 11/16/2011 03:36 PM, Anthony Liguori wrote:
>> We have another requirement. We need to embed the source for the guest
>> agent in the QEMU release tarball. This is for GPL compliance since we
>> want to include an ISO (eventually) that contains binaries.
>>
>> This could be as simple as doing a git submodule but it would mean that
>> the guest agent would have to live in its own git repository. Do you all
>> see a problem with this?
>
> Not that I object of placing the code within qemu but I doubt this is a
> requirement, we can settle w/ GPL license for the code.
>
> A requirement of having the agent code reside within qemu is similar to some
> neighbors idea about kvm-tool and the kernel ...

It can just be a submodule (like we do with SeaBIOS, etc.).  The only request is 
that we split guest agent out of vdsm so we don't have to also include all of 
vdsm in the release tarballs.  That would make the guest agent an independent 
git repository and presumably project.

We can't ship a binary without including the source in the release.  The way we 
handle this for things that are external to QEMU (SeaBIOS, OpenBIOS, etc.) are 
git submodules.

Regards,

Anthony Liguori

Re: [Qemu-devel] converging around a single guest agent

[Ayal Baron]

----- Original Message -----
> On 11/16/2011 07:39 AM, Dor Laor wrote:
> > On 11/16/2011 03:36 PM, Anthony Liguori wrote:
> >> We have another requirement. We need to embed the source for the
> >> guest
> >> agent in the QEMU release tarball. This is for GPL compliance
> >> since we
> >> want to include an ISO (eventually) that contains binaries.
> >>
> >> This could be as simple as doing a git submodule but it would mean
> >> that
> >> the guest agent would have to live in its own git repository. Do
> >> you all
> >> see a problem with this?
> >
> > Not that I object of placing the code within qemu but I doubt this
> > is a
> > requirement, we can settle w/ GPL license for the code.
> >
> > A requirement of having the agent code reside within qemu is
> > similar to some
> > neighbors idea about kvm-tool and the kernel ...
> 
> It can just be a submodule (like we do with SeaBIOS, etc.).  The only
> request is
> that we split guest agent out of vdsm so we don't have to also
> include all of
> vdsm in the release tarballs.  That would make the guest agent an
> independent
> git repository and presumably project.
> 
> We can't ship a binary without including the source in the release.
>  The way we
> handle this for things that are external to QEMU (SeaBIOS, OpenBIOS,
> etc.) are
> git submodules.

It is already a separate git so that would not be a problem...

> 
> Regards,
> 
> Anthony Liguori
> 

Re: [Qemu-devel] converging around a single guest agent

[Paolo Bonzini]

On 11/16/2011 02:42 PM, Anthony Liguori wrote:
> On 11/16/2011 07:39 AM, Dor Laor wrote:
>> On 11/16/2011 03:36 PM, Anthony Liguori wrote:
>>> We have another requirement. We need to embed the source for the guest
>>> agent in the QEMU release tarball. This is for GPL compliance since we
>>> want to include an ISO (eventually) that contains binaries.
>>>
>>> This could be as simple as doing a git submodule but it would mean that
>>> the guest agent would have to live in its own git repository. Do you all
>>> see a problem with this?
>>
>> Not that I object of placing the code within qemu but I doubt this is a
>> requirement, we can settle w/ GPL license for the code.
>>
>> A requirement of having the agent code reside within qemu is similar to some
>> neighbors idea about kvm-tool and the kernel ...
>
> It can just be a submodule (like we do with SeaBIOS, etc.).  The only request is
> that we split guest agent out of vdsm so we don't have to also include all of
> vdsm in the release tarballs.  That would make the guest agent an independent
> git repository and presumably project.

It is already (git://gerrit.ovirt.org/ovirt-guest-agent).  Barak, is 
there a gitweb/cgit instance?

> We can't ship a binary without including the source in the release.  The way we
> handle this for things that are external to QEMU (SeaBIOS, OpenBIOS, etc.) are
> git submodules.

ovirt-guest-agent is licensed under GPLv3, so you do not need to; the 
options in GPLv3 include this one:

     d) Convey the object code by offering access from a designated
     place (gratis or for a charge), and offer equivalent access to the
     Corresponding Source in the same way through the same place at no
     further charge.  You need not require recipients to copy the
     Corresponding Source along with the object code.  If the place to
     copy the object code is a network server, the Corresponding Source
     may be on a different server (operated by you or a third party)
     that supports equivalent copying facilities, provided you maintain
     clear directions next to the object code saying where to find the
     Corresponding Source.  Regardless of what server hosts the
     Corresponding Source, you remain obligated to ensure that it is
     available for as long as needed to satisfy these requirements.

Of course having a separate repo, and mirroring to qemu.org both remain 
nice things to have.

Paolo

Re: [Qemu-devel] converging around a single guest agent

[Itamar Heim]

On 11/16/2011 04:20 PM, Paolo Bonzini wrote:
>
...

>>
>> It can just be a submodule (like we do with SeaBIOS, etc.). The only
>> request is
>> that we split guest agent out of vdsm so we don't have to also include
>> all of
>> vdsm in the release tarballs. That would make the guest agent an
>> independent
>> git repository and presumably project.
>
> It is already (git://gerrit.ovirt.org/ovirt-guest-agent). Barak, is
> there a gitweb/cgit instance?

http://gerrit.ovirt.org/gitweb?p=ovirt-guest-agent.git

Re: [Qemu-devel] converging around a single guest agent

[Jamie Lokier]

>>> On 11/16/2011 03:36 PM, Anthony Liguori wrote:
>>>> We have another requirement. We need to embed the source for the guest
>>>> agent in the QEMU release tarball. This is for GPL compliance since we
>>>> want to include an ISO (eventually) that contains binaries.

Paolo Bonzini wrote:
> ovirt-guest-agent is licensed under GPLv3, so you do not need to;
> the options in GPLv3 include this one:
> 
>     d) Convey the object code by offering access from a designated
>     place (gratis or for a charge), and offer equivalent access to the
>     Corresponding Source in the same way through the same place at no
>     further charge.  You need not require recipients to copy the
>     Corresponding Source along with the object code.  If the place to
>     copy the object code is a network server, the Corresponding Source
>     may be on a different server (operated by you or a third party)
>     that supports equivalent copying facilities, provided you maintain
>     clear directions next to the object code saying where to find the
>     Corresponding Source.  Regardless of what server hosts the
>     Corresponding Source, you remain obligated to ensure that it is
>     available for as long as needed to satisfy these requirements.

Hi,

GPLv2 also has a clause similar to the above.  In GPLv2 it's not
enumerated, but says:

    If distribution of executable or object code is made by offering
    access to copy from a designated place, then offering equivalent
    access to copy the source code from the same place counts as
    distribution of the source code, even though third parties are not
    compelled to copy the source along with the object code.

I'm not sure why "mere aggregation" (GPLv2) and "aggregate" (GPLv3)
aren't sufficient to allow shipping the different binaries together in
a single ISO regardless of where the source code lives or how it's licensed.

-- Jamie

Re: [Qemu-devel] converging around a single guest agent

[Anthony Liguori]

On 11/15/2011 04:39 PM, Ayal Baron wrote:
>
>
> ----- Original Message -----
>> On 11/15/2011 11:24 AM, Barak Azulay wrote:
>>> Hi,
>>>
>>> One of the breakout sessions during the ovirt workshop [1] was
>>> about the guest
>>> tools, and focused mainly on the ovirt-guest-agent [2].
>>>
>>> One of the issues discussed there, was the various existing guest
>>> agents out
>>> there, and the need to converge the efforts to a single agent that
>>> will serve
>>> all.
>>>
>>> while 4 agents were mentioned (Matahari, vdagent, qemu-ga&
>>>   ovirt-guest-agent)
>>> during that discussion, we narrowed it down to 2 candidates:
>>>
>>> qemu-ga (aka virt-agent):
>>> -------------------------
>>> - Qemu specific - it was aimed for specific qemu needs (mainly
>>> quiesce guest
>>> I/O)
>>> - Communicates directly with qemu  (not implemented yet)
>>> - Supports ?
>>> - So far linux only
>>
>> But very easy to port.  It also should work on just about any Unix
>> since its
>> only dependency is glib.  Also:
>>
>>    - exists in the QEMU repository
>>
>>> - written in C
>>>
>>> Ovirt-guest-agent:
>>> ------------------
>>> - Has been around for a long time (~5 years) - considered stable
>>> - Started as rhevm specific but evolved a lot since then
>>> - Currently the only fully functional guest agent available for
>>> ovirt
>>> - Written in python
>>> - Some VDI related sub components are written in C&   C++
>>> - Supports a well defined list of message types / protocol [3]
>>> - Supports the folowing guest OSs
>>>     Linux: RHEL5, RHEL6 F15, F16(soon)
>>>     Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)
>>
>> The guest agent we use in QEMU exists to implement QEMU specific
>> functionality.
>>    I think one challenge that comes up here is that the ovirt guest
>>    agent has a
>> very different scope than the QEMU agent.  The ovirt guest agent has
>> a very
>> ovirt-engine centric scope.
>>
>>> The need to converge is obvious, and now that ovirt-guest-agent is
>>> opensourced
>>> under the ovirt stack, and since it already produces value for
>>> enterprise
>>> installations, and is cross platform, I offer to join hands around
>>> ovirt-
>>> guest-agent and formalize a single code base that will serve us
>>> all.
>>
>> You are basically saying, stop what you guys are doing and work on
>> our code
>> because it's better.  That's not really convergence.
>>
>> If you want to talk about convergence, the discussion should start
>> around
>> collecting requirements.  We can then figure out if the two sets of
>> requirements
>> are strictly overlapping or if there are any requirements that are
>> fundamentally
>> in opposition.
>
> Agreed.
>
> So vdsm guest agent goal is to ease administration of VMs.  This is not saying much as it is quite broad so I will list what is provided today and some things we need to add:

Is there a spec for the guest agent protocol?

What's the current policy on compatibility?  How does the guest agent protocol 
handle feature negotiation?

Regards,

Anthony Liguori

Re: [Qemu-devel] converging around a single guest agent

[Anthony Liguori]

On 11/15/2011 11:24 AM, Barak Azulay wrote:
> Hi,
>
> One of the breakout sessions during the ovirt workshop [1] was about the guest
> tools, and focused mainly on the ovirt-guest-agent [2].
>
> One of the issues discussed there, was the various existing guest agents out
> there, and the need to converge the efforts to a single agent that will serve
> all.
>
> while 4 agents were mentioned (Matahari, vdagent, qemu-ga&  ovirt-guest-agent)
> during that discussion, we narrowed it down to 2 candidates:
>
> qemu-ga (aka virt-agent):
> -------------------------
> - Qemu specific - it was aimed for specific qemu needs (mainly quiesce guest
> I/O)
> - Communicates directly with qemu  (not implemented yet)
> - Supports ?
> - So far linux only

But very easy to port.  It also should work on just about any Unix since its 
only dependency is glib.  Also:

  - exists in the QEMU repository

> - written in C
>
> Ovirt-guest-agent:
> ------------------
> - Has been around for a long time (~5 years) - considered stable
> - Started as rhevm specific but evolved a lot since then
> - Currently the only fully functional guest agent available for ovirt
> - Written in python
> - Some VDI related sub components are written in C&  C++
> - Supports a well defined list of message types / protocol [3]
> - Supports the folowing guest OSs
>    Linux: RHEL5, RHEL6 F15, F16(soon)
>    Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)

The guest agent we use in QEMU exists to implement QEMU specific functionality. 
  I think one challenge that comes up here is that the ovirt guest agent has a 
very different scope than the QEMU agent.  The ovirt guest agent has a very 
ovirt-engine centric scope.

> The need to converge is obvious, and now that ovirt-guest-agent is opensourced
> under the ovirt stack, and since it already produces value for enterprise
> installations, and is cross platform, I offer to join hands around ovirt-
> guest-agent and formalize a single code base that will serve us all.

You are basically saying, stop what you guys are doing and work on our code 
because it's better.  That's not really convergence.

If you want to talk about convergence, the discussion should start around 
collecting requirements.  We can then figure out if the two sets of requirements 
are strictly overlapping or if there are any requirements that are fundamentally 
in opposition.

Regards,

Anthony Liguori

Re: [Qemu-devel] converging around a single guest agent

[Michael Roth]

On 11/15/2011 11:24 AM, Barak Azulay wrote:
> Hi,
>
> One of the breakout sessions during the ovirt workshop [1] was about the guest
> tools, and focused mainly on the ovirt-guest-agent [2].
>
> One of the issues discussed there, was the various existing guest agents out
> there, and the need to converge the efforts to a single agent that will serve
> all.
>
> while 4 agents were mentioned (Matahari, vdagent, qemu-ga&  ovirt-guest-agent)
> during that discussion, we narrowed it down to 2 candidates:
>
> qemu-ga (aka virt-agent):
> -------------------------
> - Qemu specific - it was aimed for specific qemu needs (mainly quiesce guest
> I/O)
> - Communicates directly with qemu  (not implemented yet)

Won't be implemented until we finish the QMP conversion to QAPI since 
that's a prereq to implementing a QMP server with proper async support 
(needed for communication with a potentially non-responsive guest 
agent). But once it's in guest extensions are completely transparent to 
QMP/libvirt, which is highly desirable from a management perspective 
since you're coding against a single API/transport.

> - Supports ?

Documented in qemu.git/qapi-schema.json:

mdroth@illuin:~/w/qemu.git$ grep command qapi-schema-guest.json
# Such clients should also preceed this command
{ 'command': 'guest-sync'
{ 'command': 'guest-ping' }
{ 'command': 'guest-info',
{ 'command': 'guest-shutdown', 'data': { '*mode': 'str' } }
{ 'command': 'guest-file-open',
{ 'command': 'guest-file-close',
{ 'command': 'guest-file-read',
{ 'command': 'guest-file-write',
{ 'command': 'guest-file-seek',
{ 'command': 'guest-file-flush',
{ 'command': 'guest-fsfreeze-status',
{ 'command': 'guest-fsfreeze-freeze',
{ 'command': 'guest-fsfreeze-thaw',

There's a wiki page with additional details:

> - So far linux only

Windows port is *almost* there. I have patches to build/run it on 
windows but there are some remaining bugs, and guest-fsfreeze* and 
guest-shutdown* are gonna need windows-specific command implementations.

> - written in C
>
> Ovirt-guest-agent:
> ------------------
> - Has been around for a long time (~5 years) - considered stable
> - Started as rhevm specific but evolved a lot since then
> - Currently the only fully functional guest agent available for ovirt
> - Written in python
> - Some VDI related sub components are written in C&  C++
> - Supports a well defined list of message types / protocol [3]
> - Supports the folowing guest OSs
>    Linux: RHEL5, RHEL6 F15, F16(soon)
>    Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2)
>

In terms of completeness/support for ovirt (and node/cluster-level 
management frameworks in general), the ovirt-guest-agent certainly seems 
like a win. The main problem with convergence within the qemu space is 
that we can't have guest extensions to qemu-driven guest events like, 
say, hotplug or shutdown be managed by an external agent: the 
functionality, specificity, and assurances required are not things that 
are necessarily suited for ovirt-guest-agent; the scope is very different.

And the same holds true in the other direction: I don't, personally at 
least, foresee qemu-ga ever doing things like providing a list of logged 
in users on a system or handling SSO, though if there are those who'd 
like to take qemu-ga in that direction I think that's fine.

But practically-speaking, it's unavoidable that qemu-specific management 
tooling will need to communicate with qemu (via QMP/libqmp/HMP/etc, or 
by proxy via libvirt). It's through those same channels that the qemu-ga 
interfaces will ultimately be exposed, so the problem of qemu-ga vs. 
ovirt-guest-agent isn't really any different than the problem of QMP's 
system_powerdown/info_balloon/etc vs. ovirt-guest-agent's 
Shutdown/Available_Ram/etc: it's a policy decision rather than argument 
for choosing one project over another.

>
> The need to converge is obvious, and now that ovirt-guest-agent is opensourced
> under the ovirt stack, and since it already produces value for enterprise
> installations, and is cross platform, I offer to join hands around ovirt-
> guest-agent and formalize a single code base that will serve us all.
>
> git @ git://gerrit.ovirt.org/ovirt-guest-agent
>
> Thoughts ?
>
> Thanks
> Barak Azulay
>
> [1] http://www.ovirt.org/news-and-events/workshop
> [2] http://www.ovirt.org/wiki/File:Ovirt-guest-agent.odp
> [3] http://www.ovirt.org/wiki/Ovirt_guest_agent
>

Re: [Qemu-devel] converging around a single guest agent

[Alexander Graf]

On 16.11.2011, at 00:01, Michael Roth wrote:

> But practically-speaking, it's unavoidable that qemu-specific management tooling will need to communicate with qemu (via QMP/libqmp/HMP/etc, or by proxy via libvirt). It's through those same channels that the qemu-ga interfaces will ultimately be exposed, so the problem of qemu-ga vs. ovirt-guest-agent isn't really any different than the problem of QMP's system_powerdown/info_balloon/etc vs. ovirt-guest-agent's Shutdown/Available_Ram/etc: it's a policy decision rather than argument for choosing one project over another.

I don't see why we shouldn't be able to just proxy whatever communication happens between the guest agent and the management tool through qemu. At that point qemu could talk to the guest agent just as well as the management tool and everyone's happy.

Alex

Re: [Qemu-devel] converging around a single guest agent

[Barak Azulay]

On Wednesday 16 November 2011 02:42:30 Alexander Graf wrote:
> On 16.11.2011, at 00:01, Michael Roth wrote:
> > But practically-speaking, it's unavoidable that qemu-specific management
> > tooling will need to communicate with qemu (via QMP/libqmp/HMP/etc, or
> > by proxy via libvirt). It's through those same channels that the qemu-ga
> > interfaces will ultimately be exposed, so the problem of qemu-ga vs.
> > ovirt-guest-agent isn't really any different than the problem of QMP's
> > system_powerdown/info_balloon/etc vs. ovirt-guest-agent's
> > Shutdown/Available_Ram/etc: it's a policy decision rather than argument
> > for choosing one project over another.
> 
> I don't see why we shouldn't be able to just proxy whatever communication
> happens between the guest agent and the management tool through qemu. At
> that point qemu could talk to the guest agent just as well as the
> management tool and everyone's happy.

I'm not sure proxying all the requests to the guset through qemu is desirable, 
other than having single point of management, most of the calls will be pass 
throgh and has no interest to qemu (MITM?). 

There is a big advantage on direct communication (VDSM <-> agent), that way 
features can be added to the ovirt stack without the need to add it to the 
qemu.    

I envision the agent will have 2 separate ports to listen to, one to 
communicate to qemu and one for VDSM.    

Barak

> 
> Alex

Re: [Qemu-devel] converging around a single guest agent

[Alexander Graf]

On 16.11.2011, at 08:05, Barak Azulay <bazulay@redhat.com> wrote:

> On Wednesday 16 November 2011 02:42:30 Alexander Graf wrote:
>> On 16.11.2011, at 00:01, Michael Roth wrote:
>>> But practically-speaking, it's unavoidable that qemu-specific management
>>> tooling will need to communicate with qemu (via QMP/libqmp/HMP/etc, or
>>> by proxy via libvirt). It's through those same channels that the qemu-ga
>>> interfaces will ultimately be exposed, so the problem of qemu-ga vs.
>>> ovirt-guest-agent isn't really any different than the problem of QMP's
>>> system_powerdown/info_balloon/etc vs. ovirt-guest-agent's
>>> Shutdown/Available_Ram/etc: it's a policy decision rather than argument
>>> for choosing one project over another.
>> 
>> I don't see why we shouldn't be able to just proxy whatever communication
>> happens between the guest agent and the management tool through qemu. At
>> that point qemu could talk to the guest agent just as well as the
>> management tool and everyone's happy.
> 
> I'm not sure proxying all the requests to the guset through qemu is desirable, 
> other than having single point of management, most of the calls will be pass 
> throgh and has no interest to qemu (MITM?). 
> 
> There is a big advantage on direct communication (VDSM <-> agent), that way 
> features can be added to the ovirt stack without the need to add it to the 
> qemu.    

If we keep the protocol well-defined, we can get that for free. Just have every command carry its own size and a request id shich the reply also contains and suddenly you get asynchronous proxyable communication.

> 
> I envision the agent will have 2 separate ports to listen to, one to 
> communicate to qemu and one for VDSM.    

Ugh, no, I'd much prefer a single 'bus' everyone attaches to.

Alex

> 
> Barak
> 
>> 
>> Alex

Re: [Qemu-devel] converging around a single guest agent

[Barak Azulay]

On Wednesday 16 November 2011 10:16:57 Alexander Graf wrote:
> On 16.11.2011, at 08:05, Barak Azulay <bazulay@redhat.com> wrote:
> > On Wednesday 16 November 2011 02:42:30 Alexander Graf wrote:
> >> On 16.11.2011, at 00:01, Michael Roth wrote:
> >>> But practically-speaking, it's unavoidable that qemu-specific
> >>> management tooling will need to communicate with qemu (via
> >>> QMP/libqmp/HMP/etc, or by proxy via libvirt). It's through those same
> >>> channels that the qemu-ga interfaces will ultimately be exposed, so
> >>> the problem of qemu-ga vs. ovirt-guest-agent isn't really any
> >>> different than the problem of QMP's system_powerdown/info_balloon/etc
> >>> vs. ovirt-guest-agent's
> >>> Shutdown/Available_Ram/etc: it's a policy decision rather than argument
> >>> for choosing one project over another.
> >> 
> >> I don't see why we shouldn't be able to just proxy whatever
> >> communication happens between the guest agent and the management tool
> >> through qemu. At that point qemu could talk to the guest agent just as
> >> well as the management tool and everyone's happy.
> > 
> > I'm not sure proxying all the requests to the guset through qemu is
> > desirable, other than having single point of management, most of the
> > calls will be pass throgh and has no interest to qemu (MITM?).
> > 
> > There is a big advantage on direct communication (VDSM <-> agent), that
> > way features can be added to the ovirt stack without the need to add it
> > to the qemu.
> 
> If we keep the protocol well-defined, we can get that for free. Just have
> every command carry its own size and a request id shich the reply also
> contains and suddenly you get asynchronous proxyable communication.
> 


Sure we can keep commands synchronized in various ways the question is do we 
want that, there are a few down sides for that:
1 - VDSM will have to pass through 2 proxies (libvirt & qemu) in order to 
deliver a message to the guest, this byiself is not such a big disadvantage 
but will force us to handle much more corner-cases.
2 - looking at the qemu-ga functionality (read & write ...) do we really want 
to let a big chunk of data through both qemu & libvirt rather than directtly 
to the comsumer (VDSM)
3 - When events are fired from the guest agent, the delay of passing it 
through a double proxy will have it's latency penalty (as we have experianced 
in the client disconnect spice event)  


> > I envision the agent will have 2 separate ports to listen to, one to
> > communicate to qemu and one for VDSM.
> 
> Ugh, no, I'd much prefer a single 'bus' everyone attaches to.

why?

I'm thinking on situation we'll need to priorities commands arriving from qemu 
over "management standard commands" & info gathering, sure there are number of 
mechanisms to do that but it seems to me that a separation is the best way.

e.g. I think we need to priorities a quiesce command from qemu over any other 
info/command from VDSM.



> 
> Alex
> 
> > Barak
> > 
> >> Alex

Re: [Qemu-devel] converging around a single guest agent

[Michael Roth]

On 11/16/2011 06:13 AM, Barak Azulay wrote:
> On Wednesday 16 November 2011 10:16:57 Alexander Graf wrote:
>> On 16.11.2011, at 08:05, Barak Azulay<bazulay@redhat.com>  wrote:
>>> On Wednesday 16 November 2011 02:42:30 Alexander Graf wrote:
>>>> On 16.11.2011, at 00:01, Michael Roth wrote:
>>>>> But practically-speaking, it's unavoidable that qemu-specific
>>>>> management tooling will need to communicate with qemu (via
>>>>> QMP/libqmp/HMP/etc, or by proxy via libvirt). It's through those same
>>>>> channels that the qemu-ga interfaces will ultimately be exposed, so
>>>>> the problem of qemu-ga vs. ovirt-guest-agent isn't really any
>>>>> different than the problem of QMP's system_powerdown/info_balloon/etc
>>>>> vs. ovirt-guest-agent's
>>>>> Shutdown/Available_Ram/etc: it's a policy decision rather than argument
>>>>> for choosing one project over another.
>>>>
>>>> I don't see why we shouldn't be able to just proxy whatever
>>>> communication happens between the guest agent and the management tool
>>>> through qemu. At that point qemu could talk to the guest agent just as
>>>> well as the management tool and everyone's happy.
>>>
>>> I'm not sure proxying all the requests to the guset through qemu is
>>> desirable, other than having single point of management, most of the
>>> calls will be pass throgh and has no interest to qemu (MITM?).
>>>
>>> There is a big advantage on direct communication (VDSM<->  agent), that
>>> way features can be added to the ovirt stack without the need to add it
>>> to the qemu.
>>
>> If we keep the protocol well-defined, we can get that for free. Just have
>> every command carry its own size and a request id shich the reply also
>> contains and suddenly you get asynchronous proxyable communication.
>>
>
>
> Sure we can keep commands synchronized in various ways the question is do we
> want that, there are a few down sides for that:
> 1 - VDSM will have to pass through 2 proxies (libvirt&  qemu) in order to
> deliver a message to the guest, this byiself is not such a big disadvantage
> but will force us to handle much more corner-cases.

Can't rule out the possibility of corner-cases resulting from this, but 
the practical way to look at it is VDSM will need handle libvirt/QMP 
protocols well. The implementation of the proxying mechanism is where 
the extra challenge comes into play, but this should be transparent to 
the protocols VDSM speaks.

Implementation-wise, just to give you an idea of the work involved if we 
took this route:

1) ovirt-guest-agent would need to convert request/response payloads 
from/to QMP payloads on the guest-side, which are JSON and should, 
theoretically, mesh well with a python-based agent.

2) You'd also need a schema, similar to qemu.git/qapi-schema-guest.json, 
to describe the calls you're proxying. The existing infrastructure in 
QEMU will handle all the work of marshalling/unmarshalling responses 
back to the QMP client on the host-side.

It's a bit of extra work, but the benefit is unifying the 
qemu/guest-level management interface into a single place that's easy 
for QMP/libvirt to consume.

> 2 - looking at the qemu-ga functionality (read&  write ...) do we really want
> to let a big chunk of data through both qemu&  libvirt rather than directtly
> to the comsumer (VDSM)

VDSM isn't the only consumer however, HMP/QMP and libvirt are consumers 
in and of themselves.

> 3 - When events are fired from the guest agent, the delay of passing it
> through a double proxy will have it's latency penalty (as we have experianced
> in the client disconnect spice event)
>

Getting them out of the guest is probably the biggest factor, delivering 
them between processes on the host is likely a small hit in comparison.

>
>>> I envision the agent will have 2 separate ports to listen to, one to
>>> communicate to qemu and one for VDSM.
>>
>> Ugh, no, I'd much prefer a single 'bus' everyone attaches to.
>
> why?
>
> I'm thinking on situation we'll need to priorities commands arriving from qemu
> over "management standard commands"&  info gathering, sure there are number of
> mechanisms to do that but it seems to me that a separation is the best way.
>
> e.g. I think we need to priorities a quiesce command from qemu over any other
> info/command from VDSM.

Do you mean prioritize in terms of order of delivery? Best way to do 
that is a single protocol with state-tracking, otherwise we're just racing.

>
>
>
>>
>> Alex
>>
>>> Barak
>>>
>>>> Alex
>

Re: [Qemu-devel] converging around a single guest agent

[Barak Azulay]

On Wednesday 16 November 2011 17:28:16 Michael Roth wrote:
> On 11/16/2011 06:13 AM, Barak Azulay wrote:
> > On Wednesday 16 November 2011 10:16:57 Alexander Graf wrote:
> >> On 16.11.2011, at 08:05, Barak Azulay<bazulay@redhat.com>  wrote:
> >>> On Wednesday 16 November 2011 02:42:30 Alexander Graf wrote:
> >>>> On 16.11.2011, at 00:01, Michael Roth wrote:
> >>>>> But practically-speaking, it's unavoidable that qemu-specific
> >>>>> management tooling will need to communicate with qemu (via
> >>>>> QMP/libqmp/HMP/etc, or by proxy via libvirt). It's through those same
> >>>>> channels that the qemu-ga interfaces will ultimately be exposed, so
> >>>>> the problem of qemu-ga vs. ovirt-guest-agent isn't really any
> >>>>> different than the problem of QMP's system_powerdown/info_balloon/etc
> >>>>> vs. ovirt-guest-agent's
> >>>>> Shutdown/Available_Ram/etc: it's a policy decision rather than
> >>>>> argument for choosing one project over another.
> >>>> 
> >>>> I don't see why we shouldn't be able to just proxy whatever
> >>>> communication happens between the guest agent and the management tool
> >>>> through qemu. At that point qemu could talk to the guest agent just as
> >>>> well as the management tool and everyone's happy.
> >>> 
> >>> I'm not sure proxying all the requests to the guset through qemu is
> >>> desirable, other than having single point of management, most of the
> >>> calls will be pass throgh and has no interest to qemu (MITM?).
> >>> 
> >>> There is a big advantage on direct communication (VDSM<->  agent), that
> >>> way features can be added to the ovirt stack without the need to add it
> >>> to the qemu.
> >> 
> >> If we keep the protocol well-defined, we can get that for free. Just
> >> have every command carry its own size and a request id shich the reply
> >> also contains and suddenly you get asynchronous proxyable
> >> communication.
> > 
> > Sure we can keep commands synchronized in various ways the question is do
> > we want that, there are a few down sides for that:
> > 1 - VDSM will have to pass through 2 proxies (libvirt&  qemu) in order to
> > deliver a message to the guest, this byiself is not such a big
> > disadvantage but will force us to handle much more corner-cases.
> 
> Can't rule out the possibility of corner-cases resulting from this, but
> the practical way to look at it is VDSM will need handle libvirt/QMP
> protocols well. The implementation of the proxying mechanism is where
> the extra challenge comes into play, but this should be transparent to
> the protocols VDSM speaks.
> 
> Implementation-wise, just to give you an idea of the work involved if we
> took this route:
> 
> 1) ovirt-guest-agent would need to convert request/response payloads
> from/to QMP payloads on the guest-side, which are JSON and should,
> theoretically, mesh well with a python-based agent.



ovirt-guest-agent already uses JSON for communication with VDSM 



> 
> 2) You'd also need a schema, similar to qemu.git/qapi-schema-guest.json,
> to describe the calls you're proxying. The existing infrastructure in
> QEMU will handle all the work of marshalling/unmarshalling responses
> back to the QMP client on the host-side.
> 
> It's a bit of extra work, but the benefit is unifying the
> qemu/guest-level management interface into a single place that's easy
> for QMP/libvirt to consume.
> 

The issue is not whether it's possible or not or the amount of efforts need to 
be done for that to happen, either for qemu-ga or ovirt-guest-agent this work 
needs to be done.

the question is whether all comminication should go through the monitor (hence 
double proxy) or ... only a subset of the commands that are closly related to 
hypervisor functionality and separate it from general management-system 
related actions (e.g. ovirt or any other management system that wants to 
communicate to the guest).



> > 2 - looking at the qemu-ga functionality (read&  write ...) do we really
> > want to let a big chunk of data through both qemu&  libvirt rather than
> > directtly to the comsumer (VDSM)
> 
> VDSM isn't the only consumer however, HMP/QMP and libvirt are consumers
> in and of themselves.


This is not the claim it was just an example, it may as well be any other 
management system.

The question still remains, if we want to pass a big chunk of data, do we want 
it to be passed through this double proxy layer ? personally I think it does 
not belong to core hypervisor management interface.

> 
> > 3 - When events are fired from the guest agent, the delay of passing it
> > through a double proxy will have it's latency penalty (as we have
> > experianced in the client disconnect spice event)
> 
> Getting them out of the guest is probably the biggest factor, delivering
> them between processes on the host is likely a small hit in comparison.
> 

From our experiance in the last 3 years this latency (passing a single proxy 
layer, libvirt) , affected the overall functionality & behaviour. However 
using libvirt as a monitor proxy also gave us some advantages, the question is 
what are the advantages of passing ALL guest-agent protocol through qemu ?



> >>> I envision the agent will have 2 separate ports to listen to, one to
> >>> communicate to qemu and one for VDSM.
> >> 
> >> Ugh, no, I'd much prefer a single 'bus' everyone attaches to.
> > 
> > why?
> > 
> > I'm thinking on situation we'll need to priorities commands arriving from
> > qemu over "management standard commands"&  info gathering, sure there
> > are number of mechanisms to do that but it seems to me that a separation
> > is the best way.
> > 
> > e.g. I think we need to priorities a quiesce command from qemu over any
> > other info/command from VDSM.
> 
> Do you mean prioritize in terms of order of delivery? Best way to do
> that is a single protocol with state-tracking, otherwise we're just racing.
> 
> >> Alex
> >> 
> >>> Barak
> >>> 
> >>>> Alex

Re: [Qemu-devel] converging around a single guest agent

[Michael Roth]

On 11/16/2011 11:53 AM, Barak Azulay wrote:
> On Wednesday 16 November 2011 17:28:16 Michael Roth wrote:
>> On 11/16/2011 06:13 AM, Barak Azulay wrote:
>>> On Wednesday 16 November 2011 10:16:57 Alexander Graf wrote:
>>>> On 16.11.2011, at 08:05, Barak Azulay<bazulay@redhat.com>   wrote:
>>>>> On Wednesday 16 November 2011 02:42:30 Alexander Graf wrote:
>>>>>> On 16.11.2011, at 00:01, Michael Roth wrote:
>>>>>>> But practically-speaking, it's unavoidable that qemu-specific
>>>>>>> management tooling will need to communicate with qemu (via
>>>>>>> QMP/libqmp/HMP/etc, or by proxy via libvirt). It's through those same
>>>>>>> channels that the qemu-ga interfaces will ultimately be exposed, so
>>>>>>> the problem of qemu-ga vs. ovirt-guest-agent isn't really any
>>>>>>> different than the problem of QMP's system_powerdown/info_balloon/etc
>>>>>>> vs. ovirt-guest-agent's
>>>>>>> Shutdown/Available_Ram/etc: it's a policy decision rather than
>>>>>>> argument for choosing one project over another.
>>>>>>
>>>>>> I don't see why we shouldn't be able to just proxy whatever
>>>>>> communication happens between the guest agent and the management tool
>>>>>> through qemu. At that point qemu could talk to the guest agent just as
>>>>>> well as the management tool and everyone's happy.
>>>>>
>>>>> I'm not sure proxying all the requests to the guset through qemu is
>>>>> desirable, other than having single point of management, most of the
>>>>> calls will be pass throgh and has no interest to qemu (MITM?).
>>>>>
>>>>> There is a big advantage on direct communication (VDSM<->   agent), that
>>>>> way features can be added to the ovirt stack without the need to add it
>>>>> to the qemu.
>>>>
>>>> If we keep the protocol well-defined, we can get that for free. Just
>>>> have every command carry its own size and a request id shich the reply
>>>> also contains and suddenly you get asynchronous proxyable
>>>> communication.
>>>
>>> Sure we can keep commands synchronized in various ways the question is do
>>> we want that, there are a few down sides for that:
>>> 1 - VDSM will have to pass through 2 proxies (libvirt&   qemu) in order to
>>> deliver a message to the guest, this byiself is not such a big
>>> disadvantage but will force us to handle much more corner-cases.
>>
>> Can't rule out the possibility of corner-cases resulting from this, but
>> the practical way to look at it is VDSM will need handle libvirt/QMP
>> protocols well. The implementation of the proxying mechanism is where
>> the extra challenge comes into play, but this should be transparent to
>> the protocols VDSM speaks.
>>
>> Implementation-wise, just to give you an idea of the work involved if we
>> took this route:
>>
>> 1) ovirt-guest-agent would need to convert request/response payloads
>> from/to QMP payloads on the guest-side, which are JSON and should,
>> theoretically, mesh well with a python-based agent.
>
>
>
> ovirt-guest-agent already uses JSON for communication with VDSM
>
>
>
>>
>> 2) You'd also need a schema, similar to qemu.git/qapi-schema-guest.json,
>> to describe the calls you're proxying. The existing infrastructure in
>> QEMU will handle all the work of marshalling/unmarshalling responses
>> back to the QMP client on the host-side.
>>
>> It's a bit of extra work, but the benefit is unifying the
>> qemu/guest-level management interface into a single place that's easy
>> for QMP/libvirt to consume.
>>
>
> The issue is not whether it's possible or not or the amount of efforts need to
> be done for that to happen, either for qemu-ga or ovirt-guest-agent this work
> needs to be done.

Right, just trying to flesh out the areas where the extra corner-cases 
argument to this approach would be relevant. On the host-side the corner 
cases are something that already needs to be handled in the context of 
QMP/libvirt in general, it's in the implementation of 1) and 2) on the 
agent side where they'd potentially arise.

>
> the question is whether all comminication should go through the monitor (hence
> double proxy) or ... only a subset of the commands that are closly related to
> hypervisor functionality and separate it from general management-system
> related actions (e.g. ovirt or any other management system that wants to
> communicate to the guest).
>
>
>
>>> 2 - looking at the qemu-ga functionality (read&   write ...) do we really
>>> want to let a big chunk of data through both qemu&   libvirt rather than
>>> directtly to the comsumer (VDSM)
>>
>> VDSM isn't the only consumer however, HMP/QMP and libvirt are consumers
>> in and of themselves.
>
>
> This is not the claim it was just an example, it may as well be any other
> management system.
>
> The question still remains, if we want to pass a big chunk of data, do we want
> it to be passed through this double proxy layer ? personally I think it does
> not belong to core hypervisor management interface.

The common use case in practice has been reading things like 
/proc/meminfo, which ties into higher-level guest statistics collection.

I agree that for large data transfers this is not the ideal interface, 
but we can opt to not use the interface for such purposes at that level 
and avoid the potential for bad performance entirely.

>
>>
>>> 3 - When events are fired from the guest agent, the delay of passing it
>>> through a double proxy will have it's latency penalty (as we have
>>> experianced in the client disconnect spice event)
>>
>> Getting them out of the guest is probably the biggest factor, delivering
>> them between processes on the host is likely a small hit in comparison.
>>
>
>  From our experiance in the last 3 years this latency (passing a single proxy
> layer, libvirt) , affected the overall functionality&  behaviour. However
> using libvirt as a monitor proxy also gave us some advantages, the question is
> what are the advantages of passing ALL guest-agent protocol through qemu ?
>

There's the existing argument of coding against a single 
transport/interface which I think is generally applicable. Beyond that, 
events are a particularly good example actually: QEMU already has a 
state machine to aid lifecycle management and handle device callbacks, 
this data is then made available at the QMP-layer.

A management interface at all levels of the stack will want to know 
things like whether the guest is in the middle of a migration, or 
paused, or in an error state, which you get via QMP.

QEMU itself would benefit from additional guest-driven events like 
reboots, copy(/paste) notifications, etc, since these events can drive 
the state machine, or trigger device callbacks. We can then propagate 
the events up the stack via the existing (or a new) notification system 
for state changes.

If we bypass QEMU in reporting these events we complicate things at the 
management level: we're augmenting events reported by QMP with racy 
out-of-band events, and taking events away from QEMU that could be 
useful internally.

>
>
>>>>> I envision the agent will have 2 separate ports to listen to, one to
>>>>> communicate to qemu and one for VDSM.
>>>>
>>>> Ugh, no, I'd much prefer a single 'bus' everyone attaches to.
>>>
>>> why?
>>>
>>> I'm thinking on situation we'll need to priorities commands arriving from
>>> qemu over "management standard commands"&   info gathering, sure there
>>> are number of mechanisms to do that but it seems to me that a separation
>>> is the best way.
>>>
>>> e.g. I think we need to priorities a quiesce command from qemu over any
>>> other info/command from VDSM.
>>
>> Do you mean prioritize in terms of order of delivery? Best way to do
>> that is a single protocol with state-tracking, otherwise we're just racing.
>>
>>>> Alex
>>>>
>>>>> Barak
>>>>>
>>>>>> Alex
>

Re: [Qemu-devel] converging around a single guest agent

[Anthony Liguori]

On 11/16/2011 11:53 AM, Barak Azulay wrote:
> On Wednesday 16 November 2011 17:28:16 Michael Roth wrote:
>> 2) You'd also need a schema, similar to qemu.git/qapi-schema-guest.json,
>> to describe the calls you're proxying. The existing infrastructure in
>> QEMU will handle all the work of marshalling/unmarshalling responses
>> back to the QMP client on the host-side.
>>
>> It's a bit of extra work, but the benefit is unifying the
>> qemu/guest-level management interface into a single place that's easy
>> for QMP/libvirt to consume.
>>
>
> The issue is not whether it's possible or not or the amount of efforts need to
> be done for that to happen, either for qemu-ga or ovirt-guest-agent this work
> needs to be done.
>
> the question is whether all comminication should go through the monitor (hence
> double proxy) or ... only a subset of the commands that are closly related to
> hypervisor functionality and separate it from general management-system
> related actions (e.g. ovirt or any other management system that wants to
> communicate to the guest).

Yes, all guest interaction should be funnelled through QEMU.  QEMU has one job 
in life--to expose an interface to guests and turn it into something more useful 
to the host.  QEMU expose an emulated AHCI controller and turns that into VFS 
operations.

Likewise, QEMU should expose a paravirtual "agent" device to a guest, and then 
turn that into higher level management interfaces.

QEMU's job is to sanitize information from the guest and try to turn that into 
something that is safer for the broader world to consume.  QEMU also deals with 
isolating state in order to support things like live migration.  This ends up 
being non trivial when it comes to guest agents as it turns out.

When you bypass QEMU and have higher level components talk directly to the 
guest, you effectively skip through many layers of security and potentially 
break things like migration by spreading state beyond QEMU.  It's of course 
fixable given enough hacking but it makes for a brittle architecture.

VDSM runs as root, right?  That means that a guest driven attack that exploits 
an issue with guest-agent protocol handling is going to compromise VDSM and gain 
root access.  OTOH, QEMU runs with greatly reduced privileges isolating the 
effect of such a compromise.

VDSM really shouldn't be talking directly to the guest.  libvirt shouldn't be 
either although it is now because we haven't properly plumbed the guest agent 
protocol through QMP.

Regards,

Anthony Liguori

Re: [Qemu-devel] converging around a single guest agent

[Ayal Baron]

----- Original Message -----
> On 11/16/2011 11:53 AM, Barak Azulay wrote:
> > On Wednesday 16 November 2011 17:28:16 Michael Roth wrote:
> >> 2) You'd also need a schema, similar to
> >> qemu.git/qapi-schema-guest.json,
> >> to describe the calls you're proxying. The existing infrastructure
> >> in
> >> QEMU will handle all the work of marshalling/unmarshalling
> >> responses
> >> back to the QMP client on the host-side.
> >>
> >> It's a bit of extra work, but the benefit is unifying the
> >> qemu/guest-level management interface into a single place that's
> >> easy
> >> for QMP/libvirt to consume.
> >>
> >
> > The issue is not whether it's possible or not or the amount of
> > efforts need to
> > be done for that to happen, either for qemu-ga or ovirt-guest-agent
> > this work
> > needs to be done.
> >
> > the question is whether all comminication should go through the
> > monitor (hence
> > double proxy) or ... only a subset of the commands that are closly
> > related to
> > hypervisor functionality and separate it from general
> > management-system
> > related actions (e.g. ovirt or any other management system that
> > wants to
> > communicate to the guest).
> 
> Yes, all guest interaction should be funnelled through QEMU.  QEMU
> has one job
> in life--to expose an interface to guests and turn it into something
> more useful
> to the host.  QEMU expose an emulated AHCI controller and turns that
> into VFS
> operations.
> 
> Likewise, QEMU should expose a paravirtual "agent" device to a guest,
> and then
> turn that into higher level management interfaces.

Exposing higher level management interfaces means that qemu would have to do policy.
I have no problem with this, but note that this is counter to what you've been advocating to up to now (e.g. high watermark event for disks).

Also, you would still have to have low level interfaces to accomplish things that qemu has not implemented yet or is not interested in implementing (the use case is too narrow).

> 
> QEMU's job is to sanitize information from the guest and try to turn
> that into
> something that is safer for the broader world to consume.  QEMU also
> deals with
> isolating state in order to support things like live migration.  This

So are you suggesting that when a user reads a file you would automatically encode the contents?

> ends up
> being non trivial when it comes to guest agents as it turns out.
> 
> When you bypass QEMU and have higher level components talk directly
> to the
> guest, you effectively skip through many layers of security and
> potentially
> break things like migration by spreading state beyond QEMU.  It's of
> course
> fixable given enough hacking but it makes for a brittle architecture.
> 
> VDSM runs as root, right?  That means that a guest driven attack that

No, vdsm runs as user vdsm.  Operations that need root privileges are in a separate process with root privileges and this process exposes a limited API which vdsm is allowed to invoke.

> exploits
> an issue with guest-agent protocol handling is going to compromise
> VDSM and gain
> root access.  OTOH, QEMU runs with greatly reduced privileges
> isolating the
> effect of such a compromise.
> 
> VDSM really shouldn't be talking directly to the guest.  libvirt
> shouldn't be
> either although it is now because we haven't properly plumbed the
> guest agent
> protocol through QMP.
> 
> Regards,
> 
> Anthony Liguori
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel
> 

Re: [Qemu-devel] converging around a single guest agent

[Anthony Liguori]

On 11/17/2011 02:59 AM, Ayal Baron wrote:
>
>
> ----- Original Message -----
>> On 11/16/2011 11:53 AM, Barak Azulay wrote:
>>> On Wednesday 16 November 2011 17:28:16 Michael Roth wrote:
>>>> 2) You'd also need a schema, similar to
>>>> qemu.git/qapi-schema-guest.json,
>>>> to describe the calls you're proxying. The existing infrastructure
>>>> in
>>>> QEMU will handle all the work of marshalling/unmarshalling
>>>> responses
>>>> back to the QMP client on the host-side.
>>>>
>>>> It's a bit of extra work, but the benefit is unifying the
>>>> qemu/guest-level management interface into a single place that's
>>>> easy
>>>> for QMP/libvirt to consume.
>>>>
>>>
>>> The issue is not whether it's possible or not or the amount of
>>> efforts need to
>>> be done for that to happen, either for qemu-ga or ovirt-guest-agent
>>> this work
>>> needs to be done.
>>>
>>> the question is whether all comminication should go through the
>>> monitor (hence
>>> double proxy) or ... only a subset of the commands that are closly
>>> related to
>>> hypervisor functionality and separate it from general
>>> management-system
>>> related actions (e.g. ovirt or any other management system that
>>> wants to
>>> communicate to the guest).
>>
>> Yes, all guest interaction should be funnelled through QEMU.  QEMU
>> has one job
>> in life--to expose an interface to guests and turn it into something
>> more useful
>> to the host.  QEMU expose an emulated AHCI controller and turns that
>> into VFS
>> operations.
>>
>> Likewise, QEMU should expose a paravirtual "agent" device to a guest,
>> and then
>> turn that into higher level management interfaces.
>
> Exposing higher level management interfaces means that qemu would have to do policy.

No, the way we plan on doing this is having a guest agent schema 
(qapi-schema-guest.json) that we can use to (1) white list valid operations and 
(2) decode and re-encode operations.

(1) let's us validate that guest state isn't escaping which keeps migration safe

(2) let's us scrub any potentially malicious input from the guest before we hand 
it off to the management tool.

Otherwise, we don't get in the middle and don't really care what the verbs are.

>>
>> QEMU's job is to sanitize information from the guest and try to turn
>> that into
>> something that is safer for the broader world to consume.  QEMU also
>> deals with
>> isolating state in order to support things like live migration.  This
>
> So are you suggesting that when a user reads a file you would automatically encode the contents?

I'm not sure I understand what you're suggesting.

Here's another way to think of this.  In a typical enterprise environment, you 
would secure your network infrastructure using isolated zones.  You may have a 
red zone (guest networking), a yellow zone (management network), and a green 
zone (broader intranet).  The zones are physically separate with very few things 
that exist on two zones.

You pay special attention to anything that crosses zones and try to minimize 
them as much as possible.  You never allow something to live on more than two zones.

The guest is the red zone and the rest of the host environment is the yellow 
zone.  QEMU bridges between the red and yellow zone.  That is fundamentally its 
job in the stack.

Other than the guest agent, VDSM lives purely in the yellow zone.  In fact, VDSM 
bridges from the yellow zone to the green zone (broader management infrastructure).

It may be easier to skip QEMU and have VDSM also stride into the red zone.  It's 
always easier to cross zones.  But it's not good security practice.  There is 
tremendous value in having clean security layers.

Regards,

Anthony Liguori

Re: [Qemu-devel] converging around a single guest agent

[Daniel P. Berrange]

On Tue, Nov 15, 2011 at 05:01:00PM -0600, Michael Roth wrote:
> On 11/15/2011 11:24 AM, Barak Azulay wrote:
> >Hi,
> >
> >One of the breakout sessions during the ovirt workshop [1] was about the guest
> >tools, and focused mainly on the ovirt-guest-agent [2].
> >
> >One of the issues discussed there, was the various existing guest agents out
> >there, and the need to converge the efforts to a single agent that will serve
> >all.
> >
> >while 4 agents were mentioned (Matahari, vdagent, qemu-ga&  ovirt-guest-agent)
> >during that discussion, we narrowed it down to 2 candidates:
> >
> >qemu-ga (aka virt-agent):
> >-------------------------
> >- Qemu specific - it was aimed for specific qemu needs (mainly quiesce guest
> >I/O)
> >- Communicates directly with qemu  (not implemented yet)
> 
> Won't be implemented until we finish the QMP conversion to QAPI
> since that's a prereq to implementing a QMP server with proper async
> support (needed for communication with a potentially non-responsive
> guest agent). But once it's in guest extensions are completely
> transparent to QMP/libvirt, which is highly desirable from a
> management perspective since you're coding against a single
> API/transport.

FYI, I already have patches for libvirt to make it directly talk
to a QEMU guest agent for a guest. We just configure the guest
agent with a UNIX socket on the host, and livirt talks QMP to
that directly. It was trivial, since the agent uses the same
basic protocol as the QMP monitor, so from that POV I really like
the QEMU guest agent for libvirt integration, and loathe to have
to integrate with something that has invented yet another comms
protocol. I expect we'll merge these patches in libvirt 0.9.8
and my intent is for Fedora 17 guests to have qemu-ga installed
by default, so we get reliable guest shutdown/reboot support at
last.

 https://www.redhat.com/archives/libvir-list/2011-October/msg00135.html

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

Re: [Qemu-devel] converging around a single guest agent

[Adam Litke]

I have been following this thread pretty closely and the one sentence summary of
the current argument is: ovirt-guest-agent is already featureful and tested, so
let's drop qemu-ga and have everyone adopt ovirt-guest-agent.  Unfortunately,
this track strays completely away from the stated goal of convergence.  I have
at least two examples of why the greater KVM community can never adopt
ovirt-guest-agent as-is.  To address this, I would like to counter with an
example on how qemu-ga can enable the deployment of ovirt-guest-agent features
and satisfy the needs of the whole community at the same time.

1) Scope:  The ovirt-guest-agent contains functionality that is incredibly
useful within the context of oVirt.  Single Sign-on is very handy but KVM users
outside the scope of oVirt will not want this extra complexity in their agent.
For simplicity they will probably just write something small that does what they
need (and we have failed to provide a ubiquitous KVM agent).

1) Deployment complexity: The more complex the guest agent is, the more often it
will need to be updated (bug/security fixes, distro compatibility, new
features).  Rolling out guest agent updates does not scale well in large
environments (especially when the guest and host administrators are not the same
person).

For these reasons (and many others), I support having an agent with very basic
primitives that can be orchestrated by the host to provide needed functionality.
This agent would present a low-level, stable, extensible API that everyone can
use.  Today qemu-ga supports the following verbs: sync ping info shutdown
file-open file-close file-read file-write file-seek file-flush fsfreeze-status
fsfreeze-freeze fsfreeze-thaw.  If we add a generic execute mechanism, then the
agent can provide everything needed by oVirt to deploy SSO.

Let's assume that we have already agreed on some sort of security policy for the
write-file and exec primitives.  Consensus is possible on this issue but I
don't want to get bogged down with that here.

With the above primitives, SSO could be deployed automatically to a guest with
the following sequence of commands:

file-open "<exec-dir>/sso-package.bin" "w"
file-write <fh> <buf>
file-close <fh>
file-open "<exec-dir>/sso-package.bin" "x"
file-exec <fh> <args>
file-close <fh>

At this point, the package is installed.  It can contain whatever existing logic
exists in the ovirt-guest-agent today.  To perform a user login, we'll assume
that sso-package.bin contains an executable 'sso/do-user-sso':

file-open "<exec-dir>/sso/do-user-sso" "x"
exec <fh> <args>
file-close <fh>

At this point the user would be logged in as before.

Obviously, this type of approach could be made easier by providing a well
designed exec API that returns command exit codes and (optionally) command
output.  We could also formalize the install of additional components into some
sort of plugin interface.  These are all relatively easy problems to solve.

If we go in this direction, we would have a simple, general-purpose agent with
low-level primitives that everyone can use.  We would also be able to easily
extend the agent based on the needs of individual deployments (not the least of
which is an oVirt environment).  If certain plugins become popular enough, they
can always be promoted to first-order API calls in future versions of the API.

What are your thoughts on this approach?

-- 
Adam Litke <agl@us.ibm.com>
IBM Linux Technology Center

Re: [Qemu-devel] converging around a single guest agent

[Michael Roth]

On 11/16/2011 02:24 PM, Adam Litke wrote:
> I have been following this thread pretty closely and the one sentence summary of
> the current argument is: ovirt-guest-agent is already featureful and tested, so
> let's drop qemu-ga and have everyone adopt ovirt-guest-agent.  Unfortunately,
> this track strays completely away from the stated goal of convergence.  I have
> at least two examples of why the greater KVM community can never adopt
> ovirt-guest-agent as-is.  To address this, I would like to counter with an
> example on how qemu-ga can enable the deployment of ovirt-guest-agent features
> and satisfy the needs of the whole community at the same time.
>
> 1) Scope:  The ovirt-guest-agent contains functionality that is incredibly
> useful within the context of oVirt.  Single Sign-on is very handy but KVM users
> outside the scope of oVirt will not want this extra complexity in their agent.
> For simplicity they will probably just write something small that does what they
> need (and we have failed to provide a ubiquitous KVM agent).
>
> 1) Deployment complexity: The more complex the guest agent is, the more often it
> will need to be updated (bug/security fixes, distro compatibility, new
> features).  Rolling out guest agent updates does not scale well in large
> environments (especially when the guest and host administrators are not the same
> person).
>
> For these reasons (and many others), I support having an agent with very basic
> primitives that can be orchestrated by the host to provide needed functionality.
> This agent would present a low-level, stable, extensible API that everyone can
> use.  Today qemu-ga supports the following verbs: sync ping info shutdown
> file-open file-close file-read file-write file-seek file-flush fsfreeze-status
> fsfreeze-freeze fsfreeze-thaw.  If we add a generic execute mechanism, then the
> agent can provide everything needed by oVirt to deploy SSO.
>
> Let's assume that we have already agreed on some sort of security policy for the
> write-file and exec primitives.  Consensus is possible on this issue but I
> don't want to get bogged down with that here.
>
> With the above primitives, SSO could be deployed automatically to a guest with
> the following sequence of commands:
>
> file-open "<exec-dir>/sso-package.bin" "w"
> file-write<fh>  <buf>
> file-close<fh>
> file-open "<exec-dir>/sso-package.bin" "x"
> file-exec<fh>  <args>
> file-close<fh>
>
> At this point, the package is installed.  It can contain whatever existing logic
> exists in the ovirt-guest-agent today.  To perform a user login, we'll assume
> that sso-package.bin contains an executable 'sso/do-user-sso':
>
> file-open "<exec-dir>/sso/do-user-sso" "x"
> exec<fh>  <args>
> file-close<fh>
>
> At this point the user would be logged in as before.
>
> Obviously, this type of approach could be made easier by providing a well
> designed exec API that returns command exit codes and (optionally) command
> output.  We could also formalize the install of additional components into some
> sort of plugin interface.  These are all relatively easy problems to solve.
>
> If we go in this direction, we would have a simple, general-purpose agent with
> low-level primitives that everyone can use.  We would also be able to easily
> extend the agent based on the needs of individual deployments (not the least of
> which is an oVirt environment).  If certain plugins become popular enough, they
> can always be promoted to first-order API calls in future versions of the API.
>
> What are your thoughts on this approach?
>

Another possibility, for functionality that may be more suited for a 
daemon that needs to maintain a lot of state, would be modifying the 
ovirt-guest-agent code to read/write to a (guest-local) named pipe. We 
can could then deploy the daemon via file-write+exec (assuming we 
provide a fork/detach flag), and the management tool could do 
request/response via file-write/file-read.

It's almost equivalent to reading/writing directly to a virtio-serial 
channel, except there'd need to be a translation 
(base64decode(qmp_json_response.payload)->oga_json_response, and 
vice-versa) at the ovirt management layer.

And we still reduce the deployment complexity since we can 
deploy/upgrade via a hypervisor push.

There's actually so many ways this could be done with exec support...

What's being lost in both approaches are ovirt-guest-agent-provided 
events, however. We'd either need to subsume those into qemu-ga, or 
provide a proxying mechanism on the guest-side for event reporting, 
which is something we've discussed in the past with the Spice folks with 
regard to support for session-level agents.

Re: [Qemu-devel] converging around a single guest agent

[Ayal Baron]

----- Original Message -----
> I have been following this thread pretty closely and the one sentence
> summary of
> the current argument is: ovirt-guest-agent is already featureful and
> tested, so
> let's drop qemu-ga and have everyone adopt ovirt-guest-agent.

What we're suggesting is let's drop *one* of the two agents (obviously it would be easier for us to drop qemu-ga, but we'd rather reach consensus and unite behind one agent regardless of which agent it is).

>  Unfortunately,
> this track strays completely away from the stated goal of
> convergence.  I have
> at least two examples of why the greater KVM community can never
> adopt
> ovirt-guest-agent as-is.  To address this, I would like to counter
> with an
> example on how qemu-ga can enable the deployment of ovirt-guest-agent
> features
> and satisfy the needs of the whole community at the same time.
> 
> 1) Scope:  The ovirt-guest-agent contains functionality that is
> incredibly
> useful within the context of oVirt.  Single Sign-on is very handy but
> KVM users
> outside the scope of oVirt will not want this extra complexity in
> their agent.
> For simplicity they will probably just write something small that
> does what they
> need (and we have failed to provide a ubiquitous KVM agent).

I totally agree, but that could easily be resolved using the plugin architecture suggested before.

> 
> 1) Deployment complexity: The more complex the guest agent is, the
> more often it
> will need to be updated (bug/security fixes, distro compatibility,
> new
> features).  Rolling out guest agent updates does not scale well in
> large
> environments (especially when the guest and host administrators are
> not the same
> person).

Using plugins, you just deploy the ones you need, keeping the attack surface / #bugs / need to update lower

> 
> For these reasons (and many others), I support having an agent with
> very basic
> primitives that can be orchestrated by the host to provide needed
> functionality.
> This agent would present a low-level, stable, extensible API that
> everyone can
> use.  Today qemu-ga supports the following verbs: sync ping info
> shutdown
> file-open file-close file-read file-write file-seek file-flush
> fsfreeze-status
> fsfreeze-freeze fsfreeze-thaw.  If we add a generic execute
> mechanism, then the
> agent can provide everything needed by oVirt to deploy SSO.
> 
> Let's assume that we have already agreed on some sort of security
> policy for the
> write-file and exec primitives.  Consensus is possible on this issue
> but I
> don't want to get bogged down with that here.
> 
> With the above primitives, SSO could be deployed automatically to a
> guest with
> the following sequence of commands:
> 
> file-open "<exec-dir>/sso-package.bin" "w"
> file-write <fh> <buf>
> file-close <fh>
> file-open "<exec-dir>/sso-package.bin" "x"
> file-exec <fh> <args>
> file-close <fh>

The guest can run on any number of hosts.  currently, the guest tools contain all the relevant logic installed (specifically for the guest os version).
What you're suggesting here is that we keep all the relevant guest-agent variants code on the host, automatically detect the guest os version and inject the correct file (e.g. SSO on winXP and on win2k8 is totally different).
In addition, there might be things requiring boot for example. So to solve that we would instead need to install a set of tools on the guest like we do the guest agent today (it would be a separate package because it's management specific).  And then we would tell the guest-agent to run tools from that set?  Sounds overly complex to me.

> 
> At this point, the package is installed.  It can contain whatever
> existing logic
> exists in the ovirt-guest-agent today.  To perform a user login,
> we'll assume
> that sso-package.bin contains an executable 'sso/do-user-sso':
> 
> file-open "<exec-dir>/sso/do-user-sso" "x"
> exec <fh> <args>
> file-close <fh>
> 
> At this point the user would be logged in as before.
> 
> Obviously, this type of approach could be made easier by providing a
> well
> designed exec API that returns command exit codes and (optionally)
> command
> output.  We could also formalize the install of additional components
> into some
> sort of plugin interface.  These are all relatively easy problems to
> solve.
> 
> If we go in this direction, we would have a simple, general-purpose
> agent with
> low-level primitives that everyone can use.  We would also be able to
> easily
> extend the agent based on the needs of individual deployments (not
> the least of
> which is an oVirt environment).  If certain plugins become popular
> enough, they
> can always be promoted to first-order API calls in future versions of
> the API.
> 
> What are your thoughts on this approach?
> 
> --
> Adam Litke <agl@us.ibm.com>
> IBM Linux Technology Center
> 
> _______________________________________________
> Arch mailing list
> Arch@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 

Re: [Qemu-devel] converging around a single guest agent

[Michael Roth]

On 11/17/2011 02:46 AM, Ayal Baron wrote:
>
>
> ----- Original Message -----
>> I have been following this thread pretty closely and the one sentence
>> summary of
>> the current argument is: ovirt-guest-agent is already featureful and
>> tested, so
>> let's drop qemu-ga and have everyone adopt ovirt-guest-agent.
>
> What we're suggesting is let's drop *one* of the two agents (obviously it would be easier for us to drop qemu-ga, but we'd rather reach consensus and unite behind one agent regardless of which agent it is).
>
>>   Unfortunately,
>> this track strays completely away from the stated goal of
>> convergence.  I have
>> at least two examples of why the greater KVM community can never
>> adopt
>> ovirt-guest-agent as-is.  To address this, I would like to counter
>> with an
>> example on how qemu-ga can enable the deployment of ovirt-guest-agent
>> features
>> and satisfy the needs of the whole community at the same time.
>>
>> 1) Scope:  The ovirt-guest-agent contains functionality that is
>> incredibly
>> useful within the context of oVirt.  Single Sign-on is very handy but
>> KVM users
>> outside the scope of oVirt will not want this extra complexity in
>> their agent.
>> For simplicity they will probably just write something small that
>> does what they
>> need (and we have failed to provide a ubiquitous KVM agent).
>
> I totally agree, but that could easily be resolved using the plugin architecture suggested before.
>
>>
>> 1) Deployment complexity: The more complex the guest agent is, the
>> more often it
>> will need to be updated (bug/security fixes, distro compatibility,
>> new
>> features).  Rolling out guest agent updates does not scale well in
>> large
>> environments (especially when the guest and host administrators are
>> not the same
>> person).
>
> Using plugins, you just deploy the ones you need, keeping the attack surface / #bugs / need to update lower

But you still need to deploy those plugins somehow, so the logistics of 
distributing this code to multiple types/levels of guests remains, and 
plugins are insufficient to handle security fixes in the core code 
(however small that attack surface may be). Eventually you'll need a 
newer version of the guest agent installed.

qemu-ga could be the vehicle for delivering those ovirt plugins/updates, 
and qemu-ga can upgrade itself to handle it's own security fixes/updates.

With this model you can keep your agent functionality closely tied to 
the high-level management infrastructure, take liberties in what 
features/changes you need to add/make, and push-deploy those changes 
through qemu-ga. Low-level primitives to build high-level interfaces 
higher up the stack has always been a primary design goal so this all 
fits together fairly well from a QEMU perspective. The extra 
orchestration required is worth it, IMO, as the alternative is limiting 
customers to a particular distro, installing a similar backend, or 
shooting out emails to everyone asking them to update their guest agent 
so you can leverage feature X.

>
>>
>> For these reasons (and many others), I support having an agent with
>> very basic
>> primitives that can be orchestrated by the host to provide needed
>> functionality.
>> This agent would present a low-level, stable, extensible API that
>> everyone can
>> use.  Today qemu-ga supports the following verbs: sync ping info
>> shutdown
>> file-open file-close file-read file-write file-seek file-flush
>> fsfreeze-status
>> fsfreeze-freeze fsfreeze-thaw.  If we add a generic execute
>> mechanism, then the
>> agent can provide everything needed by oVirt to deploy SSO.
>>
>> Let's assume that we have already agreed on some sort of security
>> policy for the
>> write-file and exec primitives.  Consensus is possible on this issue
>> but I
>> don't want to get bogged down with that here.
>>
>> With the above primitives, SSO could be deployed automatically to a
>> guest with
>> the following sequence of commands:
>>
>> file-open "<exec-dir>/sso-package.bin" "w"
>> file-write<fh>  <buf>
>> file-close<fh>
>> file-open "<exec-dir>/sso-package.bin" "x"
>> file-exec<fh>  <args>
>> file-close<fh>
>
> The guest can run on any number of hosts.  currently, the guest tools contain all the relevant logic installed (specifically for the guest os version).
> What you're suggesting here is that we keep all the relevant guest-agent variants code on the host, automatically detect the guest os version and inject the correct file (e.g. SSO on winXP and on win2k8 is totally different).
> In addition, there might be things requiring boot for example. So to solve that we would instead need to install a set of tools on the guest like we do the guest agent today (it would be a separate package because it's management specific).  And then we would tell the guest-agent to run tools from that set?  Sounds overly complex to me.
>

The nature of the tools is more an implementation detail. It could also 
be distributed the same way it is now, except with a CLI interface or 
something rather than via virtio-serial.

Going even further, I posted another approach where ovirt-guest-agent 
just speaks to a local pipe, and qemu-ga execs ovirt-guest-agent and 
proxies RPCs via it's existing file-read/file-write interfaces. With a 
small amount work we could even provide an ovirt-exec command that 
automatically does the setup if required and takes "native" 
ovirt-guest-guest agent JSON requests/responses and nests them with a 
qemu-ga JSON request/response. So you get instant all the benefits of 
using the same transport as QMP, and QMP users get easy access to 
ovirt-guest-agent features.

Not saying that's a better approach than deploying sets of scripts, but 
there's a lot of flexibility here with at least a couple that have 
virtually no negative impact to how extensible or consumable 
ovirt-guest-agent is at the high-level management level.

>>
>> At this point, the package is installed.  It can contain whatever
>> existing logic
>> exists in the ovirt-guest-agent today.  To perform a user login,
>> we'll assume
>> that sso-package.bin contains an executable 'sso/do-user-sso':
>>
>> file-open "<exec-dir>/sso/do-user-sso" "x"
>> exec<fh>  <args>
>> file-close<fh>
>>
>> At this point the user would be logged in as before.
>>
>> Obviously, this type of approach could be made easier by providing a
>> well
>> designed exec API that returns command exit codes and (optionally)
>> command
>> output.  We could also formalize the install of additional components
>> into some
>> sort of plugin interface.  These are all relatively easy problems to
>> solve.
>>
>> If we go in this direction, we would have a simple, general-purpose
>> agent with
>> low-level primitives that everyone can use.  We would also be able to
>> easily
>> extend the agent based on the needs of individual deployments (not
>> the least of
>> which is an oVirt environment).  If certain plugins become popular
>> enough, they
>> can always be promoted to first-order API calls in future versions of
>> the API.
>>
>> What are your thoughts on this approach?
>>
>> --
>> Adam Litke<agl@us.ibm.com>
>> IBM Linux Technology Center
>>
>> _______________________________________________
>> Arch mailing list
>> Arch@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>
>

Re: [Qemu-devel] converging around a single guest agent

[Adam Litke]

On Thu, Nov 17, 2011 at 03:46:37AM -0500, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
> > I have been following this thread pretty closely and the one sentence
> > summary of the current argument is: ovirt-guest-agent is already featureful
> > and tested, so let's drop qemu-ga and have everyone adopt ovirt-guest-agent.
> 
> What we're suggesting is let's drop *one* of the two agents (obviously it
> would be easier for us to drop qemu-ga, but we'd rather reach consensus and
> unite behind one agent regardless of which agent it is).
> 
> >  Unfortunately, this track strays completely away from the stated goal of
> >  convergence.  I have at least two examples of why the greater KVM community
> >  can never adopt ovirt-guest-agent as-is.  To address this, I would like to
> >  counter with an example on how qemu-ga can enable the deployment of
> >  ovirt-guest-agent features and satisfy the needs of the whole community at
> >  the same time.
> > 
> > 1) Scope:  The ovirt-guest-agent contains functionality that is incredibly
> > useful within the context of oVirt.  Single Sign-on is very handy but KVM
> > users outside the scope of oVirt will not want this extra complexity in
> > their agent.  For simplicity they will probably just write something small
> > that does what they need (and we have failed to provide a ubiquitous KVM
> > agent).
> 
> I totally agree, but that could easily be resolved using the plugin
> architecture suggested before.
> 
> > 
> > 1) Deployment complexity: The more complex the guest agent is, the more
> > often it will need to be updated (bug/security fixes, distro compatibility,
> > new features).  Rolling out guest agent updates does not scale well in large
> > environments (especially when the guest and host administrators are not the
> > same person).
> 
> Using plugins, you just deploy the ones you need, keeping the attack surface /
> #bugs / need to update lower

In order for any KVM guest agent to become ubiquitous, I think the code _must_ live
in the qemu repository.  This includes the base infrastructure and a core set of
plugins to provide the current set of qemu-ga APIs.  This way, both endpoints
(host/guest) can evolve together.  How easy would it be to extract this basic
infrastructure from the ovirt-guest-agent?  Is the qemu project opposed to a
Python agent?

> > For these reasons (and many others), I support having an agent with very
> > basic primitives that can be orchestrated by the host to provide needed
> > functionality.  This agent would present a low-level, stable, extensible API
> > that everyone can use.  Today qemu-ga supports the following verbs: sync
> > ping info shutdown file-open file-close file-read file-write file-seek
> > file-flush fsfreeze-status fsfreeze-freeze fsfreeze-thaw.  If we add a
> > generic execute mechanism, then the agent can provide everything needed by
> > oVirt to deploy SSO.
> > 
> > Let's assume that we have already agreed on some sort of security policy for
> > the write-file and exec primitives.  Consensus is possible on this issue but
> > I don't want to get bogged down with that here.
> > 
> > With the above primitives, SSO could be deployed automatically to a guest
> > with the following sequence of commands:
> > 
> > file-open "<exec-dir>/sso-package.bin" "w" file-write <fh> <buf> file-close
> > <fh> file-open "<exec-dir>/sso-package.bin" "x" file-exec <fh> <args>
> > file-close <fh>
> 
> The guest can run on any number of hosts.  currently, the guest tools contain
> all the relevant logic installed (specifically for the guest os version).
> What you're suggesting here is that we keep all the relevant guest-agent
> variants code on the host, automatically detect the guest os version and
> inject the correct file (e.g. SSO on winXP and on win2k8 is totally
> different).  In addition, there might be things requiring boot for example. So
> to solve that we would instead need to install a set of tools on the guest
> like we do the guest agent today (it would be a separate package because it's
> management specific).  And then we would tell the guest-agent to run tools
> from that set?  Sounds overly complex to me.

We already have that packaging complexity today.  You must already maintain the
various Windows packages somewhere.  You'd just be pushing them from the host
instead.  Could you provide examples of the things required for boot?  If you
are talking virtio drivers, I think this is a separate problem.  I would argue
that vdsm should have a hardware "safe-mode" when the guest tools are not
installed.  This would be a set of hardware exposed that is known to work with
all guests.  Then, when the guest tools are installed, the hardware can be
"upgraded" since we will know the guest can support paravirt hw.

> > At this point, the package is installed.  It can contain whatever existing
> > logic exists in the ovirt-guest-agent today.  To perform a user login, we'll
> > assume that sso-package.bin contains an executable 'sso/do-user-sso':
> > 
> > file-open "<exec-dir>/sso/do-user-sso" "x" exec <fh> <args> file-close <fh>
> > 
> > At this point the user would be logged in as before.
> > 
> > Obviously, this type of approach could be made easier by providing a well
> > designed exec API that returns command exit codes and (optionally) command
> > output.  We could also formalize the install of additional components into
> > some sort of plugin interface.  These are all relatively easy problems to
> > solve.
> > 
> > If we go in this direction, we would have a simple, general-purpose agent
> > with low-level primitives that everyone can use.  We would also be able to
> > easily extend the agent based on the needs of individual deployments (not
> > the least of which is an oVirt environment).  If certain plugins become
> > popular enough, they can always be promoted to first-order API calls in
> > future versions of the API.
> > 
> > What are your thoughts on this approach?
> > 
> > -- Adam Litke <agl@us.ibm.com> IBM Linux Technology Center
> > 
> > _______________________________________________ Arch mailing list
> > Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
> > 
> 

-- 
Adam Litke <agl@us.ibm.com>
IBM Linux Technology Center

Re: [Qemu-devel] converging around a single guest agent

[Daniel P. Berrange]

On Thu, Nov 17, 2011 at 09:58:33AM -0600, Adam Litke wrote:
> On Thu, Nov 17, 2011 at 03:46:37AM -0500, Ayal Baron wrote:
> > 
> > 
> > ----- Original Message -----
> > > I have been following this thread pretty closely and the one sentence
> > > summary of the current argument is: ovirt-guest-agent is already featureful
> > > and tested, so let's drop qemu-ga and have everyone adopt ovirt-guest-agent.
> > 
> > What we're suggesting is let's drop *one* of the two agents (obviously it
> > would be easier for us to drop qemu-ga, but we'd rather reach consensus and
> > unite behind one agent regardless of which agent it is).
> > 
> > >  Unfortunately, this track strays completely away from the stated goal of
> > >  convergence.  I have at least two examples of why the greater KVM community
> > >  can never adopt ovirt-guest-agent as-is.  To address this, I would like to
> > >  counter with an example on how qemu-ga can enable the deployment of
> > >  ovirt-guest-agent features and satisfy the needs of the whole community at
> > >  the same time.
> > > 
> > > 1) Scope:  The ovirt-guest-agent contains functionality that is incredibly
> > > useful within the context of oVirt.  Single Sign-on is very handy but KVM
> > > users outside the scope of oVirt will not want this extra complexity in
> > > their agent.  For simplicity they will probably just write something small
> > > that does what they need (and we have failed to provide a ubiquitous KVM
> > > agent).
> > 
> > I totally agree, but that could easily be resolved using the plugin
> > architecture suggested before.
> > 
> > > 
> > > 1) Deployment complexity: The more complex the guest agent is, the more
> > > often it will need to be updated (bug/security fixes, distro compatibility,
> > > new features).  Rolling out guest agent updates does not scale well in large
> > > environments (especially when the guest and host administrators are not the
> > > same person).
> > 
> > Using plugins, you just deploy the ones you need, keeping the attack surface /
> > #bugs / need to update lower
> 
> In order for any KVM guest agent to become ubiquitous, I think the code _must_ live
> in the qemu repository.  This includes the base infrastructure and a core set of
> plugins to provide the current set of qemu-ga APIs.  This way, both endpoints
> (host/guest) can evolve together.  How easy would it be to extract this basic
> infrastructure from the ovirt-guest-agent?  Is the qemu project opposed to a
> Python agent?

IMHO Python would be a really bad choice for the agent. An agent wants to be
maximally portable to any guest OS, regardless of its vintage. The changes
between each python release, even within the 2.x stream, let alone between
2.x and 3.x would cause us endless compatibility problems upon deployment.
And while python is common on Linux, we don't really want to get into the
business of installing the python runtime on Windows or other OS, simply to
run an agent.

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

Re: [Qemu-devel] converging around a single guest agent

[Eric Gaulin]

On Thu, Nov 17, 2011 at 11:14 AM, Daniel P. Berrange
<berrange@redhat.com> wrote:
> On Thu, Nov 17, 2011 at 09:58:33AM -0600, Adam Litke wrote:
>> On Thu, Nov 17, 2011 at 03:46:37AM -0500, Ayal Baron wrote:
>> >
>> >
>> > ----- Original Message -----
>> > > I have been following this thread pretty closely and the one sentence
>> > > summary of the current argument is: ovirt-guest-agent is already featureful
>> > > and tested, so let's drop qemu-ga and have everyone adopt ovirt-guest-agent.
>> >
>> > What we're suggesting is let's drop *one* of the two agents (obviously it
>> > would be easier for us to drop qemu-ga, but we'd rather reach consensus and
>> > unite behind one agent regardless of which agent it is).
>> >
>> > >  Unfortunately, this track strays completely away from the stated goal of
>> > >  convergence.  I have at least two examples of why the greater KVM community
>> > >  can never adopt ovirt-guest-agent as-is.  To address this, I would like to
>> > >  counter with an example on how qemu-ga can enable the deployment of
>> > >  ovirt-guest-agent features and satisfy the needs of the whole community at
>> > >  the same time.
>> > >
>> > > 1) Scope:  The ovirt-guest-agent contains functionality that is incredibly
>> > > useful within the context of oVirt.  Single Sign-on is very handy but KVM
>> > > users outside the scope of oVirt will not want this extra complexity in
>> > > their agent.  For simplicity they will probably just write something small
>> > > that does what they need (and we have failed to provide a ubiquitous KVM
>> > > agent).
>> >
>> > I totally agree, but that could easily be resolved using the plugin
>> > architecture suggested before.
>> >
>> > >
>> > > 1) Deployment complexity: The more complex the guest agent is, the more
>> > > often it will need to be updated (bug/security fixes, distro compatibility,
>> > > new features).  Rolling out guest agent updates does not scale well in large
>> > > environments (especially when the guest and host administrators are not the
>> > > same person).
>> >
>> > Using plugins, you just deploy the ones you need, keeping the attack surface /
>> > #bugs / need to update lower
>>
>> In order for any KVM guest agent to become ubiquitous, I think the code _must_ live
>> in the qemu repository.  This includes the base infrastructure and a core set of
>> plugins to provide the current set of qemu-ga APIs.  This way, both endpoints
>> (host/guest) can evolve together.  How easy would it be to extract this basic
>> infrastructure from the ovirt-guest-agent?  Is the qemu project opposed to a
>> Python agent?
>
> IMHO Python would be a really bad choice for the agent. An agent wants to be
> maximally portable to any guest OS, regardless of its vintage. The changes
> between each python release, even within the 2.x stream, let alone between
> 2.x and 3.x would cause us endless compatibility problems upon deployment.
> And while python is common on Linux, we don't really want to get into the
> business of installing the python runtime on Windows or other OS, simply to
> run an agent.
>
> Regards,
> Daniel
> --

I agree with Daniel,

A good example to get inspired from is the ZABBIX agent. A single C
source tree that can be compiled to many Unix and Windows binaries.

Eric Gaulin
___

Re: [Qemu-devel] converging around a single guest agent

[Barak Azulay]

On 11/17/2011 06:14 PM, Daniel P. Berrange wrote:
> On Thu, Nov 17, 2011 at 09:58:33AM -0600, Adam Litke wrote:
>> On Thu, Nov 17, 2011 at 03:46:37AM -0500, Ayal Baron wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> I have been following this thread pretty closely and the one sentence
>>>> summary of the current argument is: ovirt-guest-agent is already featureful
>>>> and tested, so let's drop qemu-ga and have everyone adopt ovirt-guest-agent.
>>>
>>> What we're suggesting is let's drop *one* of the two agents (obviously it
>>> would be easier for us to drop qemu-ga, but we'd rather reach consensus and
>>> unite behind one agent regardless of which agent it is).
>>>
>>>>   Unfortunately, this track strays completely away from the stated goal of
>>>>   convergence.  I have at least two examples of why the greater KVM community
>>>>   can never adopt ovirt-guest-agent as-is.  To address this, I would like to
>>>>   counter with an example on how qemu-ga can enable the deployment of
>>>>   ovirt-guest-agent features and satisfy the needs of the whole community at
>>>>   the same time.
>>>>
>>>> 1) Scope:  The ovirt-guest-agent contains functionality that is incredibly
>>>> useful within the context of oVirt.  Single Sign-on is very handy but KVM
>>>> users outside the scope of oVirt will not want this extra complexity in
>>>> their agent.  For simplicity they will probably just write something small
>>>> that does what they need (and we have failed to provide a ubiquitous KVM
>>>> agent).
>>>
>>> I totally agree, but that could easily be resolved using the plugin
>>> architecture suggested before.
>>>
>>>>
>>>> 1) Deployment complexity: The more complex the guest agent is, the more
>>>> often it will need to be updated (bug/security fixes, distro compatibility,
>>>> new features).  Rolling out guest agent updates does not scale well in large
>>>> environments (especially when the guest and host administrators are not the
>>>> same person).
>>>
>>> Using plugins, you just deploy the ones you need, keeping the attack surface /
>>> #bugs / need to update lower
>>
>> In order for any KVM guest agent to become ubiquitous, I think the code _must_ live
>> in the qemu repository.  This includes the base infrastructure and a core set of
>> plugins to provide the current set of qemu-ga APIs.  This way, both endpoints
>> (host/guest) can evolve together.  How easy would it be to extract this basic
>> infrastructure from the ovirt-guest-agent?  Is the qemu project opposed to a
>> Python agent?
>
> IMHO Python would be a really bad choice for the agent. An agent wants to be
> maximally portable to any guest OS, regardless of its vintage. The changes
> between each python release, even within the 2.x stream, let alone between
> 2.x and 3.x would cause us endless compatibility problems upon deployment.
> And while python is common on Linux, we don't really want to get into the
> business of installing the python runtime on Windows or other OS, simply to
> run an agent.


And still the ovirt-guest-agent:

- is written in python
- Supports many guest OSs (f15, f16, RHEL6.X RHEL5.X, winXP, W7 (32&64), 
2k3 (32/64) 2k8 (32/64/R2))
- Deployed in binary format on win (py2exe ... no need to install python 
and no compatibility problems)



>
> Regards,
> Daniel

Re: [Qemu-devel] converging around a single guest agent

[Barak Azulay]

On Wednesday 16 November 2011 22:24:51 Adam Litke wrote:
> I have been following this thread pretty closely and the one sentence
> summary of the current argument is: ovirt-guest-agent is already
> featureful and tested, so let's drop qemu-ga and have everyone adopt
> ovirt-guest-agent.  


Not exactly what I meant, but the above is also a factor that needs to be 
taken into account.

to be on the safe side I'll add:

1 - true we want the ovirt-guest-agent to be widly adopted.
2 - we are willing to do major changes in it to fit all (let's discuss it in 
    details)
3 - one can not ignore the:
    * maturity of the 2 components 
    * capabilities
    when considering a convergence into a single agent




> Unfortunately, this track strays completely away from
> the stated goal of convergence.  I have at least two examples of why the
> greater KVM community can never adopt ovirt-guest-agent as-is.  To address
> this, I would like to counter with an example on how qemu-ga can enable
> the deployment of ovirt-guest-agent features and satisfy the needs of the
> whole community at the same time.
> 
> 1) Scope:  The ovirt-guest-agent contains functionality that is incredibly
> useful within the context of oVirt.  Single Sign-on is very handy but KVM
> users outside the scope of oVirt will not want this extra complexity in
> their agent. For simplicity they will probably just write something small
> that does what they need (and we have failed to provide a ubiquitous KVM
> agent).


the ovirt-guest-agent functions well when the SSO if not installed, so no need 
to install it if one does not wish to enjoy it 


> 
> 1) Deployment complexity: The more complex the guest agent is, the more
> often it will need to be updated (bug/security fixes, distro
> compatibility, new features).  Rolling out guest agent updates does not
> scale well in large environments (especially when the guest and host
> administrators are not the same person).


This is what we have been doing for the last few years (with the entire ovirt 
stack). so we are basing our approach on that experiance.
In the session I gave I tried to touch the way we handle deployment of the 
packages (both linux & windows guests), but it was a too large subject to 
contain in that session.

deploying and  upgrading the agent was one of the issues handled.
I can elaborate more on the isse if required. 

I'm not sure that the deployment/upgrade of guest agent should be done through 
the monitor, I think it should be left for a higher management layer. 


> 
> For these reasons (and many others), I support having an agent with very
> basic primitives that can be orchestrated by the host to provide needed
> functionality. This agent would present a low-level, stable, extensible
> API that everyone can use.  Today qemu-ga supports the following verbs:
> sync ping info shutdown file-open file-close file-read file-write
> file-seek file-flush fsfreeze-status fsfreeze-freeze fsfreeze-thaw.  If we
> add a generic execute mechanism, then the agent can provide everything
> needed by oVirt to deploy SSO.


I'm not sure this approach will pass common-criteria review.  


> 
> Let's assume that we have already agreed on some sort of security policy
> for the write-file and exec primitives.  Consensus is possible on this
> issue but I don't want to get bogged down with that here.
> 
> With the above primitives, SSO could be deployed automatically to a guest
> with the following sequence of commands:
> 
> file-open "<exec-dir>/sso-package.bin" "w"
> file-write <fh> <buf>
> file-close <fh>
> file-open "<exec-dir>/sso-package.bin" "x"
> file-exec <fh> <args>
> file-close <fh>
> 
> At this point, the package is installed.  It can contain whatever existing
> logic exists in the ovirt-guest-agent today.  To perform a user login,
> we'll assume that sso-package.bin contains an executable
> 'sso/do-user-sso':
> 
> file-open "<exec-dir>/sso/do-user-sso" "x"
> exec <fh> <args>
> file-close <fh>
> 
> At this point the user would be logged in as before.
> 
> Obviously, this type of approach could be made easier by providing a well
> designed exec API that returns command exit codes and (optionally) command
> output.  We could also formalize the install of additional components into
> some sort of plugin interface.  These are all relatively easy problems to
> solve.
> 
> If we go in this direction, we would have a simple, general-purpose agent
> with low-level primitives that everyone can use.  We would also be able to
> easily extend the agent based on the needs of individual deployments (not
> the least of which is an oVirt environment).  If certain plugins become
> popular enough, they can always be promoted to first-order API calls in
> future versions of the API.
> 
> What are your thoughts on this approach?


When thinking on various guest OSs, I think the approach of a well defined API 
is much more appealing. The reason is that the implementation is contained 
within the specific OS implementation of the guest-agent, and not left to a 
person coding this from the high level management system.
e.g. on the SSO example you gave all the coding of the seaquence of login 
needs to be done on the management system and needs to first check what OS it 
is and only than execute the relevant code  (which is much harder for error 
handling in that situation), while when using a well defined interface all you 
need to do is call the "Login(<args>)" API.


I agree that from development point of view the flexible approach of "I can do 
anything in the guest" is much more appiling, I don't think this is the case 
for enterprise virtualization system that needs to manage thousands of VMs 
with different OS types

Thanks
Barak Azulay

Re: [Qemu-devel] converging around a single guest agent

[Luiz Capitulino]

On Thu, 17 Nov 2011 19:09:10 +0200
Barak Azulay <bazulay@redhat.com> wrote:

> On Wednesday 16 November 2011 22:24:51 Adam Litke wrote:
> > I have been following this thread pretty closely and the one sentence
> > summary of the current argument is: ovirt-guest-agent is already
> > featureful and tested, so let's drop qemu-ga and have everyone adopt
> > ovirt-guest-agent.  
> 
> 
> Not exactly what I meant, but the above is also a factor that needs to be 
> taken into account.

Maybe not, but I share Adam's impression.

> to be on the safe side I'll add:
> 
> 1 - true we want the ovirt-guest-agent to be widly adopted.
> 2 - we are willing to do major changes in it to fit all (let's discuss it in 
>     details)

We should be willing to make major changes in qemu-ga too. Actually, it
seems to me that the best way to handle most of what has been discussed
in this thread is to submit patches to qemu-ga and make it do what you
need it to do.

I don't see problems in having many different guest agents out there, as
long as they serve different purposes. If there's feature overlap, then let's
start adding what's missing to qemu-ga (of course we want to keep it kvm
centric though).

> 3 - one can not ignore the:
>     * maturity of the 2 components 
>     * capabilities

This is subjective, let's talk about concrete things.

>     when considering a convergence into a single agent

I don't think we should be considering choosing one or another agent,
at least not as a first step. That's why people are interpreting you
the wrong way.

IMHO, the first thing to do is to define what qemu's agent should provide,
and then check what's missing in qemu-ga and possibly implement it.

For what's worth, Adam's idea on API and making qemu-ga provide the basic
infrastructure seems quite reasonable to me.

> 
> 
> 
> 
> > Unfortunately, this track strays completely away from
> > the stated goal of convergence.  I have at least two examples of why the
> > greater KVM community can never adopt ovirt-guest-agent as-is.  To address
> > this, I would like to counter with an example on how qemu-ga can enable
> > the deployment of ovirt-guest-agent features and satisfy the needs of the
> > whole community at the same time.
> > 
> > 1) Scope:  The ovirt-guest-agent contains functionality that is incredibly
> > useful within the context of oVirt.  Single Sign-on is very handy but KVM
> > users outside the scope of oVirt will not want this extra complexity in
> > their agent. For simplicity they will probably just write something small
> > that does what they need (and we have failed to provide a ubiquitous KVM
> > agent).
> 
> 
> the ovirt-guest-agent functions well when the SSO if not installed, so no need 
> to install it if one does not wish to enjoy it 
> 
> 
> > 
> > 1) Deployment complexity: The more complex the guest agent is, the more
> > often it will need to be updated (bug/security fixes, distro
> > compatibility, new features).  Rolling out guest agent updates does not
> > scale well in large environments (especially when the guest and host
> > administrators are not the same person).
> 
> 
> This is what we have been doing for the last few years (with the entire ovirt 
> stack). so we are basing our approach on that experiance.
> In the session I gave I tried to touch the way we handle deployment of the 
> packages (both linux & windows guests), but it was a too large subject to 
> contain in that session.
> 
> deploying and  upgrading the agent was one of the issues handled.
> I can elaborate more on the isse if required. 
> 
> I'm not sure that the deployment/upgrade of guest agent should be done through 
> the monitor, I think it should be left for a higher management layer. 
> 
> 
> > 
> > For these reasons (and many others), I support having an agent with very
> > basic primitives that can be orchestrated by the host to provide needed
> > functionality. This agent would present a low-level, stable, extensible
> > API that everyone can use.  Today qemu-ga supports the following verbs:
> > sync ping info shutdown file-open file-close file-read file-write
> > file-seek file-flush fsfreeze-status fsfreeze-freeze fsfreeze-thaw.  If we
> > add a generic execute mechanism, then the agent can provide everything
> > needed by oVirt to deploy SSO.
> 
> 
> I'm not sure this approach will pass common-criteria review.  
> 
> 
> > 
> > Let's assume that we have already agreed on some sort of security policy
> > for the write-file and exec primitives.  Consensus is possible on this
> > issue but I don't want to get bogged down with that here.
> > 
> > With the above primitives, SSO could be deployed automatically to a guest
> > with the following sequence of commands:
> > 
> > file-open "<exec-dir>/sso-package.bin" "w"
> > file-write <fh> <buf>
> > file-close <fh>
> > file-open "<exec-dir>/sso-package.bin" "x"
> > file-exec <fh> <args>
> > file-close <fh>
> > 
> > At this point, the package is installed.  It can contain whatever existing
> > logic exists in the ovirt-guest-agent today.  To perform a user login,
> > we'll assume that sso-package.bin contains an executable
> > 'sso/do-user-sso':
> > 
> > file-open "<exec-dir>/sso/do-user-sso" "x"
> > exec <fh> <args>
> > file-close <fh>
> > 
> > At this point the user would be logged in as before.
> > 
> > Obviously, this type of approach could be made easier by providing a well
> > designed exec API that returns command exit codes and (optionally) command
> > output.  We could also formalize the install of additional components into
> > some sort of plugin interface.  These are all relatively easy problems to
> > solve.
> > 
> > If we go in this direction, we would have a simple, general-purpose agent
> > with low-level primitives that everyone can use.  We would also be able to
> > easily extend the agent based on the needs of individual deployments (not
> > the least of which is an oVirt environment).  If certain plugins become
> > popular enough, they can always be promoted to first-order API calls in
> > future versions of the API.
> > 
> > What are your thoughts on this approach?
> 
> 
> When thinking on various guest OSs, I think the approach of a well defined API 
> is much more appealing. The reason is that the implementation is contained 
> within the specific OS implementation of the guest-agent, and not left to a 
> person coding this from the high level management system.
> e.g. on the SSO example you gave all the coding of the seaquence of login 
> needs to be done on the management system and needs to first check what OS it 
> is and only than execute the relevant code  (which is much harder for error 
> handling in that situation), while when using a well defined interface all you 
> need to do is call the "Login(<args>)" API.
> 
> 
> I agree that from development point of view the flexible approach of "I can do 
> anything in the guest" is much more appiling, I don't think this is the case 
> for enterprise virtualization system that needs to manage thousands of VMs 
> with different OS types
> 
> Thanks
> Barak Azulay
> 
> 
> 
> 
> 
> 
> 

Re: [Qemu-devel] wiki summary

[Michael Roth]

I've tried to summarize the pros/cons, points, and proposals outlined in 
this thread at the following wiki:

http://www.ovirt.org/wiki/Guest_agent_proposals

Please feel free to add/edit as needed. If you don't have an account on 
ovirt.org let me know.

Thanks!

Re: [Qemu-devel] wiki summary

[Barak Azulay]

On Thursday 17 November 2011 02:48:50 Michael Roth wrote:
> I've tried to summarize the pros/cons, points, and proposals outlined in
> this thread at the following wiki:
> 
> http://www.ovirt.org/wiki/Guest_agent_proposals
> 
> Please feel free to add/edit as needed. If you don't have an account on
> ovirt.org let me know.
>

Thanks Michael, it's a good start.


A few questions about the qemu-ga's requirements:

#1
  - same repo ? why is this a requirement ?
  - distributable via ISO  - can you elaborate? 
  - upgradeable via hypervisor push - by the title it sounds like it belongs 
    to deployment, which sounds to me like it belongs to a higher management 
    level

#3 a few questions come up when I read it: 
  - some may consider those primitives as a security breach
  - I understand the motivation of being able to do everything on the guest 
    (exe) but we need to keep in mind it's various guest OSs, and it means 
    that there should be a script for every OS type. to me the option of 
    having a well defined interface is much more appealing  

Thanks
Barak
 
> Thanks!

Re: [Qemu-devel] wiki summary

[Michael Roth]

On 11/17/2011 10:34 AM, Barak Azulay wrote:
> On Thursday 17 November 2011 02:48:50 Michael Roth wrote:
>> I've tried to summarize the pros/cons, points, and proposals outlined in
>> this thread at the following wiki:
>>
>> http://www.ovirt.org/wiki/Guest_agent_proposals
>>
>> Please feel free to add/edit as needed. If you don't have an account on
>> ovirt.org let me know.
>>
>
> Thanks Michael, it's a good start.
>
>
> A few questions about the qemu-ga's requirements:
>
> #1
>    - same repo ? why is this a requirement ?

Or git submodule. Main reasons are that integration with QMP requires 
that qemu be able to generate marshaling code from a guest agent schema 
definition of commands/parameters, and that qemu needs to be able to 
consume guest agent extensions internally. A few examples that came up 
in this thread were opening new virtio-serial channel via agent calls, 
and registering device callbacks/driving state machine changes for guest 
agent events. Since we'd like to pursue a push-deployment model where 
QEMU can deploy a specific, compatible version of the agent to a 
bootstrapped guest (qemu-ga pre-installed via guest distro or ISO 
package), having code changes in-sync with repo would be necessary.

VMware has a similar model for handling guest tools upgrades, where the 
hypervisor pushes upgrades based on host hypervisor level:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008907

The alternative is strict APIs with backward-compatibility with 
down-level agents, which complicates things tremendously on the QEMU 
side, and pretty much everywhere in the stack. Just keeping libvirt in 
sync with QMP has proven difficult and that's just on the host, with a 
common distro and fairly close development communities. Extending this 
kind of synchronization out to multiple guest distros with varying 
levels of guest agents makes this far harder.

>    - distributable via ISO  - can you elaborate?

We'd eventually like to have an analogue to virtualbox/vmware guest 
tools, which ship with the hypervisor and can be deployed in a guest via 
an ISO made available in the guest as a cdrom when push-deployment isn't 
an option (guest doesnt already have some version of an agent with 
upgrade support installed). This is to avoid limiting support to 
specific distros due to lack of available packages in guest repo.

>    - upgradeable via hypervisor push - by the title it sounds like it belongs
>      to deployment, which sounds to me like it belongs to a higher management
>      level

We'd like ability to push to be available all throughout the stack. If 
device X has a callback for event Y, which is only available via version 
Z of the guest agent, we're now reliant on layers far higher up the 
stack to enable low-level functionality that's beneficial at all levels.

>
> #3 a few questions come up when I read it:
>    - some may consider those primitives as a security breach

s/some/virtually everyone/ :) Yes, this is a problem that'll need to be 
addressed. But at the end of the day, QEMU/host *must* be trusted if 
there's so be any pretense of security, since we have access to 
everything at the end of the day. Additionally, VMware has been 
successfully leveraging guest file access, automatic upgrades of guest 
tools, and exec functionality for quite some time now.

That's not to say we don't need to examine the implications closely, but 
there's precedence.

>    - I understand the motivation of being able to do everything on the guest
>      (exe) but we need to keep in mind it's various guest OSs, and it means
>      that there should be a script for every OS type. to me the option of
>      having a well defined interface is much more appealing

Agreed, and we should strive for that. But rarely is an interface 
designed so well that it never needs to change, and however well-defined 
it may be, it will grow with time and that growth entails deploying new 
guest code.

>
> Thanks
> Barak
>
>> Thanks!
>
>

Re: [Qemu-devel] wiki summary

[Barak Azulay]

On Thursday 17 November 2011 21:58:03 Michael Roth wrote:
> On 11/17/2011 10:34 AM, Barak Azulay wrote:
> > On Thursday 17 November 2011 02:48:50 Michael Roth wrote:
> >> I've tried to summarize the pros/cons, points, and proposals outlined in
> >> this thread at the following wiki:
> >> 
> >> http://www.ovirt.org/wiki/Guest_agent_proposals
> >> 
> >> Please feel free to add/edit as needed. If you don't have an account on
> >> ovirt.org let me know.
> > 
> > Thanks Michael, it's a good start.
> > 
> > 
> > A few questions about the qemu-ga's requirements:
> > 
> > #1
> > 
> >    - same repo ? why is this a requirement ?
> 
> Or git submodule. Main reasons are that integration with QMP requires
> that qemu be able to generate marshaling code from a guest agent schema
> definition of commands/parameters, and that qemu needs to be able to
> consume guest agent extensions internally. A few examples that came up
> in this thread were opening new virtio-serial channel via agent calls,
> and registering device callbacks/driving state machine changes for guest
> agent events. Since we'd like to pursue a push-deployment model where
> QEMU can deploy a specific, compatible version of the agent to a
> bootstrapped guest (qemu-ga pre-installed via guest distro or ISO
> package), having code changes in-sync with repo would be necessary.
> 

Does it mean that every time we need to add a new feature to ovirt (which may 
require new API call), we'll have to wait for the appropriate qemu & libvirt 
release?  


> VMware has a similar model for handling guest tools upgrades, where the
> hypervisor pushes upgrades based on host hypervisor level:
> 
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di
> splayKC&externalId=1008907
> 


This is a very good feature (which we have discussed in past many times), but 
I don't think it has something to do with guest-agent being in the same repo 
with qemu.


> The alternative is strict APIs with backward-compatibility with
> down-level agents, which complicates things tremendously on the QEMU
> side, and pretty much everywhere in the stack. Just keeping libvirt in
> sync with QMP has proven difficult and that's just on the host, with a
> common distro and fairly close development communities. Extending this
> kind of synchronization out to multiple guest distros with varying
> levels of guest agents makes this far harder.
> 


This is exactly my concern about having to pass everything through libvirt & 
qemu. 
I'm sure we will not catch all the things we need right from the start, there 
for we'll have to delay features till they are in qemu & libvirt.


> >    - distributable via ISO  - can you elaborate?
> 
> We'd eventually like to have an analogue to virtualbox/vmware guest
> tools, which ship with the hypervisor and can be deployed in a guest via
> an ISO made available in the guest as a cdrom when push-deployment isn't
> an option (guest doesnt already have some version of an agent with
> upgrade support installed). This is to avoid limiting support to
> specific distros due to lack of available packages in guest repo.
> 


Actually we have this solution already active in ovirt for windows guests, for 
linux guests we had assumed that every distro has it's own updates mechanism 
(network dependant), but adding support for various linux distros is very 
easy. I'll be more than happt to elaborate if needed.

Again I don't think it's a requirement from the guest agent (or qemu) but from 
a much higher level management system


> >    - upgradeable via hypervisor push - by the title it sounds like it
> >    belongs
> >    
> >      to deployment, which sounds to me like it belongs to a higher
> >      management level
> 
> We'd like ability to push to be available all throughout the stack. If
> device X has a callback for event Y, which is only available via version
> Z of the guest agent, we're now reliant on layers far higher up the
> stack to enable low-level functionality that's beneficial at all levels.
> 
> > #3 a few questions come up when I read it:
> >    - some may consider those primitives as a security breach
> 
> s/some/virtually everyone/ :) Yes, this is a problem that'll need to be
> addressed. But at the end of the day, QEMU/host *must* be trusted if
> there's so be any pretense of security, since we have access to
> everything at the end of the day. Additionally, VMware has been
> successfully leveraging guest file access, automatic upgrades of guest
> tools, and exec functionality for quite some time now.
> 
> That's not to say we don't need to examine the implications closely, but
> there's precedence.


1 - We have had such functionality in the ovirt-guest-agent and removed it 
becuase of security (BTW it's very easy to add it back)

2 - it's not about trusting qemu, it's about trusting who ever use such an 
API, meaning: that eventually there is a management system with lots of users 
and permissions that allow to use this api, so the exposure is much much 
bigger than just to qemu itself. keep in mind that I qemu only supply the 
APIs, i find it hard to believe that it will acually do some upgrade logic on 
it's own. 

> 
> >    - I understand the motivation of being able to do everything on the
> >    guest
> >    
> >      (exe) but we need to keep in mind it's various guest OSs, and it
> >      means that there should be a script for every OS type. to me the
> >      option of having a well defined interface is much more appealing
> 
> Agreed, and we should strive for that. But rarely is an interface
> designed so well that it never needs to change, and however well-defined
> it may be, it will grow with time and that growth entails deploying new
> guest code.

Hence my concern above, about having to pass every new API through qemu & 
libvirt will slow down features drastically.


> 
> > Thanks
> > Barak
> > 
> >> Thanks!

Re: [Qemu-devel] wiki summary

[Adam Litke]

On Fri, Nov 18, 2011 at 01:25:04PM +0200, Barak Azulay wrote:
> On Thursday 17 November 2011 21:58:03 Michael Roth wrote:
> > On 11/17/2011 10:34 AM, Barak Azulay wrote:
> > > On Thursday 17 November 2011 02:48:50 Michael Roth wrote:
> > >> I've tried to summarize the pros/cons, points, and proposals outlined in
> > >> this thread at the following wiki:
> > >> 
> > >> http://www.ovirt.org/wiki/Guest_agent_proposals
> > >> 
> > >> Please feel free to add/edit as needed. If you don't have an account on
> > >> ovirt.org let me know.
> > > 
> > > Thanks Michael, it's a good start.
> > > 
> > > 
> > > A few questions about the qemu-ga's requirements:
> > > 
> > > #1
> > > 
> > >    - same repo ? why is this a requirement ?
> > 
> > Or git submodule. Main reasons are that integration with QMP requires
> > that qemu be able to generate marshaling code from a guest agent schema
> > definition of commands/parameters, and that qemu needs to be able to
> > consume guest agent extensions internally. A few examples that came up
> > in this thread were opening new virtio-serial channel via agent calls,
> > and registering device callbacks/driving state machine changes for guest
> > agent events. Since we'd like to pursue a push-deployment model where
> > QEMU can deploy a specific, compatible version of the agent to a
> > bootstrapped guest (qemu-ga pre-installed via guest distro or ISO
> > package), having code changes in-sync with repo would be necessary.
> > 
> 
> Does it mean that every time we need to add a new feature to ovirt (which may 
> require new API call), we'll have to wait for the appropriate qemu & libvirt 
> release?  

No, since qemu-ga is built around primitives you will be able to build nearly
anything you want on top of the basic read/write/exec (or plugin) architecture.

> > VMware has a similar model for handling guest tools upgrades, where the
> > hypervisor pushes upgrades based on host hypervisor level:
> > 
> > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di
> > splayKC&externalId=1008907
> > 
> 
> 
> This is a very good feature (which we have discussed in past many times), but 
> I don't think it has something to do with guest-agent being in the same repo 
> with qemu.
> 
> 
> > The alternative is strict APIs with backward-compatibility with
> > down-level agents, which complicates things tremendously on the QEMU
> > side, and pretty much everywhere in the stack. Just keeping libvirt in
> > sync with QMP has proven difficult and that's just on the host, with a
> > common distro and fairly close development communities. Extending this
> > kind of synchronization out to multiple guest distros with varying
> > levels of guest agents makes this far harder.
> > 
> 
> 
> This is exactly my concern about having to pass everything through libvirt & 
> qemu. 
> I'm sure we will not catch all the things we need right from the start, there 
> for we'll have to delay features till they are in qemu & libvirt.

See above.  This underscores the need for an agent that implements a low level
API.

> > >    - distributable via ISO  - can you elaborate?
> > 
> > We'd eventually like to have an analogue to virtualbox/vmware guest
> > tools, which ship with the hypervisor and can be deployed in a guest via
> > an ISO made available in the guest as a cdrom when push-deployment isn't
> > an option (guest doesnt already have some version of an agent with
> > upgrade support installed). This is to avoid limiting support to
> > specific distros due to lack of available packages in guest repo.
> > 
> 
> 
> Actually we have this solution already active in ovirt for windows guests, for 
> linux guests we had assumed that every distro has it's own updates mechanism 
> (network dependant), but adding support for various linux distros is very 
> easy. I'll be more than happt to elaborate if needed.
> 
> Again I don't think it's a requirement from the guest agent (or qemu) but from 
> a much higher level management system

I disagree.  Many people use KVM today outside the realm of a "much higher level
management system".  I run VMs on my laptop and in this environment we still
need a way to deploy guest tools easily.  I would like to use a mechanism that
is the same for all of my guests.  This means using the tried and tested model
employed by other prominent, easy to use hypervisors -- a host-supplied guest
tools ISO.

> > >    - upgradeable via hypervisor push - by the title it sounds like it
> > >    belongs
> > >    
> > >      to deployment, which sounds to me like it belongs to a higher
> > >      management level
> > 
> > We'd like ability to push to be available all throughout the stack. If
> > device X has a callback for event Y, which is only available via version
> > Z of the guest agent, we're now reliant on layers far higher up the
> > stack to enable low-level functionality that's beneficial at all levels.
> > 
> > > #3 a few questions come up when I read it:
> > >    - some may consider those primitives as a security breach
> > 
> > s/some/virtually everyone/ :) Yes, this is a problem that'll need to be
> > addressed. But at the end of the day, QEMU/host *must* be trusted if
> > there's so be any pretense of security, since we have access to
> > everything at the end of the day. Additionally, VMware has been
> > successfully leveraging guest file access, automatic upgrades of guest
> > tools, and exec functionality for quite some time now.
> > 
> > That's not to say we don't need to examine the implications closely, but
> > there's precedence.
> 
> 
> 1 - We have had such functionality in the ovirt-guest-agent and removed it 
> becuase of security (BTW it's very easy to add it back)
> 
> 2 - it's not about trusting qemu, it's about trusting who ever use such an 
> API, meaning: that eventually there is a management system with lots of users 
> and permissions that allow to use this api, so the exposure is much much 
> bigger than just to qemu itself. keep in mind that I qemu only supply the 
> APIs, i find it hard to believe that it will acually do some upgrade logic on 
> it's own. 

The security problems are addressable (via auditing, guest and host side
controls, etc).  And as far as upgrade goes, making the agent a part of qemu
will actually help.  The monitor will have two APIs: one to check if a guest
agent as installed and query capabilities/version (already present), and another
to present a guest-tools ISO to the guest for installation/upgrade.  With these
two host-side APIs in place, it will be possible to provide a trivial
guest-tools-upgrader that could be run when the guest tools iso is updated on
the host.

> 
> > 
> > >    - I understand the motivation of being able to do everything on the
> > >    guest
> > >    
> > >      (exe) but we need to keep in mind it's various guest OSs, and it
> > >      means that there should be a script for every OS type. to me the
> > >      option of having a well defined interface is much more appealing
> > 
> > Agreed, and we should strive for that. But rarely is an interface
> > designed so well that it never needs to change, and however well-defined
> > it may be, it will grow with time and that growth entails deploying new
> > guest code.
> 
> Hence my concern above, about having to pass every new API through qemu & 
> libvirt will slow down features drastically.

I am sure your sentiment is shared by non-oVirt users who would now need to
implement low-level guest agent features in an unrelated software stack.  I
think we need a separation of responsibility.  Low-level general purpose agent
functionality should be built into a hypervisor (qemu) API which should be
consumable by higher level management systems in a natural way.


-- 
Adam Litke <agl@us.ibm.com>
IBM Linux Technology Center

Re: [Qemu-devel] wiki summary

[Michael Roth]

On 11/18/2011 05:25 AM, Barak Azulay wrote:
> On Thursday 17 November 2011 21:58:03 Michael Roth wrote:
>> On 11/17/2011 10:34 AM, Barak Azulay wrote:
>>> On Thursday 17 November 2011 02:48:50 Michael Roth wrote:
>>>> I've tried to summarize the pros/cons, points, and proposals outlined in
>>>> this thread at the following wiki:
>>>>
>>>> http://www.ovirt.org/wiki/Guest_agent_proposals
>>>>
>>>> Please feel free to add/edit as needed. If you don't have an account on
>>>> ovirt.org let me know.
>>>
>>> Thanks Michael, it's a good start.
>>>
>>>
>>> A few questions about the qemu-ga's requirements:
>>>
>>> #1
>>>
>>>     - same repo ? why is this a requirement ?
>>
>> Or git submodule. Main reasons are that integration with QMP requires
>> that qemu be able to generate marshaling code from a guest agent schema
>> definition of commands/parameters, and that qemu needs to be able to
>> consume guest agent extensions internally. A few examples that came up
>> in this thread were opening new virtio-serial channel via agent calls,
>> and registering device callbacks/driving state machine changes for guest
>> agent events. Since we'd like to pursue a push-deployment model where
>> QEMU can deploy a specific, compatible version of the agent to a
>> bootstrapped guest (qemu-ga pre-installed via guest distro or ISO
>> package), having code changes in-sync with repo would be necessary.
>>
>
> Does it mean that every time we need to add a new feature to ovirt (which may
> require new API call), we'll have to wait for the appropriate qemu&  libvirt
> release?

Exactly the opposite if you deploy ovirt functionality using Adam's 
proposal (use qemu-ga to deploy/exec ovirt scripts in guest via ovirt 
management layer, we could potentially provide a higher-level mechanism 
to simplify the process:

for instance:

`guest-script-exec script_name <args> <optional_localpath_to_script>`

for instance, that'll push the latest version of the script to some 
standard location in the guest if it's not present in the guest, or the 
md5sum doesn't match the host version, then exec it. I think, since 
you're already using JSON, we could embed the JSON requests/responses 
via using a special case `guest-script-exec-json` call so the parsing is 
virtually transparent on your end.

libvirt/qemu/qmp would only need to be aware of the primitives, you can 
extend your guest agent functionality simply by updating the scripts 
available to your management tooling on the host.

>
>
>> VMware has a similar model for handling guest tools upgrades, where the
>> hypervisor pushes upgrades based on host hypervisor level:
>>
>> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di
>> splayKC&externalId=1008907
>>
>
>
> This is a very good feature (which we have discussed in past many times), but
> I don't think it has something to do with guest-agent being in the same repo
> with qemu.

To be beneficial from a development/integration perspective, the host 
level would need to be kept in sync with the guest agent level, same 
repo or git submodule is the best way to handle this.

>
>
>> The alternative is strict APIs with backward-compatibility with
>> down-level agents, which complicates things tremendously on the QEMU
>> side, and pretty much everywhere in the stack. Just keeping libvirt in
>> sync with QMP has proven difficult and that's just on the host, with a
>> common distro and fairly close development communities. Extending this
>> kind of synchronization out to multiple guest distros with varying
>> levels of guest agents makes this far harder.
>>
>
>
> This is exactly my concern about having to pass everything through libvirt&
> qemu.
> I'm sure we will not catch all the things we need right from the start, there
> for we'll have to delay features till they are in qemu&  libvirt.

Not with Adam's proposal. It's something we're specifically trying to 
avoid as well and was a core design goal for qemu-ga: make QMP/libvirt 
aware of low-level primitives, let higher level tooling build 
higher-level interfaces/functionality from those. QMP/libvirt do not 
need to be made aware of your changes, though with some work, we could 
potentionally utilize your agent functionality at those levels as well 
(something like the guest-script-exec-json I mentioned above)

>
>
>>>     - distributable via ISO  - can you elaborate?
>>
>> We'd eventually like to have an analogue to virtualbox/vmware guest
>> tools, which ship with the hypervisor and can be deployed in a guest via
>> an ISO made available in the guest as a cdrom when push-deployment isn't
>> an option (guest doesnt already have some version of an agent with
>> upgrade support installed). This is to avoid limiting support to
>> specific distros due to lack of available packages in guest repo.
>>
>
>
> Actually we have this solution already active in ovirt for windows guests, for
> linux guests we had assumed that every distro has it's own updates mechanism
> (network dependant), but adding support for various linux distros is very
> easy. I'll be more than happt to elaborate if needed.
>
> Again I don't think it's a requirement from the guest agent (or qemu) but from
> a much higher level management system

We need to consider low-level requirements: virtio drivers for instance, 
and guest extensions that integrate closely with QEMU itself. QEMU needs 
to be useable in and of itself: relying on high-level management tools 
to package/deploy low-level drivers does nothing for someone who's 
trying to fire up QEMU via command-line and poke at it via QMP.

Ideally we'd have a qemu-guest-tools ISO that a stack can be built on 
from QEMU on up rather than an ovirt-guest-tools ISO that leaves QEMU 
crippled when used in isolation. We've shown how a qemu-guest-tools ISO 
can be used to build arbitrarily complex functionality higher up the 
stack while still servicing low-level, QEMU-internal functionality. 
That's not to say it couldn't be done with ovirt-guest-tools, but to me 
it seems like a much more natural/extensible approach than having QEMU 
internally reliant on something way higher up the stack.

>
>
>>>     - upgradeable via hypervisor push - by the title it sounds like it
>>>     belongs
>>>
>>>       to deployment, which sounds to me like it belongs to a higher
>>>       management level
>>
>> We'd like ability to push to be available all throughout the stack. If
>> device X has a callback for event Y, which is only available via version
>> Z of the guest agent, we're now reliant on layers far higher up the
>> stack to enable low-level functionality that's beneficial at all levels.
>>
>>> #3 a few questions come up when I read it:
>>>     - some may consider those primitives as a security breach
>>
>> s/some/virtually everyone/ :) Yes, this is a problem that'll need to be
>> addressed. But at the end of the day, QEMU/host *must* be trusted if
>> there's so be any pretense of security, since we have access to
>> everything at the end of the day. Additionally, VMware has been
>> successfully leveraging guest file access, automatic upgrades of guest
>> tools, and exec functionality for quite some time now.
>>
>> That's not to say we don't need to examine the implications closely, but
>> there's precedence.
>
>
> 1 - We have had such functionality in the ovirt-guest-agent and removed it
> becuase of security (BTW it's very easy to add it back)
>
> 2 - it's not about trusting qemu, it's about trusting who ever use such an
> API, meaning: that eventually there is a management system with lots of users
> and permissions that allow to use this api, so the exposure is much much
> bigger than just to qemu itself. keep in mind that I qemu only supply the

Agreed. But QMP access in general should be considered root access to a 
guest: we can reboot, poke at registers, memory, etc, so guest-exec 
support is not a particularly special case in that regard. What matters 
is how you expose that functionality higher up the stack. And that's 
what will need to be assessed.

> APIs, i find it hard to believe that it will acually do some upgrade logic on
> it's own.

A particular version of QEMU will know what particular version of the 
guest agent it was coded against (ideally, the version it shipped with). 
The only logic required beyond that it someone typing 
"guest-update-agent" at a QMP console, or perhaps some lower-level image 
authoring tool injecting the code via kickstart/libguestfs/etc.

>
>>
>>>     - I understand the motivation of being able to do everything on the
>>>     guest
>>>
>>>       (exe) but we need to keep in mind it's various guest OSs, and it
>>>       means that there should be a script for every OS type. to me the
>>>       option of having a well defined interface is much more appealing
>>
>> Agreed, and we should strive for that. But rarely is an interface
>> designed so well that it never needs to change, and however well-defined
>> it may be, it will grow with time and that growth entails deploying new
>> guest code.
>
> Hence my concern above, about having to pass every new API through qemu&
> libvirt will slow down features drastically.

We've shared the same concerns from day one: qemu-ga is actually a 
mechanism to avoid this: keep the default agent low-level and simple, 
build APIs on top of it that, above the libvirt/qemu-ga/QMP layers. If 
it's a common, generally-useful interface, pull it into qemu-ga proper, 
and expose it at the QMP layer.

>
>
>>
>>> Thanks
>>> Barak
>>>
>>>> Thanks!
>

Re: [Qemu-devel] wiki summary

[Dor Laor]

On 11/17/2011 09:58 PM, Michael Roth wrote:
> On 11/17/2011 10:34 AM, Barak Azulay wrote:
>> On Thursday 17 November 2011 02:48:50 Michael Roth wrote:
>>> I've tried to summarize the pros/cons, points, and proposals outlined in
>>> this thread at the following wiki:
>>>
>>> http://www.ovirt.org/wiki/Guest_agent_proposals
>>>
>>> Please feel free to add/edit as needed. If you don't have an account on
>>> ovirt.org let me know.
>>>
>>
>> Thanks Michael, it's a good start.
>>
>>
>> A few questions about the qemu-ga's requirements:
>>
>> #1
>>     - same repo ? why is this a requirement ?
>
> Or git submodule. Main reasons are that integration with QMP requires
> that qemu be able to generate marshaling code from a guest agent schema
> definition of commands/parameters, and that qemu needs to be able to
> consume guest agent extensions internally. A few examples that came up
> in this thread were opening new virtio-serial channel via agent calls,
> and registering device callbacks/driving state machine changes for guest
> agent events. Since we'd like to pursue a push-deployment model where
> QEMU can deploy a specific, compatible version of the agent to a
> bootstrapped guest (qemu-ga pre-installed via guest distro or ISO
> package), having code changes in-sync with repo would be necessary.
>
> VMware has a similar model for handling guest tools upgrades, where the
> hypervisor pushes upgrades based on host hypervisor level:
>
> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008907
>
> The alternative is strict APIs with backward-compatibility with
> down-level agents, which complicates things tremendously on the QEMU
> side, and pretty much everywhere in the stack. Just keeping libvirt in
> sync with QMP has proven difficult and that's just on the host, with a
> common distro and fairly close development communities. Extending this
> kind of synchronization out to multiple guest distros with varying
> levels of guest agents makes this far harder.

Using QMP is an advantage, I agree.
However it can be used by another option - move the QMP schema out of 
qemu.git so all projects like libvirt, agents, vdsm, etc will be able to 
consume it directly.

This way, adding a new (agent) command will immediately propagate to all 
of the stack instead of each component to implement it differently 
(while it would still be possible).
That's what libguestfs scheme do today.

In addition, it can answer one of (justified) Barak's concerns that it 
takes too long a time to have all the stack implements commands.
Regardless, we'll want to support kind of path through verbs so we'll be 
able to execute remote WMI or Matahari commands.

>
>>     - distributable via ISO  - can you elaborate?
>
> We'd eventually like to have an analogue to virtualbox/vmware guest

Hmmm, those type-f hypervisors do not have an OS to back them up.
Unlike them, we can easily cover Linux and the ovirt project is 
supported by the major distributions. There is inherited advantage of 
relaying on the distribution for updating the agents, especially when it 
comes to security updates (will iso distribution be part of embargo 
infosec procedure now?). Imagine that bugs/flaws might be in one of your 
libraries.

> tools, which ship with the hypervisor and can be deployed in a guest via
> an ISO made available in the guest as a cdrom when push-deployment isn't
> an option (guest doesnt already have some version of an agent with
> upgrade support installed). This is to avoid limiting support to
> specific distros due to lack of available packages in guest repo.

Having the (mine) above said, the ovirt-agent get pushed today by iso 
for windows, so can we call this issue a draw and remove it out from the 
discussion?

>
>>     - upgradeable via hypervisor push - by the title it sounds like it belongs
>>       to deployment, which sounds to me like it belongs to a higher management
>>       level
>
> We'd like ability to push to be available all throughout the stack. If
> device X has a callback for event Y, which is only available via version
> Z of the guest agent, we're now reliant on layers far higher up the
> stack to enable low-level functionality that's beneficial at all levels.
>
>>
>> #3 a few questions come up when I read it:
>>     - some may consider those primitives as a security breach
>
> s/some/virtually everyone/ :) Yes, this is a problem that'll need to be
> addressed. But at the end of the day, QEMU/host *must* be trusted if
> there's so be any pretense of security, since we have access to
> everything at the end of the day. Additionally, VMware has been
> successfully leveraging guest file access, automatic upgrades of guest
> tools, and exec functionality for quite some time now.
>
> That's not to say we don't need to examine the implications closely, but
> there's precedence.
>
>>     - I understand the motivation of being able to do everything on the guest
>>       (exe) but we need to keep in mind it's various guest OSs, and it means
>>       that there should be a script for every OS type. to me the option of
>>       having a well defined interface is much more appealing
>
> Agreed, and we should strive for that. But rarely is an interface
> designed so well that it never needs to change, and however well-defined
> it may be, it will grow with time and that growth entails deploying new
> guest code.
>
>>
>> Thanks
>> Barak
>>
>>> Thanks!
>>
>>
>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [Qemu-devel] wiki summary

[Richard W.M. Jones]

On Thu, Nov 24, 2011 at 02:40:07PM +0200, Dor Laor wrote:
> Using QMP is an advantage, I agree.
> However it can be used by another option - move the QMP schema out
> of qemu.git so all projects like libvirt, agents, vdsm, etc will be
> able to consume it directly.
> 
> This way, adding a new (agent) command will immediately propagate to
> all of the stack instead of each component to implement it
> differently (while it would still be possible).
> That's what libguestfs scheme do today.

I think Dor CC'd me on this because we use aggressive code generation
in libguestfs to simplify creating new APIs.  For an example see:

http://fedorapeople.org/gitweb?p=rjones/public_git/libguestfs.git;a=commitdiff;h=cbd1c45d95c530c8d94103dcc2c521bf5501ef59

The patch is in three parts:

(1) C code to implement the new API.  Constructing the command line,
    parsing the output.

(2) Metadata in the generator to describe the new API (parameters,
    return, documentation, etc.)

  ==> From this part *everything* is generated <==

      - C header file
      - bindings in 8+ programming languages
      - documentation
      - RPC used over internal virtio-serial connection

(3) A test.

Intelligently generating code like this has been an enormous win.

Here are two slightly more complicated examples demonstrating the same
thing:

http://fedorapeople.org/gitweb?p=rjones/public_git/libguestfs.git;a=commitdiff;h=c4bd6bba8d88ecf1ebf4a9c2c80a407d9971aaf7
http://fedorapeople.org/gitweb?p=rjones/public_git/libguestfs.git;a=commitdiff;h=c11a92751e003b3d4bc3584b598afc9bd9d9e703

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

Re: [Qemu-devel] wiki summary

[Daniel P. Berrange]

On Thu, Nov 24, 2011 at 02:40:07PM +0200, Dor Laor wrote:
> On 11/17/2011 09:58 PM, Michael Roth wrote:
> >On 11/17/2011 10:34 AM, Barak Azulay wrote:
> >>On Thursday 17 November 2011 02:48:50 Michael Roth wrote:
> >>>I've tried to summarize the pros/cons, points, and proposals outlined in
> >>>this thread at the following wiki:
> >>>
> >>>http://www.ovirt.org/wiki/Guest_agent_proposals
> >>>
> >>>Please feel free to add/edit as needed. If you don't have an account on
> >>>ovirt.org let me know.
> >>>
> >>
> >>Thanks Michael, it's a good start.
> >>
> >>
> >>A few questions about the qemu-ga's requirements:
> >>
> >>#1
> >>    - same repo ? why is this a requirement ?
> >
> >Or git submodule. Main reasons are that integration with QMP requires
> >that qemu be able to generate marshaling code from a guest agent schema
> >definition of commands/parameters, and that qemu needs to be able to
> >consume guest agent extensions internally. A few examples that came up
> >in this thread were opening new virtio-serial channel via agent calls,
> >and registering device callbacks/driving state machine changes for guest
> >agent events. Since we'd like to pursue a push-deployment model where
> >QEMU can deploy a specific, compatible version of the agent to a
> >bootstrapped guest (qemu-ga pre-installed via guest distro or ISO
> >package), having code changes in-sync with repo would be necessary.
> >
> >VMware has a similar model for handling guest tools upgrades, where the
> >hypervisor pushes upgrades based on host hypervisor level:
> >
> >http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008907
> >
> >The alternative is strict APIs with backward-compatibility with
> >down-level agents, which complicates things tremendously on the QEMU
> >side, and pretty much everywhere in the stack. Just keeping libvirt in
> >sync with QMP has proven difficult and that's just on the host, with a
> >common distro and fairly close development communities. Extending this
> >kind of synchronization out to multiple guest distros with varying
> >levels of guest agents makes this far harder.
> 
> Using QMP is an advantage, I agree.
> However it can be used by another option - move the QMP schema out
> of qemu.git so all projects like libvirt, agents, vdsm, etc will be
> able to consume it directly.
>
> This way, adding a new (agent) command will immediately propagate to
> all of the stack instead of each component to implement it
> differently (while it would still be possible).
> That's what libguestfs scheme do today.

That kind of idea doesn't really help much in practice, because it is
presuming that the API you want to expose is identical at every level
in the stack. If that were really the case, then you wouldn't really
have different levels in the stack in the first place. An API exposed
at the libvirt level may well map to multiple API calls at the QEMU
level, and and API call at the VDSM level may map to multiple API
calls at the libvirt level, etc.

libguestfs is doing something different here - they have one API and
they are exposed that API, at the same level of granularity in other
languages. That is very different from stacking APIs with different
levels of abstraction. When you're stacking APIs you cannot avoid the
fact that you need to create a design that is suitable for the level
of abstraction you need at each layer.

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

Re: [Qemu-devel] wiki summary

[Dor Laor]

On 11/25/2011 12:07 PM, Daniel P. Berrange wrote:
> On Thu, Nov 24, 2011 at 02:40:07PM +0200, Dor Laor wrote:
>> On 11/17/2011 09:58 PM, Michael Roth wrote:
>>> On 11/17/2011 10:34 AM, Barak Azulay wrote:
>>>> On Thursday 17 November 2011 02:48:50 Michael Roth wrote:
>>>>> I've tried to summarize the pros/cons, points, and proposals outlined in
>>>>> this thread at the following wiki:
>>>>>
>>>>> http://www.ovirt.org/wiki/Guest_agent_proposals
>>>>>
>>>>> Please feel free to add/edit as needed. If you don't have an account on
>>>>> ovirt.org let me know.
>>>>>
>>>>
>>>> Thanks Michael, it's a good start.
>>>>
>>>>
>>>> A few questions about the qemu-ga's requirements:
>>>>
>>>> #1
>>>>     - same repo ? why is this a requirement ?
>>>
>>> Or git submodule. Main reasons are that integration with QMP requires
>>> that qemu be able to generate marshaling code from a guest agent schema
>>> definition of commands/parameters, and that qemu needs to be able to
>>> consume guest agent extensions internally. A few examples that came up
>>> in this thread were opening new virtio-serial channel via agent calls,
>>> and registering device callbacks/driving state machine changes for guest
>>> agent events. Since we'd like to pursue a push-deployment model where
>>> QEMU can deploy a specific, compatible version of the agent to a
>>> bootstrapped guest (qemu-ga pre-installed via guest distro or ISO
>>> package), having code changes in-sync with repo would be necessary.
>>>
>>> VMware has a similar model for handling guest tools upgrades, where the
>>> hypervisor pushes upgrades based on host hypervisor level:
>>>
>>> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008907
>>>
>>> The alternative is strict APIs with backward-compatibility with
>>> down-level agents, which complicates things tremendously on the QEMU
>>> side, and pretty much everywhere in the stack. Just keeping libvirt in
>>> sync with QMP has proven difficult and that's just on the host, with a
>>> common distro and fairly close development communities. Extending this
>>> kind of synchronization out to multiple guest distros with varying
>>> levels of guest agents makes this far harder.
>>
>> Using QMP is an advantage, I agree.
>> However it can be used by another option - move the QMP schema out
>> of qemu.git so all projects like libvirt, agents, vdsm, etc will be
>> able to consume it directly.
>>
>> This way, adding a new (agent) command will immediately propagate to
>> all of the stack instead of each component to implement it
>> differently (while it would still be possible).
>> That's what libguestfs scheme do today.
>
> That kind of idea doesn't really help much in practice, because it is
> presuming that the API you want to expose is identical at every level
> in the stack. If that were really the case, then you wouldn't really
> have different levels in the stack in the first place. An API exposed
> at the libvirt level may well map to multiple API calls at the QEMU
> level, and and API call at the VDSM level may map to multiple API
> calls at the libvirt level, etc.
>
> libguestfs is doing something different here - they have one API and
> they are exposed that API, at the same level of granularity in other
> languages. That is very different from stacking APIs with different
> levels of abstraction. When you're stacking APIs you cannot avoid the
> fact that you need to create a design that is suitable for the level
> of abstraction you need at each layer.

You're right, but Barak's concern was that each new command will now 
need to be represented differently by each API in the stack. That's 
cause a significant slow down of the development cycle.

While we should keep have a rich and different API in the various layers 
(agent, qmp, libvirt, vdsm,..), we can use a QMP pass through mode for 
others. Some times this is tricky, and one command generated by layer x 
might contradict another created by layer y. In the agent case, it can 
utilized in most cases since most commands are read-only.

QMP/qAPI is a stable api and all layers in the stack can relay on it. 
Libvirt passes it through as well as you know :)

Again, some commands like fs-freeze shouldn't be pass through-ed but 
plenty of others like mem info, fs content, app list, etc can be used.

>
> Regards,
> Daniel