Re: [Qemu-devel] converging around a single guest agent
On 11/17/2011 06:14 PM, Daniel P. Berrange wrote: > On Thu, Nov 17, 2011 at 09:58:33AM -0600, Adam Litke wrote: >> On Thu, Nov 17, 2011 at 03:46:37AM -0500, Ayal Baron wrote: >>> >>> >>> - Original Message - I have been following this thread pretty closely and the one sentence summary of the current argument is: ovirt-guest-agent is already featureful and tested, so let's drop qemu-ga and have everyone adopt ovirt-guest-agent. >>> >>> What we're suggesting is let's drop *one* of the two agents (obviously it >>> would be easier for us to drop qemu-ga, but we'd rather reach consensus and >>> unite behind one agent regardless of which agent it is). >>> Unfortunately, this track strays completely away from the stated goal of convergence. I have at least two examples of why the greater KVM community can never adopt ovirt-guest-agent as-is. To address this, I would like to counter with an example on how qemu-ga can enable the deployment of ovirt-guest-agent features and satisfy the needs of the whole community at the same time. 1) Scope: The ovirt-guest-agent contains functionality that is incredibly useful within the context of oVirt. Single Sign-on is very handy but KVM users outside the scope of oVirt will not want this extra complexity in their agent. For simplicity they will probably just write something small that does what they need (and we have failed to provide a ubiquitous KVM agent). >>> >>> I totally agree, but that could easily be resolved using the plugin >>> architecture suggested before. >>> 1) Deployment complexity: The more complex the guest agent is, the more often it will need to be updated (bug/security fixes, distro compatibility, new features). Rolling out guest agent updates does not scale well in large environments (especially when the guest and host administrators are not the same person). >>> >>> Using plugins, you just deploy the ones you need, keeping the attack >>> surface / >>> #bugs / need to update lower >> >> In order for any KVM guest agent to become ubiquitous, I think the code >> _must_ live >> in the qemu repository. This includes the base infrastructure and a core >> set of >> plugins to provide the current set of qemu-ga APIs. This way, both endpoints >> (host/guest) can evolve together. How easy would it be to extract this basic >> infrastructure from the ovirt-guest-agent? Is the qemu project opposed to a >> Python agent? > > IMHO Python would be a really bad choice for the agent. An agent wants to be > maximally portable to any guest OS, regardless of its vintage. The changes > between each python release, even within the 2.x stream, let alone between > 2.x and 3.x would cause us endless compatibility problems upon deployment. > And while python is common on Linux, we don't really want to get into the > business of installing the python runtime on Windows or other OS, simply to > run an agent. And still the ovirt-guest-agent: - is written in python - Supports many guest OSs (f15, f16, RHEL6.X RHEL5.X, winXP, W7 (32&64), 2k3 (32/64) 2k8 (32/64/R2)) - Deployed in binary format on win (py2exe ... no need to install python and no compatibility problems) > > Regards, > Daniel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
>>> 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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On Thu, Nov 17, 2011 at 11:14 AM, Daniel P. Berrange wrote: > On Thu, Nov 17, 2011 at 09:58:33AM -0600, Adam Litke wrote: >> On Thu, Nov 17, 2011 at 03:46:37AM -0500, Ayal Baron wrote: >> > >> > >> > - Original Message - >> > > I have been following this thread pretty closely and the one sentence >> > > summary of the current argument is: ovirt-guest-agent is already >> > > featureful >> > > and tested, so let's drop qemu-ga and have everyone adopt >> > > ovirt-guest-agent. >> > >> > What we're suggesting is let's drop *one* of the two agents (obviously it >> > would be easier for us to drop qemu-ga, but we'd rather reach consensus and >> > unite behind one agent regardless of which agent it is). >> > >> > > Unfortunately, this track strays completely away from the stated goal of >> > > convergence. I have at least two examples of why the greater KVM >> > > community >> > > can never adopt ovirt-guest-agent as-is. To address this, I would like >> > > to >> > > counter with an example on how qemu-ga can enable the deployment of >> > > ovirt-guest-agent features and satisfy the needs of the whole community >> > > at >> > > the same time. >> > > >> > > 1) Scope: The ovirt-guest-agent contains functionality that is >> > > incredibly >> > > useful within the context of oVirt. Single Sign-on is very handy but KVM >> > > users outside the scope of oVirt will not want this extra complexity in >> > > their agent. For simplicity they will probably just write something >> > > small >> > > that does what they need (and we have failed to provide a ubiquitous KVM >> > > agent). >> > >> > I totally agree, but that could easily be resolved using the plugin >> > architecture suggested before. >> > >> > > >> > > 1) Deployment complexity: The more complex the guest agent is, the more >> > > often it will need to be updated (bug/security fixes, distro >> > > compatibility, >> > > new features). Rolling out guest agent updates does not scale well in >> > > large >> > > environments (especially when the guest and host administrators are not >> > > the >> > > same person). >> > >> > Using plugins, you just deploy the ones you need, keeping the attack >> > surface / >> > #bugs / need to update lower >> >> In order for any KVM guest agent to become ubiquitous, I think the code >> _must_ live >> in the qemu repository. This includes the base infrastructure and a core >> set of >> plugins to provide the current set of qemu-ga APIs. This way, both endpoints >> (host/guest) can evolve together. How easy would it be to extract this basic >> infrastructure from the ovirt-guest-agent? Is the qemu project opposed to a >> Python agent? > > IMHO Python would be a really bad choice for the agent. An agent wants to be > maximally portable to any guest OS, regardless of its vintage. The changes > between each python release, even within the 2.x stream, let alone between > 2.x and 3.x would cause us endless compatibility problems upon deployment. > And while python is common on Linux, we don't really want to get into the > business of installing the python runtime on Windows or other OS, simply to > run an agent. > > 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 ___ ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On Thu, 17 Nov 2011 19:09:10 +0200 Barak Azulay wrote: > On Wednesday 16 November 2011 22:24:51 Adam Litke wrote: > > I have been following this thread pretty closely and the one sentence > > summary of the current argument is: ovirt-guest-agent is already > > featureful and tested, so let's drop qemu-ga and have everyone adopt > > ovirt-guest-agent. > > > Not exactly what I meant, but the above is also a factor that needs to be > taken into account. Maybe not, but I share Adam's impression. > to be on the safe side I'll add: > > 1 - true we want the ovirt-guest-agent to be widly adopted. > 2 - we are willing to do major changes in it to fit all (let's discuss it in > details) We should be willing to make major changes in qemu-ga too. Actually, it seems to me that the best way to handle most of what has been discussed in this thread is to submit patches to qemu-ga and make it do what you need it to do. I don't see problems in having many different guest agents out there, as long as they serve different purposes. If there's feature overlap, then let's start adding what's missing to qemu-ga (of course we want to keep it kvm centric though). > 3 - one can not ignore the: > * maturity of the 2 components > * capabilities This is subjective, let's talk about concrete things. > when considering a convergence into a single agent I don't think we should be considering choosing one or another agent, at least not as a first step. That's why people are interpreting you the wrong way. IMHO, the first thing to do is to define what qemu's agent should provide, and then check what's missing in qemu-ga and possibly implement it. For what's worth, Adam's idea on API and making qemu-ga provide the basic infrastructure seems quite reasonable to me. > > > > > > Unfortunately, this track strays completely away from > > the stated goal of convergence. I have at least two examples of why the > > greater KVM community can never adopt ovirt-guest-agent as-is. To address > > this, I would like to counter with an example on how qemu-ga can enable > > the deployment of ovirt-guest-agent features and satisfy the needs of the > > whole community at the same time. > > > > 1) Scope: The ovirt-guest-agent contains functionality that is incredibly > > useful within the context of oVirt. Single Sign-on is very handy but KVM > > users outside the scope of oVirt will not want this extra complexity in > > their agent. For simplicity they will probably just write something small > > that does what they need (and we have failed to provide a ubiquitous KVM > > agent). > > > the ovirt-guest-agent functions well when the SSO if not installed, so no > need > to install it if one does not wish to enjoy it > > > > > > 1) Deployment complexity: The more complex the guest agent is, the more > > often it will need to be updated (bug/security fixes, distro > > compatibility, new features). Rolling out guest agent updates does not > > scale well in large environments (especially when the guest and host > > administrators are not the same person). > > > This is what we have been doing for the last few years (with the entire ovirt > stack). so we are basing our approach on that experiance. > In the session I gave I tried to touch the way we handle deployment of the > packages (both linux & windows guests), but it was a too large subject to > contain in that session. > > deploying and upgrading the agent was one of the issues handled. > I can elaborate more on the isse if required. > > I'm not sure that the deployment/upgrade of guest agent should be done > through > the monitor, I think it should be left for a higher management layer. > > > > > > For these reasons (and many others), I support having an agent with very > > basic primitives that can be orchestrated by the host to provide needed > > functionality. This agent would present a low-level, stable, extensible > > API that everyone can use. Today qemu-ga supports the following verbs: > > sync ping info shutdown file-open file-close file-read file-write > > file-seek file-flush fsfreeze-status fsfreeze-freeze fsfreeze-thaw. If we > > add a generic execute mechanism, then the agent can provide everything > > needed by oVirt to deploy SSO. > > > I'm not sure this approach will pass common-criteria review. > > > > > > Let's assume that we have already agreed on some sort of security policy > > for the write-file and exec primitives. Consensus is possible on this > > issue but I don't want to get bogged down with that here. > > > > With the above primitives, SSO could be deployed automatically to a guest > > with the following sequence of commands: > > > > file-open "/sso-package.bin" "w" > > file-write > > file-close > > file-open "/sso-package.bin" "x" > > file-exec > > file-close > > > > At this point, the package is installed. It can contain whatever existing > > logic exists in the ovirt-guest-agent today. To pe
Re: [Qemu-devel] converging around a single guest agent
On Wednesday 16 November 2011 22:24:51 Adam Litke wrote: > I have been following this thread pretty closely and the one sentence > summary of the current argument is: ovirt-guest-agent is already > featureful and tested, so let's drop qemu-ga and have everyone adopt > ovirt-guest-agent. Not exactly what I meant, but the above is also a factor that needs to be taken into account. to be on the safe side I'll add: 1 - true we want the ovirt-guest-agent to be widly adopted. 2 - we are willing to do major changes in it to fit all (let's discuss it in details) 3 - one can not ignore the: * maturity of the 2 components * capabilities when considering a convergence into a single agent > Unfortunately, this track strays completely away from > the stated goal of convergence. I have at least two examples of why the > greater KVM community can never adopt ovirt-guest-agent as-is. To address > this, I would like to counter with an example on how qemu-ga can enable > the deployment of ovirt-guest-agent features and satisfy the needs of the > whole community at the same time. > > 1) Scope: The ovirt-guest-agent contains functionality that is incredibly > useful within the context of oVirt. Single Sign-on is very handy but KVM > users outside the scope of oVirt will not want this extra complexity in > their agent. For simplicity they will probably just write something small > that does what they need (and we have failed to provide a ubiquitous KVM > agent). the ovirt-guest-agent functions well when the SSO if not installed, so no need to install it if one does not wish to enjoy it > > 1) Deployment complexity: The more complex the guest agent is, the more > often it will need to be updated (bug/security fixes, distro > compatibility, new features). Rolling out guest agent updates does not > scale well in large environments (especially when the guest and host > administrators are not the same person). This is what we have been doing for the last few years (with the entire ovirt stack). so we are basing our approach on that experiance. In the session I gave I tried to touch the way we handle deployment of the packages (both linux & windows guests), but it was a too large subject to contain in that session. deploying and upgrading the agent was one of the issues handled. I can elaborate more on the isse if required. I'm not sure that the deployment/upgrade of guest agent should be done through the monitor, I think it should be left for a higher management layer. > > For these reasons (and many others), I support having an agent with very > basic primitives that can be orchestrated by the host to provide needed > functionality. This agent would present a low-level, stable, extensible > API that everyone can use. Today qemu-ga supports the following verbs: > sync ping info shutdown file-open file-close file-read file-write > file-seek file-flush fsfreeze-status fsfreeze-freeze fsfreeze-thaw. If we > add a generic execute mechanism, then the agent can provide everything > needed by oVirt to deploy SSO. I'm not sure this approach will pass common-criteria review. > > Let's assume that we have already agreed on some sort of security policy > for the write-file and exec primitives. Consensus is possible on this > issue but I don't want to get bogged down with that here. > > With the above primitives, SSO could be deployed automatically to a guest > with the following sequence of commands: > > file-open "/sso-package.bin" "w" > file-write > file-close > file-open "/sso-package.bin" "x" > file-exec > file-close > > 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 "/sso/do-user-sso" "x" > exec > file-close > > 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
Re: [Qemu-devel] converging around a single guest agent
On Thu, Nov 17, 2011 at 09:58:33AM -0600, Adam Litke wrote: > On Thu, Nov 17, 2011 at 03:46:37AM -0500, Ayal Baron wrote: > > > > > > - Original Message - > > > I have been following this thread pretty closely and the one sentence > > > summary of the current argument is: ovirt-guest-agent is already > > > featureful > > > and tested, so let's drop qemu-ga and have everyone adopt > > > ovirt-guest-agent. > > > > What we're suggesting is let's drop *one* of the two agents (obviously it > > would be easier for us to drop qemu-ga, but we'd rather reach consensus and > > unite behind one agent regardless of which agent it is). > > > > > Unfortunately, this track strays completely away from the stated goal of > > > convergence. I have at least two examples of why the greater KVM > > > community > > > can never adopt ovirt-guest-agent as-is. To address this, I would like > > > to > > > counter with an example on how qemu-ga can enable the deployment of > > > ovirt-guest-agent features and satisfy the needs of the whole community > > > at > > > the same time. > > > > > > 1) Scope: The ovirt-guest-agent contains functionality that is incredibly > > > useful within the context of oVirt. Single Sign-on is very handy but KVM > > > users outside the scope of oVirt will not want this extra complexity in > > > their agent. For simplicity they will probably just write something small > > > that does what they need (and we have failed to provide a ubiquitous KVM > > > agent). > > > > I totally agree, but that could easily be resolved using the plugin > > architecture suggested before. > > > > > > > > 1) Deployment complexity: The more complex the guest agent is, the more > > > often it will need to be updated (bug/security fixes, distro > > > compatibility, > > > new features). Rolling out guest agent updates does not scale well in > > > large > > > environments (especially when the guest and host administrators are not > > > the > > > same person). > > > > Using plugins, you just deploy the ones you need, keeping the attack > > surface / > > #bugs / need to update lower > > In order for any KVM guest agent to become ubiquitous, I think the code > _must_ live > in the qemu repository. This includes the base infrastructure and a core set > of > plugins to provide the current set of qemu-ga APIs. This way, both endpoints > (host/guest) can evolve together. How easy would it be to extract this basic > infrastructure from the ovirt-guest-agent? Is the qemu project opposed to a > Python agent? IMHO Python would be a really bad choice for the agent. An agent wants to be maximally portable to any guest OS, regardless of its vintage. The changes between each python release, even within the 2.x stream, let alone between 2.x and 3.x would cause us endless compatibility problems upon deployment. And while python is common on Linux, we don't really want to get into the business of installing the python runtime on Windows or other OS, simply to run an agent. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: converging around a single guest agent
On Thu, Nov 17, 2011 at 03:46:37AM -0500, Ayal Baron wrote: > > > - Original Message - > > I have been following this thread pretty closely and the one sentence > > summary of the current argument is: ovirt-guest-agent is already featureful > > and tested, so let's drop qemu-ga and have everyone adopt ovirt-guest-agent. > > What we're suggesting is let's drop *one* of the two agents (obviously it > would be easier for us to drop qemu-ga, but we'd rather reach consensus and > unite behind one agent regardless of which agent it is). > > > Unfortunately, this track strays completely away from the stated goal of > > convergence. I have at least two examples of why the greater KVM community > > can never adopt ovirt-guest-agent as-is. To address this, I would like to > > counter with an example on how qemu-ga can enable the deployment of > > ovirt-guest-agent features and satisfy the needs of the whole community at > > the same time. > > > > 1) Scope: The ovirt-guest-agent contains functionality that is incredibly > > useful within the context of oVirt. Single Sign-on is very handy but KVM > > users outside the scope of oVirt will not want this extra complexity in > > their agent. For simplicity they will probably just write something small > > that does what they need (and we have failed to provide a ubiquitous KVM > > agent). > > I totally agree, but that could easily be resolved using the plugin > architecture suggested before. > > > > > 1) Deployment complexity: The more complex the guest agent is, the more > > often it will need to be updated (bug/security fixes, distro compatibility, > > new features). Rolling out guest agent updates does not scale well in large > > environments (especially when the guest and host administrators are not the > > same person). > > Using plugins, you just deploy the ones you need, keeping the attack surface / > #bugs / need to update lower In order for any KVM guest agent to become ubiquitous, I think the code _must_ live in the qemu repository. This includes the base infrastructure and a core set of plugins to provide the current set of qemu-ga APIs. This way, both endpoints (host/guest) can evolve together. How easy would it be to extract this basic infrastructure from the ovirt-guest-agent? Is the qemu project opposed to a Python agent? > > For these reasons (and many others), I support having an agent with very > > basic primitives that can be orchestrated by the host to provide needed > > functionality. This agent would present a low-level, stable, extensible API > > that everyone can use. Today qemu-ga supports the following verbs: sync > > ping info shutdown file-open file-close file-read file-write file-seek > > file-flush fsfreeze-status fsfreeze-freeze fsfreeze-thaw. If we add a > > generic execute mechanism, then the agent can provide everything needed by > > oVirt to deploy SSO. > > > > Let's assume that we have already agreed on some sort of security policy for > > the write-file and exec primitives. Consensus is possible on this issue but > > I don't want to get bogged down with that here. > > > > With the above primitives, SSO could be deployed automatically to a guest > > with the following sequence of commands: > > > > file-open "/sso-package.bin" "w" file-write file-close > > file-open "/sso-package.bin" "x" file-exec > > file-close > > 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 "/s
Re: [Qemu-devel] converging around a single guest agent
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: > >>> > >> > >> > >> > 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) > >>> > >> > >> > >> > >>If we're gathering requirements and trying to come up with one agent > >>to rule them all, don't forget > > > >I don't think we're trying to come up with one agent to rule them all, just > >avoid duplication of efforts if most of what the 2 agents are doing overlaps. > >I think we can safely say that seeing as oVirt is KVM centric, > >ovirt-guest-agent wants to leverage qemu/kvm to the fullest which aligns > >with what qemu-guest-agent is doing. > >However, ovirt-guest-agent is required to do a lot more, so we need to see > >if and how we resolve this. > > > >>about VDI and the Spice agent. Currently the spice agent handles the > >>following: > >> > >>1) Paravirtual mouse (needed to get mouse coordinates right with > >>multi monitor setups) > >>2) Send client monitor configuration, so that the guest os can adjust > >>its resolution > >> (and number and place of monitors) to match the client > >>3) Copy and paste in a platform neutral manner, if anyone wishes to > >>add this to another agent > >> please, please contact us (me) first. This is easy to get wrong > >> (we went through 2 revisions > >> of the protocol for this). > >>4) Allow the client to request the guest to tone down the bling (for > >>low spec clients) > >> > >>Notes: > >>1) All of these are client<-> guest communication, rather then the > >>host<-> guest communication > >>which the other agents seem to focus on. > >> > >>2) Getting copy paste right requires a system level guest agent > >>process as well as a per user > >>session agent process. > > > >Neither qemu-guest-agent nor ovirt-guest-agent is aligned with doing any of > >the above, so I'm not sure there is any justification in uniting the spice > >agent with the rest. > > > > copy/paste was actually one of the initial use cases motivating > qemu-ga; it's just that the requirements (system+user-level agents) > were so different from the more pressing use cases of things like > reliable shutdown/reboot that it's been put off for now. At some > point we had a basic plan on how to approach it, but that needs to > be re-assessed. > I think for large opaque copies in/out to the guest, like image copy paste, or guest<->guest copy paste (word OLE) it would be nice to implemant a side channel scheme: message to allocate a channel message to deallocate a channel and signal successfull completion or error the channel is just another virtio-serial that is used for this communication only The benefits would be: no need to slow down other operations no base64 conversion (both sides) This of course means that this data is not being parsed by qemu, so it can't benefit from any whitelisting / schema description. That's why it should only be used for data that is undescribable - like the aformentioned image/guest copy case (for instance for text copy it makes possibly less sense - although again that's completely unstructured text, so perhaps it makes sense as well). > >> > >>Regards, > >> > >>Hans > >> > > > > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On 11/17/2011 02:46 AM, Ayal Baron wrote: > > > - Original Message - >> I have been following this thread pretty closely and the one sentence >> summary of >> the current argument is: ovirt-guest-agent is already featureful and >> tested, so >> let's drop qemu-ga and have everyone adopt ovirt-guest-agent. > > What we're suggesting is let's drop *one* of the two agents (obviously it > would be easier for us to drop qemu-ga, but we'd rather reach consensus and > unite behind one agent regardless of which agent it is). > >> Unfortunately, >> this track strays completely away from the stated goal of >> convergence. I have >> at least two examples of why the greater KVM community can never >> adopt >> ovirt-guest-agent as-is. To address this, I would like to counter >> with an >> example on how qemu-ga can enable the deployment of ovirt-guest-agent >> features >> and satisfy the needs of the whole community at the same time. >> >> 1) Scope: The ovirt-guest-agent contains functionality that is >> incredibly >> useful within the context of oVirt. Single Sign-on is very handy but >> KVM users >> outside the scope of oVirt will not want this extra complexity in >> their agent. >> For simplicity they will probably just write something small that >> does what they >> need (and we have failed to provide a ubiquitous KVM agent). > > I totally agree, but that could easily be resolved using the plugin > architecture suggested before. > >> >> 1) Deployment complexity: The more complex the guest agent is, the >> more often it >> will need to be updated (bug/security fixes, distro compatibility, >> new >> features). Rolling out guest agent updates does not scale well in >> large >> environments (especially when the guest and host administrators are >> not the same >> person). > > Using plugins, you just deploy the ones you need, keeping the attack surface > / #bugs / need to update lower But you still need to deploy those plugins somehow, so the logistics of distributing this code to multiple types/levels of guests remains, and plugins are insufficient to handle security fixes in the core code (however small that attack surface may be). Eventually you'll need a newer version of the guest agent installed. qemu-ga could be the vehicle for delivering those ovirt plugins/updates, and qemu-ga can upgrade itself to handle it's own security fixes/updates. With this model you can keep your agent functionality closely tied to the high-level management infrastructure, take liberties in what features/changes you need to add/make, and push-deploy those changes through qemu-ga. Low-level primitives to build high-level interfaces higher up the stack has always been a primary design goal so this all fits together fairly well from a QEMU perspective. The extra orchestration required is worth it, IMO, as the alternative is limiting customers to a particular distro, installing a similar backend, or shooting out emails to everyone asking them to update their guest agent so you can leverage feature X. > >> >> For these reasons (and many others), I support having an agent with >> very basic >> primitives that can be orchestrated by the host to provide needed >> functionality. >> This agent would present a low-level, stable, extensible API that >> everyone can >> use. Today qemu-ga supports the following verbs: sync ping info >> shutdown >> file-open file-close file-read file-write file-seek file-flush >> fsfreeze-status >> fsfreeze-freeze fsfreeze-thaw. If we add a generic execute >> mechanism, then the >> agent can provide everything needed by oVirt to deploy SSO. >> >> Let's assume that we have already agreed on some sort of security >> policy for the >> write-file and exec primitives. Consensus is possible on this issue >> but I >> don't want to get bogged down with that here. >> >> With the above primitives, SSO could be deployed automatically to a >> guest with >> the following sequence of commands: >> >> file-open "/sso-package.bin" "w" >> file-write >> file-close >> file-open "/sso-package.bin" "x" >> file-exec >> file-close > > 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 inte
Re: [Qemu-devel] converging around a single guest agent
On 11/17/2011 02:59 AM, Ayal Baron wrote: > > > - Original Message - >> On 11/16/2011 11:53 AM, Barak Azulay wrote: >>> On Wednesday 16 November 2011 17:28:16 Michael Roth wrote: 2) You'd also need a schema, similar to qemu.git/qapi-schema-guest.json, to describe the calls you're proxying. The existing infrastructure in QEMU will handle all the work of marshalling/unmarshalling responses back to the QMP client on the host-side. It's a bit of extra work, but the benefit is unifying the qemu/guest-level management interface into a single place that's easy for QMP/libvirt to consume. >>> >>> The issue is not whether it's possible or not or the amount of >>> efforts need to >>> be done for that to happen, either for qemu-ga or ovirt-guest-agent >>> this work >>> needs to be done. >>> >>> the question is whether all comminication should go through the >>> monitor (hence >>> double proxy) or ... only a subset of the commands that are closly >>> related to >>> hypervisor functionality and separate it from general >>> management-system >>> related actions (e.g. ovirt or any other management system that >>> wants to >>> communicate to the guest). >> >> Yes, all guest interaction should be funnelled through QEMU. QEMU >> has one job >> in life--to expose an interface to guests and turn it into something >> more useful >> to the host. QEMU expose an emulated AHCI controller and turns that >> into VFS >> operations. >> >> Likewise, QEMU should expose a paravirtual "agent" device to a guest, >> and then >> turn that into higher level management interfaces. > > Exposing higher level management interfaces means that qemu would have to do > policy. No, the way we plan on doing this is having a guest agent schema (qapi-schema-guest.json) that we can use to (1) white list valid operations and (2) decode and re-encode operations. (1) let's us validate that guest state isn't escaping which keeps migration safe (2) let's us scrub any potentially malicious input from the guest before we hand it off to the management tool. Otherwise, we don't get in the middle and don't really care what the verbs are. >> >> QEMU's job is to sanitize information from the guest and try to turn >> that into >> something that is safer for the broader world to consume. QEMU also >> deals with >> isolating state in order to support things like live migration. This > > So are you suggesting that when a user reads a file you would automatically > encode the contents? I'm not sure I understand what you're suggesting. Here's another way to think of this. In a typical enterprise environment, you would secure your network infrastructure using isolated zones. You may have a red zone (guest networking), a yellow zone (management network), and a green zone (broader intranet). The zones are physically separate with very few things that exist on two zones. You pay special attention to anything that crosses zones and try to minimize them as much as possible. You never allow something to live on more than two zones. The guest is the red zone and the rest of the host environment is the yellow zone. QEMU bridges between the red and yellow zone. That is fundamentally its job in the stack. Other than the guest agent, VDSM lives purely in the yellow zone. In fact, VDSM bridges from the yellow zone to the green zone (broader management infrastructure). It may be easier to skip QEMU and have VDSM also stride into the red zone. It's always easier to cross zones. But it's not good security practice. There is tremendous value in having clean security layers. Regards, Anthony Liguori ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
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: > > >>> > >>> > >>> > >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) > > >>> > >>> > >>> > >>>If we're gathering requirements and trying to come up with one agent to > >>>rule them all, don't forget > >>>about VDI and the Spice agent. Currently the spice agent handles the > >>>following: > >>> > >>>1) Paravirtual mouse (needed to get mouse coordinates right with multi > >>>monitor setups) > > > >I thought there was wide agreement that pv mouse should be extracted from > >the guest agent into its own driver. > > Yes AFAIK there is, but no-one has done that yet. I was merely listening what > the spice > agent is doing today, hopefully tomorrow > > > > >>>2) Send client monitor configuration, so that the guest os can adjust its > >>>resolution > >>>(and number and place of monitors) to match the client > > > >I also wonder if this should be part of QXL? > > That is not really practically since this is something between the client and > the guest, > where as the QXL device does communication between the hypervisor (qemu) and > the guest. > Also there is a 1 head per QXL device relation, so that would mean that a > single qxl dev > needs to be aware of other QXL devices in order to communicate the relative > position of > its head to the other heads. We do want to allow multiple heads on a single qxl device, since it would make RandR work. This only relates to the second point, Hans first point is still valid. > > Regards, > > Hans > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
- Original Message - > On 11/16/2011 11:53 AM, Barak Azulay wrote: > > On Wednesday 16 November 2011 17:28:16 Michael Roth wrote: > >> 2) You'd also need a schema, similar to > >> qemu.git/qapi-schema-guest.json, > >> to describe the calls you're proxying. The existing infrastructure > >> in > >> QEMU will handle all the work of marshalling/unmarshalling > >> responses > >> back to the QMP client on the host-side. > >> > >> It's a bit of extra work, but the benefit is unifying the > >> qemu/guest-level management interface into a single place that's > >> easy > >> for QMP/libvirt to consume. > >> > > > > The issue is not whether it's possible or not or the amount of > > efforts need to > > be done for that to happen, either for qemu-ga or ovirt-guest-agent > > this work > > needs to be done. > > > > the question is whether all comminication should go through the > > monitor (hence > > double proxy) or ... only a subset of the commands that are closly > > related to > > hypervisor functionality and separate it from general > > management-system > > related actions (e.g. ovirt or any other management system that > > wants to > > communicate to the guest). > > Yes, all guest interaction should be funnelled through QEMU. QEMU > has one job > in life--to expose an interface to guests and turn it into something > more useful > to the host. QEMU expose an emulated AHCI controller and turns that > into VFS > operations. > > Likewise, QEMU should expose a paravirtual "agent" device to a guest, > and then > turn that into higher level management interfaces. Exposing higher level management interfaces means that qemu would have to do policy. I have no problem with this, but note that this is counter to what you've been advocating to up to now (e.g. high watermark event for disks). Also, you would still have to have low level interfaces to accomplish things that qemu has not implemented yet or is not interested in implementing (the use case is too narrow). > > QEMU's job is to sanitize information from the guest and try to turn > that into > something that is safer for the broader world to consume. QEMU also > deals with > isolating state in order to support things like live migration. This So are you suggesting that when a user reads a file you would automatically encode the contents? > ends up > being non trivial when it comes to guest agents as it turns out. > > When you bypass QEMU and have higher level components talk directly > to the > guest, you effectively skip through many layers of security and > potentially > break things like migration by spreading state beyond QEMU. It's of > course > fixable given enough hacking but it makes for a brittle architecture. > > VDSM runs as root, right? That means that a guest driven attack that No, vdsm runs as user vdsm. Operations that need root privileges are in a separate process with root privileges and this process exposes a limited API which vdsm is allowed to invoke. > exploits > an issue with guest-agent protocol handling is going to compromise > VDSM and gain > root access. OTOH, QEMU runs with greatly reduced privileges > isolating the > effect of such a compromise. > > VDSM really shouldn't be talking directly to the guest. libvirt > shouldn't be > either although it is now because we haven't properly plumbed the > guest agent > protocol through QMP. > > Regards, > > Anthony Liguori > ___ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/vdsm-devel > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: converging around a single guest agent
- Original Message - > I have been following this thread pretty closely and the one sentence > summary of > the current argument is: ovirt-guest-agent is already featureful and > tested, so > let's drop qemu-ga and have everyone adopt ovirt-guest-agent. What we're suggesting is let's drop *one* of the two agents (obviously it would be easier for us to drop qemu-ga, but we'd rather reach consensus and unite behind one agent regardless of which agent it is). > Unfortunately, > this track strays completely away from the stated goal of > convergence. I have > at least two examples of why the greater KVM community can never > adopt > ovirt-guest-agent as-is. To address this, I would like to counter > with an > example on how qemu-ga can enable the deployment of ovirt-guest-agent > features > and satisfy the needs of the whole community at the same time. > > 1) Scope: The ovirt-guest-agent contains functionality that is > incredibly > useful within the context of oVirt. Single Sign-on is very handy but > KVM users > outside the scope of oVirt will not want this extra complexity in > their agent. > For simplicity they will probably just write something small that > does what they > need (and we have failed to provide a ubiquitous KVM agent). I totally agree, but that could easily be resolved using the plugin architecture suggested before. > > 1) Deployment complexity: The more complex the guest agent is, the > more often it > will need to be updated (bug/security fixes, distro compatibility, > new > features). Rolling out guest agent updates does not scale well in > large > environments (especially when the guest and host administrators are > not the same > person). Using plugins, you just deploy the ones you need, keeping the attack surface / #bugs / need to update lower > > For these reasons (and many others), I support having an agent with > very basic > primitives that can be orchestrated by the host to provide needed > functionality. > This agent would present a low-level, stable, extensible API that > everyone can > use. Today qemu-ga supports the following verbs: sync ping info > shutdown > file-open file-close file-read file-write file-seek file-flush > fsfreeze-status > fsfreeze-freeze fsfreeze-thaw. If we add a generic execute > mechanism, then the > agent can provide everything needed by oVirt to deploy SSO. > > Let's assume that we have already agreed on some sort of security > policy for the > write-file and exec primitives. Consensus is possible on this issue > but I > don't want to get bogged down with that here. > > With the above primitives, SSO could be deployed automatically to a > guest with > the following sequence of commands: > > file-open "/sso-package.bin" "w" > file-write > file-close > file-open "/sso-package.bin" "x" > file-exec > file-close 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 "/sso/do-user-sso" "x" > exec > file-close > > 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 > IBM Linux Technology Center > > ___ > Arch mailing list > a...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > ___ vdsm-devel mailing list vdsm-devel@li
Re: [Qemu-devel] converging around a single guest agent
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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On 15/11/2011 19:33, Alon Levy wrote: > Does it have a seperate system level and user level part in Linux? It No. The ovirt-guest-agent have only one instance running in the system level. Gal. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On 11/16/2011 04:20 PM, Paolo Bonzini wrote: > ... >> >> It can just be a submodule (like we do with SeaBIOS, etc.). The only >> request is >> that we split guest agent out of vdsm so we don't have to also include >> all of >> vdsm in the release tarballs. That would make the guest agent an >> independent >> git repository and presumably project. > > It is already (git://gerrit.ovirt.org/ovirt-guest-agent). Barak, is > there a gitweb/cgit instance? http://gerrit.ovirt.org/gitweb?p=ovirt-guest-agent.git ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On 11/16/2011 02:24 PM, Adam Litke wrote: > I have been following this thread pretty closely and the one sentence summary > of > the current argument is: ovirt-guest-agent is already featureful and tested, > so > let's drop qemu-ga and have everyone adopt ovirt-guest-agent. Unfortunately, > this track strays completely away from the stated goal of convergence. I have > at least two examples of why the greater KVM community can never adopt > ovirt-guest-agent as-is. To address this, I would like to counter with an > example on how qemu-ga can enable the deployment of ovirt-guest-agent features > and satisfy the needs of the whole community at the same time. > > 1) Scope: The ovirt-guest-agent contains functionality that is incredibly > useful within the context of oVirt. Single Sign-on is very handy but KVM > users > outside the scope of oVirt will not want this extra complexity in their agent. > For simplicity they will probably just write something small that does what > they > need (and we have failed to provide a ubiquitous KVM agent). > > 1) Deployment complexity: The more complex the guest agent is, the more often > it > will need to be updated (bug/security fixes, distro compatibility, new > features). Rolling out guest agent updates does not scale well in large > environments (especially when the guest and host administrators are not the > same > person). > > For these reasons (and many others), I support having an agent with very basic > primitives that can be orchestrated by the host to provide needed > functionality. > This agent would present a low-level, stable, extensible API that everyone can > use. Today qemu-ga supports the following verbs: sync ping info shutdown > file-open file-close file-read file-write file-seek file-flush fsfreeze-status > fsfreeze-freeze fsfreeze-thaw. If we add a generic execute mechanism, then > the > agent can provide everything needed by oVirt to deploy SSO. > > Let's assume that we have already agreed on some sort of security policy for > the > write-file and exec primitives. Consensus is possible on this issue but I > don't want to get bogged down with that here. > > With the above primitives, SSO could be deployed automatically to a guest with > the following sequence of commands: > > file-open "/sso-package.bin" "w" > file-write > file-close > file-open "/sso-package.bin" "x" > file-exec > file-close > > 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 "/sso/do-user-sso" "x" > exec > file-close > > 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. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On 11/16/2011 11:53 AM, Barak Azulay wrote: > On Wednesday 16 November 2011 17:28:16 Michael Roth wrote: >> 2) You'd also need a schema, similar to qemu.git/qapi-schema-guest.json, >> to describe the calls you're proxying. The existing infrastructure in >> QEMU will handle all the work of marshalling/unmarshalling responses >> back to the QMP client on the host-side. >> >> It's a bit of extra work, but the benefit is unifying the >> qemu/guest-level management interface into a single place that's easy >> for QMP/libvirt to consume. >> > > The issue is not whether it's possible or not or the amount of efforts need to > be done for that to happen, either for qemu-ga or ovirt-guest-agent this work > needs to be done. > > the question is whether all comminication should go through the monitor (hence > double proxy) or ... only a subset of the commands that are closly related to > hypervisor functionality and separate it from general management-system > related actions (e.g. ovirt or any other management system that wants to > communicate to the guest). Yes, all guest interaction should be funnelled through QEMU. QEMU has one job in life--to expose an interface to guests and turn it into something more useful to the host. QEMU expose an emulated AHCI controller and turns that into VFS operations. Likewise, QEMU should expose a paravirtual "agent" device to a guest, and then turn that into higher level management interfaces. QEMU's job is to sanitize information from the guest and try to turn that into something that is safer for the broader world to consume. QEMU also deals with isolating state in order to support things like live migration. This ends up being non trivial when it comes to guest agents as it turns out. When you bypass QEMU and have higher level components talk directly to the guest, you effectively skip through many layers of security and potentially break things like migration by spreading state beyond QEMU. It's of course fixable given enough hacking but it makes for a brittle architecture. VDSM runs as root, right? That means that a guest driven attack that exploits an issue with guest-agent protocol handling is going to compromise VDSM and gain root access. OTOH, QEMU runs with greatly reduced privileges isolating the effect of such a compromise. VDSM really shouldn't be talking directly to the guest. libvirt shouldn't be either although it is now because we haven't properly plumbed the guest agent protocol through QMP. Regards, Anthony Liguori ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On 11/16/2011 11:53 AM, Barak Azulay wrote: > On Wednesday 16 November 2011 17:28:16 Michael Roth wrote: >> On 11/16/2011 06:13 AM, Barak Azulay wrote: >>> On Wednesday 16 November 2011 10:16:57 Alexander Graf wrote: On 16.11.2011, at 08:05, Barak Azulay wrote: > On Wednesday 16 November 2011 02:42:30 Alexander Graf wrote: >> On 16.11.2011, at 00:01, Michael Roth wrote: >>> But practically-speaking, it's unavoidable that qemu-specific >>> management tooling will need to communicate with qemu (via >>> QMP/libqmp/HMP/etc, or by proxy via libvirt). It's through those same >>> channels that the qemu-ga interfaces will ultimately be exposed, so >>> the problem of qemu-ga vs. ovirt-guest-agent isn't really any >>> different than the problem of QMP's system_powerdown/info_balloon/etc >>> vs. ovirt-guest-agent's >>> Shutdown/Available_Ram/etc: it's a policy decision rather than >>> argument for choosing one project over another. >> >> I don't see why we shouldn't be able to just proxy whatever >> communication happens between the guest agent and the management tool >> through qemu. At that point qemu could talk to the guest agent just as >> well as the management tool and everyone's happy. > > I'm not sure proxying all the requests to the guset through qemu is > desirable, other than having single point of management, most of the > calls will be pass throgh and has no interest to qemu (MITM?). > > There is a big advantage on direct communication (VDSM<-> agent), that > way features can be added to the ovirt stack without the need to add it > to the qemu. If we keep the protocol well-defined, we can get that for free. Just have every command carry its own size and a request id shich the reply also contains and suddenly you get asynchronous proxyable communication. >>> >>> Sure we can keep commands synchronized in various ways the question is do >>> we want that, there are a few down sides for that: >>> 1 - VDSM will have to pass through 2 proxies (libvirt& qemu) in order to >>> deliver a message to the guest, this byiself is not such a big >>> disadvantage but will force us to handle much more corner-cases. >> >> Can't rule out the possibility of corner-cases resulting from this, but >> the practical way to look at it is VDSM will need handle libvirt/QMP >> protocols well. The implementation of the proxying mechanism is where >> the extra challenge comes into play, but this should be transparent to >> the protocols VDSM speaks. >> >> Implementation-wise, just to give you an idea of the work involved if we >> took this route: >> >> 1) ovirt-guest-agent would need to convert request/response payloads >> from/to QMP payloads on the guest-side, which are JSON and should, >> theoretically, mesh well with a python-based agent. > > > > ovirt-guest-agent already uses JSON for communication with VDSM > > > >> >> 2) You'd also need a schema, similar to qemu.git/qapi-schema-guest.json, >> to describe the calls you're proxying. The existing infrastructure in >> QEMU will handle all the work of marshalling/unmarshalling responses >> back to the QMP client on the host-side. >> >> It's a bit of extra work, but the benefit is unifying the >> qemu/guest-level management interface into a single place that's easy >> for QMP/libvirt to consume. >> > > The issue is not whether it's possible or not or the amount of efforts need to > be done for that to happen, either for qemu-ga or ovirt-guest-agent this work > needs to be done. Right, just trying to flesh out the areas where the extra corner-cases argument to this approach would be relevant. On the host-side the corner cases are something that already needs to be handled in the context of QMP/libvirt in general, it's in the implementation of 1) and 2) on the agent side where they'd potentially arise. > > the question is whether all comminication should go through the monitor (hence > double proxy) or ... only a subset of the commands that are closly related to > hypervisor functionality and separate it from general management-system > related actions (e.g. ovirt or any other management system that wants to > communicate to the guest). > > > >>> 2 - looking at the qemu-ga functionality (read& write ...) do we really >>> want to let a big chunk of data through both qemu& libvirt rather than >>> directtly to the comsumer (VDSM) >> >> VDSM isn't the only consumer however, HMP/QMP and libvirt are consumers >> in and of themselves. > > > This is not the claim it was just an example, it may as well be any other > management system. > > The question still remains, if we want to pass a big chunk of data, do we want > it to be passed through this double proxy layer ? personally I think it does > not belong to core hypervisor management interface. The common use case in practice has been reading things like /proc/meminfo, which ties into higher-level gues
Re: converging around a single guest agent
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 "/sso-package.bin" "w" file-write file-close file-open "/sso-package.bin" "x" file-exec file-close 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 "/sso/do-user-sso" "x" exec file-close 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 IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On Wednesday 16 November 2011 17:28:16 Michael Roth wrote: > On 11/16/2011 06:13 AM, Barak Azulay wrote: > > On Wednesday 16 November 2011 10:16:57 Alexander Graf wrote: > >> On 16.11.2011, at 08:05, Barak Azulay wrote: > >>> On Wednesday 16 November 2011 02:42:30 Alexander Graf wrote: > On 16.11.2011, at 00:01, Michael Roth wrote: > > But practically-speaking, it's unavoidable that qemu-specific > > management tooling will need to communicate with qemu (via > > QMP/libqmp/HMP/etc, or by proxy via libvirt). It's through those same > > channels that the qemu-ga interfaces will ultimately be exposed, so > > the problem of qemu-ga vs. ovirt-guest-agent isn't really any > > different than the problem of QMP's system_powerdown/info_balloon/etc > > vs. ovirt-guest-agent's > > Shutdown/Available_Ram/etc: it's a policy decision rather than > > argument for choosing one project over another. > > I don't see why we shouldn't be able to just proxy whatever > communication happens between the guest agent and the management tool > through qemu. At that point qemu could talk to the guest agent just as > well as the management tool and everyone's happy. > >>> > >>> I'm not sure proxying all the requests to the guset through qemu is > >>> desirable, other than having single point of management, most of the > >>> calls will be pass throgh and has no interest to qemu (MITM?). > >>> > >>> There is a big advantage on direct communication (VDSM<-> agent), that > >>> way features can be added to the ovirt stack without the need to add it > >>> to the qemu. > >> > >> If we keep the protocol well-defined, we can get that for free. Just > >> have every command carry its own size and a request id shich the reply > >> also contains and suddenly you get asynchronous proxyable > >> communication. > > > > Sure we can keep commands synchronized in various ways the question is do > > we want that, there are a few down sides for that: > > 1 - VDSM will have to pass through 2 proxies (libvirt& qemu) in order to > > deliver a message to the guest, this byiself is not such a big > > disadvantage but will force us to handle much more corner-cases. > > Can't rule out the possibility of corner-cases resulting from this, but > the practical way to look at it is VDSM will need handle libvirt/QMP > protocols well. The implementation of the proxying mechanism is where > the extra challenge comes into play, but this should be transparent to > the protocols VDSM speaks. > > Implementation-wise, just to give you an idea of the work involved if we > took this route: > > 1) ovirt-guest-agent would need to convert request/response payloads > from/to QMP payloads on the guest-side, which are JSON and should, > theoretically, mesh well with a python-based agent. ovirt-guest-agent already uses JSON for communication with VDSM > > 2) You'd also need a schema, similar to qemu.git/qapi-schema-guest.json, > to describe the calls you're proxying. The existing infrastructure in > QEMU will handle all the work of marshalling/unmarshalling responses > back to the QMP client on the host-side. > > It's a bit of extra work, but the benefit is unifying the > qemu/guest-level management interface into a single place that's easy > for QMP/libvirt to consume. > The issue is not whether it's possible or not or the amount of efforts need to be done for that to happen, either for qemu-ga or ovirt-guest-agent this work needs to be done. the question is whether all comminication should go through the monitor (hence double proxy) or ... only a subset of the commands that are closly related to hypervisor functionality and separate it from general management-system related actions (e.g. ovirt or any other management system that wants to communicate to the guest). > > 2 - looking at the qemu-ga functionality (read& write ...) do we really > > want to let a big chunk of data through both qemu& libvirt rather than > > directtly to the comsumer (VDSM) > > VDSM isn't the only consumer however, HMP/QMP and libvirt are consumers > in and of themselves. This is not the claim it was just an example, it may as well be any other management system. The question still remains, if we want to pass a big chunk of data, do we want it to be passed through this double proxy layer ? personally I think it does not belong to core hypervisor management interface. > > > 3 - When events are fired from the guest agent, the delay of passing it > > through a double proxy will have it's latency penalty (as we have > > experianced in the client disconnect spice event) > > Getting them out of the guest is probably the biggest factor, delivering > them between processes on the host is likely a small hit in comparison. > From our experiance in the last 3 years this latency (passing a single proxy layer, libvirt) , affected the overall functionality & behaviour. However using libvirt as a monitor prox
Re: [Qemu-devel] converging around a single guest agent
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: >>> >>> >>> > 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) >>> >>> >>> >>> If we're gathering requirements and trying to come up with one agent to >>> rule them all, don't forget >>> about VDI and the Spice agent. Currently the spice agent handles the >>> following: >>> >>> 1) Paravirtual mouse (needed to get mouse coordinates right with multi >>> monitor setups) > > I thought there was wide agreement that pv mouse should be extracted from the > guest agent into its own driver. Yes AFAIK there is, but no-one has done that yet. I was merely listening what the spice agent is doing today, hopefully tomorrow > >>> 2) Send client monitor configuration, so that the guest os can adjust its >>> resolution >>> (and number and place of monitors) to match the client > > I also wonder if this should be part of QXL? That is not really practically since this is something between the client and the guest, where as the QXL device does communication between the hypervisor (qemu) and the guest. Also there is a 1 head per QXL device relation, so that would mean that a single qxl dev needs to be aware of other QXL devices in order to communicate the relative position of its head to the other heads. Regards, Hans ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On 11/16/2011 06:13 AM, Barak Azulay wrote: > On Wednesday 16 November 2011 10:16:57 Alexander Graf wrote: >> On 16.11.2011, at 08:05, Barak Azulay 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 > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On 11/16/2011 02:16 AM, Ayal Baron wrote: > > > - Original Message - >> Hi, >> >> On 11/15/2011 11: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) >>> >> >> >> >> If we're gathering requirements and trying to come up with one agent >> to rule them all, don't forget > > I don't think we're trying to come up with one agent to rule them all, just > avoid duplication of efforts if most of what the 2 agents are doing overlaps. > I think we can safely say that seeing as oVirt is KVM centric, > ovirt-guest-agent wants to leverage qemu/kvm to the fullest which aligns with > what qemu-guest-agent is doing. > However, ovirt-guest-agent is required to do a lot more, so we need to see if > and how we resolve this. > >> about VDI and the Spice agent. Currently the spice agent handles the >> following: >> >> 1) Paravirtual mouse (needed to get mouse coordinates right with >> multi monitor setups) >> 2) Send client monitor configuration, so that the guest os can adjust >> its resolution >> (and number and place of monitors) to match the client >> 3) Copy and paste in a platform neutral manner, if anyone wishes to >> add this to another agent >> please, please contact us (me) first. This is easy to get wrong >> (we went through 2 revisions >> of the protocol for this). >> 4) Allow the client to request the guest to tone down the bling (for >> low spec clients) >> >> Notes: >> 1) All of these are client<-> guest communication, rather then the >> host<-> guest communication >> which the other agents seem to focus on. >> >> 2) Getting copy paste right requires a system level guest agent >> process as well as a per user >> session agent process. > > Neither qemu-guest-agent nor ovirt-guest-agent is aligned with doing any of > the above, so I'm not sure there is any justification in uniting the spice > agent with the rest. > copy/paste was actually one of the initial use cases motivating qemu-ga; it's just that the requirements (system+user-level agents) were so different from the more pressing use cases of things like reliable shutdown/reboot that it's been put off for now. At some point we had a basic plan on how to approach it, but that needs to be re-assessed. >> >> Regards, >> >> Hans >> > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
- 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 > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
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: >>> >> >> >> 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) >>> >> >> >> >> If we're gathering requirements and trying to come up with one agent to rule >> them all, don't forget >> about VDI and the Spice agent. Currently the spice agent handles the >> following: >> >> 1) Paravirtual mouse (needed to get mouse coordinates right with multi >> monitor setups) I thought there was wide agreement that pv mouse should be extracted from the guest agent into its own driver. >> 2) Send client monitor configuration, so that the guest os can adjust its >> resolution >> (and number and place of monitors) to match the client I also wonder if this should be part of QXL? Regards, Anthony Liguori >> 3) Copy and paste in a platform neutral manner, if anyone wishes to add this >> to another agent >> please, please contact us (me) first. This is easy to get wrong (we went >> through 2 revisions >> of the protocol for this). >> 4) Allow the client to request the guest to tone down the bling (for low >> spec clients) >> > As long as we are collecting requirements, even if as Ayal said merging > spice requirements is not the OP's intent: > > 5) Window management - Agent can set location of windows, report > existing running applications and locations, get notified when a new > window is created. For exposing individual applications, this is a > future requirement. > >> Notes: >> 1) All of these are client<-> guest communication, rather then the host<-> >> guest communication >> which the other agents seem to focus on. >> >> 2) Getting copy paste right requires a system level guest agent process as >> well as a per user >> session agent process. >> > >> Regards, >> >> Hans >> > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
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: >>> >> >> >> 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) >>> >> >> >> >> If we're gathering requirements and trying to come up with one agent to rule >> them all, don't forget >> about VDI and the Spice agent. Currently the spice agent handles the >> following: >> >> 1) Paravirtual mouse (needed to get mouse coordinates right with multi >> monitor setups) >> 2) Send client monitor configuration, so that the guest os can adjust its >> resolution >> (and number and place of monitors) to match the client >> 3) Copy and paste in a platform neutral manner, if anyone wishes to add this >> to another agent >> please, please contact us (me) first. This is easy to get wrong (we went >> through 2 revisions >> of the protocol for this). >> 4) Allow the client to request the guest to tone down the bling (for low >> spec clients) I suggest we'll have a single protocol and serialization means (JSON) plus a common framework that manages permissions within the guest. Beyond that, the agent should have various plugins for example the above spice related ones (could be also vnc ones) can be implemented as plugins that the ovirt agent will invoke. >> > As long as we are collecting requirements, even if as Ayal said merging > spice requirements is not the OP's intent: > > 5) Window management - Agent can set location of windows, report > existing running applications and locations, get notified when a new > window is created. For exposing individual applications, this is a > future requirement. > >> Notes: >> 1) All of these are client<-> guest communication, rather then the host<-> >> guest communication >> which the other agents seem to focus on. >> >> 2) Getting copy paste right requires a system level guest agent process as >> well as a per user >> session agent process. >> > >> Regards, >> >> Hans >> > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
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 >>> a...@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/arch >>> >> > > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
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 >> a...@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/arch >> > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On Wednesday 16 November 2011 10:16:57 Alexander Graf wrote: > On 16.11.2011, at 08:05, Barak Azulay 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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
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: > > > > > > >>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) > > > > > > If we're gathering requirements and trying to come up with one agent to rule > them all, don't forget > about VDI and the Spice agent. Currently the spice agent handles the > following: > > 1) Paravirtual mouse (needed to get mouse coordinates right with multi > monitor setups) > 2) Send client monitor configuration, so that the guest os can adjust its > resolution >(and number and place of monitors) to match the client > 3) Copy and paste in a platform neutral manner, if anyone wishes to add this > to another agent >please, please contact us (me) first. This is easy to get wrong (we went > through 2 revisions >of the protocol for this). > 4) Allow the client to request the guest to tone down the bling (for low spec > clients) > As long as we are collecting requirements, even if as Ayal said merging spice requirements is not the OP's intent: 5) Window management - Agent can set location of windows, report existing running applications and locations, get notified when a new window is created. For exposing individual applications, this is a future requirement. > Notes: > 1) All of these are client <-> guest communication, rather then the host <-> > guest communication > which the other agents seem to focus on. > > 2) Getting copy paste right requires a system level guest agent process as > well as a per user > session agent process. > > Regards, > > Hans > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On Tue, Nov 15, 2011 at 05:01:00PM -0600, Michael Roth wrote: > On 11/15/2011 11:24 AM, Barak Azulay wrote: > >Hi, > > > >One of the breakout sessions during the ovirt workshop [1] was about the > >guest > >tools, and focused mainly on the ovirt-guest-agent [2]. > > > >One of the issues discussed there, was the various existing guest agents out > >there, and the need to converge the efforts to a single agent that will serve > >all. > > > >while 4 agents were mentioned (Matahari, vdagent, qemu-ga& > >ovirt-guest-agent) > >during that discussion, we narrowed it down to 2 candidates: > > > >qemu-ga (aka virt-agent): > >- > >- Qemu specific - it was aimed for specific qemu needs (mainly quiesce guest > >I/O) > >- Communicates directly with qemu (not implemented yet) > > Won't be implemented until we finish the QMP conversion to QAPI > since that's a prereq to implementing a QMP server with proper async > support (needed for communication with a potentially non-responsive > guest agent). But once it's in guest extensions are completely > transparent to QMP/libvirt, which is highly desirable from a > management perspective since you're coding against a single > API/transport. FYI, I already have patches for libvirt to make it directly talk to a QEMU guest agent for a guest. We just configure the guest agent with a UNIX socket on the host, and livirt talks QMP to that directly. It was trivial, since the agent uses the same basic protocol as the QMP monitor, so from that POV I really like the QEMU guest agent for libvirt integration, and loathe to have to integrate with something that has invented yet another comms protocol. I expect we'll merge these patches in libvirt 0.9.8 and my intent is for Fedora 17 guests to have qemu-ga installed by default, so we get reliable guest shutdown/reboot support at last. https://www.redhat.com/archives/libvir-list/2011-October/msg00135.html Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
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
>
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
Hi, On 11/15/2011 11: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) > 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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On 16.11.2011, at 08:05, Barak Azulay 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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
- Original Message - > Hi, > > On 11/15/2011 11: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) > > > > > > If we're gathering requirements and trying to come up with one agent > to rule them all, don't forget I don't think we're trying to come up with one agent to rule them all, just avoid duplication of efforts if most of what the 2 agents are doing overlaps. I think we can safely say that seeing as oVirt is KVM centric, ovirt-guest-agent wants to leverage qemu/kvm to the fullest which aligns with what qemu-guest-agent is doing. However, ovirt-guest-agent is required to do a lot more, so we need to see if and how we resolve this. > about VDI and the Spice agent. Currently the spice agent handles the > following: > > 1) Paravirtual mouse (needed to get mouse coordinates right with > multi monitor setups) > 2) Send client monitor configuration, so that the guest os can adjust > its resolution > (and number and place of monitors) to match the client > 3) Copy and paste in a platform neutral manner, if anyone wishes to > add this to another agent > please, please contact us (me) first. This is easy to get wrong > (we went through 2 revisions > of the protocol for this). > 4) Allow the client to request the guest to tone down the bling (for > low spec clients) > > Notes: > 1) All of these are client <-> guest communication, rather then the > host <-> guest communication > which the other agents seem to focus on. > > 2) Getting copy paste right requires a system level guest agent > process as well as a per user > session agent process. Neither qemu-guest-agent nor ovirt-guest-agent is aligned with doing any of the above, so I'm not sure there is any justification in uniting the spice agent with the rest. > > Regards, > > Hans > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
On Tuesday 15 November 2011 21:45:42 Perry Myers wrote: > On 11/15/2011 01:08 PM, Subhendu Ghosh wrote: > > On 11/15/2011 01:01 PM, Perry Myers wrote: > >> On 11/15/2011 12:24 PM, Barak Azulay wrote: > >>> Hi, > >>> > >>> One of the breakout sessions during the ovirt workshop [1] was about > >>> the guest > >>> tools, and focused mainly on the ovirt-guest-agent [2]. > >>> > >>> One of the issues discussed there, was the various existing guest > >>> agents out > >>> there, and the need to converge the efforts to a single agent that > >>> will serve > >>> all. > >>> > >>> while 4 agents were mentioned (Matahari, vdagent, qemu-ga& > >>> ovirt-guest-agent) > >>> during that discussion, we narrowed it down to 2 candidates: > >>> > >>> qemu-ga (aka virt-agent): > >>> - > >>> - Qemu specific - it was aimed for specific qemu needs (mainly > >>> quiesce guest > >>> I/O) > >>> - Communicates directly with qemu (not implemented yet) > >>> - Supports ? > >>> - So far linux only > >>> - written in C > >>> > >>> Ovirt-guest-agent: > >>> -- > >>> - Has been around for a long time (~5 years) - considered stable > >>> - Started as rhevm specific but evolved a lot since then > >>> - Currently the only fully functional guest agent available for ovirt > >>> - Written in python > >>> - Some VDI related sub components are written in C& C++ > >>> - Supports a well defined list of message types / protocol [3] > >>> - Supports the folowing guest OSs > >>> > >>>Linux: RHEL5, RHEL6 F15, F16(soon) > >>>Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2) > >>> > >>> The need to converge is obvious, and now that ovirt-guest-agent is > >>> opensourced > >>> under the ovirt stack, and since it already produces value for > >>> enterprise > >>> installations, and is cross platform, I offer to join hands around > >>> ovirt- > >>> guest-agent and formalize a single code base that will serve us all. > >>> > >>> git @ git://gerrit.ovirt.org/ovirt-guest-agent > >>> > >>> Thoughts ? > >> > >> +1 > >> > >> The only downside that I concretely heard from folks re: > >> ovirt-guest-agent was that it is written in Python. Two thoughts there: > >> > >> 1. On Windows it is compiled to an executable, so no separate python > >> > >> stack needed > >> > >> 2. ovirt-guest-agent is not very large and does not bring in a lot > >> > >> (any?) additional python class dependencies above/beyond the core > >> language and interpreter. Given this, the chances of dealing with > >> python stack issues are probably minimal and also the overhead of > >> including _just_ the base python interpreter in a given guest OS is > >> very lightweight. Core python RPM in F16 is about 80k. The ovirt-guest-agent also depends on pywin32 package (http://sourceforge.net/projects/pywin32/files/) for windows platforms > >> > >> Perry > > > > If you needed WMI enablement on Windows - could you support that with > > this arch? > > I'm not a WMI expert, but google search first result on 'python WMI' > turned up: > > http://timgolden.me.uk/python/wmi/index.html As the ovirt-guest-agent the above package uses also pywin32. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: converging around a single guest agent
- 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 > a...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: converging around a single guest agent
On 11/15/2011 01:08 PM, Subhendu Ghosh wrote: > On 11/15/2011 01:01 PM, Perry Myers wrote: >> On 11/15/2011 12:24 PM, Barak Azulay wrote: >>> Hi, >>> >>> One of the breakout sessions during the ovirt workshop [1] was about >>> the guest >>> tools, and focused mainly on the ovirt-guest-agent [2]. >>> >>> One of the issues discussed there, was the various existing guest >>> agents out >>> there, and the need to converge the efforts to a single agent that >>> will serve >>> all. >>> >>> while 4 agents were mentioned (Matahari, vdagent, qemu-ga& >>> ovirt-guest-agent) >>> during that discussion, we narrowed it down to 2 candidates: >>> >>> qemu-ga (aka virt-agent): >>> - >>> - Qemu specific - it was aimed for specific qemu needs (mainly >>> quiesce guest >>> I/O) >>> - Communicates directly with qemu (not implemented yet) >>> - Supports ? >>> - So far linux only >>> - written in C >>> >>> Ovirt-guest-agent: >>> -- >>> - Has been around for a long time (~5 years) - considered stable >>> - Started as rhevm specific but evolved a lot since then >>> - Currently the only fully functional guest agent available for ovirt >>> - Written in python >>> - Some VDI related sub components are written in C& C++ >>> - Supports a well defined list of message types / protocol [3] >>> - Supports the folowing guest OSs >>>Linux: RHEL5, RHEL6 F15, F16(soon) >>>Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2) >>> >>> >>> The need to converge is obvious, and now that ovirt-guest-agent is >>> opensourced >>> under the ovirt stack, and since it already produces value for >>> enterprise >>> installations, and is cross platform, I offer to join hands around >>> ovirt- >>> guest-agent and formalize a single code base that will serve us all. >>> >>> git @ git://gerrit.ovirt.org/ovirt-guest-agent >>> >>> Thoughts ? >> >> +1 >> >> The only downside that I concretely heard from folks re: >> ovirt-guest-agent was that it is written in Python. Two thoughts there: >> >> 1. On Windows it is compiled to an executable, so no separate python >> stack needed >> >> 2. ovirt-guest-agent is not very large and does not bring in a lot >> (any?) additional python class dependencies above/beyond the core >> language and interpreter. Given this, the chances of dealing with >> python stack issues are probably minimal and also the overhead of >> including _just_ the base python interpreter in a given guest OS is >> very lightweight. Core python RPM in F16 is about 80k. >> >> Perry > > If you needed WMI enablement on Windows - could you support that with > this arch? I'm not a WMI expert, but google search first result on 'python WMI' turned up: http://timgolden.me.uk/python/wmi/index.html ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: converging around a single guest agent
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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: converging around a single guest agent
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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: converging around a single guest agent
On 11/15/2011 01:01 PM, Perry Myers wrote: > On 11/15/2011 12:24 PM, Barak Azulay wrote: >> Hi, >> >> One of the breakout sessions during the ovirt workshop [1] was about the >> guest >> tools, and focused mainly on the ovirt-guest-agent [2]. >> >> One of the issues discussed there, was the various existing guest agents out >> there, and the need to converge the efforts to a single agent that will serve >> all. >> >> while 4 agents were mentioned (Matahari, vdagent, qemu-ga& >> ovirt-guest-agent) >> during that discussion, we narrowed it down to 2 candidates: >> >> qemu-ga (aka virt-agent): >> - >> - Qemu specific - it was aimed for specific qemu needs (mainly quiesce guest >> I/O) >> - Communicates directly with qemu (not implemented yet) >> - Supports ? >> - So far linux only >> - written in C >> >> Ovirt-guest-agent: >> -- >> - Has been around for a long time (~5 years) - considered stable >> - Started as rhevm specific but evolved a lot since then >> - Currently the only fully functional guest agent available for ovirt >> - Written in python >> - Some VDI related sub components are written in C& C++ >> - Supports a well defined list of message types / protocol [3] >> - Supports the folowing guest OSs >>Linux: RHEL5, RHEL6 F15, F16(soon) >>Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2) >> >> >> The need to converge is obvious, and now that ovirt-guest-agent is >> opensourced >> under the ovirt stack, and since it already produces value for enterprise >> installations, and is cross platform, I offer to join hands around ovirt- >> guest-agent and formalize a single code base that will serve us all. >> >> git @ git://gerrit.ovirt.org/ovirt-guest-agent >> >> Thoughts ? > > +1 > > The only downside that I concretely heard from folks re: > ovirt-guest-agent was that it is written in Python. Two thoughts there: > > 1. On Windows it is compiled to an executable, so no separate python > stack needed > > 2. ovirt-guest-agent is not very large and does not bring in a lot > (any?) additional python class dependencies above/beyond the core > language and interpreter. Given this, the chances of dealing with > python stack issues are probably minimal and also the overhead of > including _just_ the base python interpreter in a given guest OS is > very lightweight. Core python RPM in F16 is about 80k. > > Perry If you needed WMI enablement on Windows - could you support that with this arch? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: converging around a single 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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [Qemu-devel] converging around a single guest agent
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 > ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
converging around a single guest agent
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 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
