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
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
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
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:
On Windows it is compiled to an executable, so no separate python stack needed
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?
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:
On Windows it is compiled to an executable, so no separate python stack needed
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:
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:
On Windows it is compiled to an executable, so no separate python
stack needed
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:
As the ovirt-guest-agent the above package uses also pywin32.
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
----- 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
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
----- 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:
- 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:
- All of these are client <-> guest communication, rather then the
host <-> guest communication which the other agents seem to focus on.
- 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
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:
- 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:
- All of these are client<-> guest communication, rather then the
host<-> guest communication which the other agents seem to focus on.
- 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
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:
- 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:
- All of these are client<-> guest communication, rather then the
host<-> guest communication which the other agents seem to focus on.
- 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
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:
- Paravirtual mouse (needed to get mouse coordinates right with multi monitor setups)
- Send client monitor configuration, so that the guest os can adjust its resolution (and number and place of monitors) to match the client
- 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).
- 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:
- All of these are client <-> guest communication, rather then the host <-> guest communication
which the other agents seem to focus on.
- Getting copy paste right requires a system level guest agent process as well as a per user
session agent process.
Regards,
Hans
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:
- Paravirtual mouse (needed to get mouse coordinates right with multi monitor setups)
- Send client monitor configuration, so that the guest os can adjust its resolution (and number and place of monitors) to match the client
- 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).
- 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:
- 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:
- All of these are client<-> guest communication, rather then the host<-> guest communication
which the other agents seem to focus on.
- Getting copy paste right requires a system level guest agent process as well as a per user
session agent process.
Regards,
Hans
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:
- 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.
- 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
- 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).
- 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:
- 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:
- All of these are client<-> guest communication, rather then the host<-> guest communication
which the other agents seem to focus on.
- Getting copy paste right requires a system level guest agent process as well as a per user
session agent process.
Regards,
Hans
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:
- 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
- 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
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:
- 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
- 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
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
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
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
----- 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
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
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?
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
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
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
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
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
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
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
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
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 Azulaybazulay@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
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 Azulaybazulay@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:
- 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
- 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
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 Azulaybazulay@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:
- 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
- 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
On 11/16/2011 11:53 AM, Barak Azulay wrote:
On Wednesday 16 November 2011 17:28:16 Michael Roth wrote:
- 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
----- Original Message -----
On 11/16/2011 11:53 AM, Barak Azulay wrote:
On Wednesday 16 November 2011 17:28:16 Michael Roth wrote:
- 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
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:
- 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
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
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?
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.
- 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).
- 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.
----- 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.
- 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.
- 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
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.
- 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.
- 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 Litkeagl@us.ibm.com IBM Linux Technology Center
Arch mailing list Arch@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
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.
- 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.
- 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
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.
- 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.
- 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
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.
- 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.
- 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 ___
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.
- 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.
- 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
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.
- 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
- 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
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.
- 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
- 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
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!
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!
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...
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!
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... 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!
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... 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.
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... 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!
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...
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
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=commitdi...
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=commitdi... http://fedorapeople.org/gitweb?p=rjones/public_git/libguestfs.git;a=commitdi...
Rich.
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...
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
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...
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
vdsm-devel@lists.fedorahosted.org