On 11/16/2011 02:24 PM, Adam Litke wrote: > I have been following this thread pretty closely and the one sentence summary > of > the current argument is: ovirt-guest-agent is already featureful and tested, > so > let's drop qemu-ga and have everyone adopt ovirt-guest-agent. Unfortunately, > this track strays completely away from the stated goal of convergence. I have > at least two examples of why the greater KVM community can never adopt > ovirt-guest-agent as-is. To address this, I would like to counter with an > example on how qemu-ga can enable the deployment of ovirt-guest-agent features > and satisfy the needs of the whole community at the same time. > > 1) Scope: The ovirt-guest-agent contains functionality that is incredibly > useful within the context of oVirt. Single Sign-on is very handy but KVM > users > outside the scope of oVirt will not want this extra complexity in their agent. > For simplicity they will probably just write something small that does what > they > need (and we have failed to provide a ubiquitous KVM agent). > > 1) Deployment complexity: The more complex the guest agent is, the more often > it > will need to be updated (bug/security fixes, distro compatibility, new > features). Rolling out guest agent updates does not scale well in large > environments (especially when the guest and host administrators are not the > same > person). > > For these reasons (and many others), I support having an agent with very basic > primitives that can be orchestrated by the host to provide needed > functionality. > This agent would present a low-level, stable, extensible API that everyone can > use. Today qemu-ga supports the following verbs: sync ping info shutdown > file-open file-close file-read file-write file-seek file-flush fsfreeze-status > fsfreeze-freeze fsfreeze-thaw. If we add a generic execute mechanism, then > the > agent can provide everything needed by oVirt to deploy SSO. > > Let's assume that we have already agreed on some sort of security policy for > the > write-file and exec primitives. Consensus is possible on this issue but I > don't want to get bogged down with that here. > > With the above primitives, SSO could be deployed automatically to a guest with > the following sequence of commands: > > file-open "<exec-dir>/sso-package.bin" "w" > file-write<fh> <buf> > file-close<fh> > file-open "<exec-dir>/sso-package.bin" "x" > file-exec<fh> <args> > file-close<fh> > > At this point, the package is installed. It can contain whatever existing > logic > exists in the ovirt-guest-agent today. To perform a user login, we'll assume > that sso-package.bin contains an executable 'sso/do-user-sso': > > file-open "<exec-dir>/sso/do-user-sso" "x" > exec<fh> <args> > file-close<fh> > > At this point the user would be logged in as before. > > Obviously, this type of approach could be made easier by providing a well > designed exec API that returns command exit codes and (optionally) command > output. We could also formalize the install of additional components into > some > sort of plugin interface. These are all relatively easy problems to solve. > > If we go in this direction, we would have a simple, general-purpose agent with > low-level primitives that everyone can use. We would also be able to easily > extend the agent based on the needs of individual deployments (not the least > of > which is an oVirt environment). If certain plugins become popular enough, > they > can always be promoted to first-order API calls in future versions of the API. > > What are your thoughts on this approach? >
Another possibility, for functionality that may be more suited for a daemon that needs to maintain a lot of state, would be modifying the ovirt-guest-agent code to read/write to a (guest-local) named pipe. We can could then deploy the daemon via file-write+exec (assuming we provide a fork/detach flag), and the management tool could do request/response via file-write/file-read. It's almost equivalent to reading/writing directly to a virtio-serial channel, except there'd need to be a translation (base64decode(qmp_json_response.payload)->oga_json_response, and vice-versa) at the ovirt management layer. And we still reduce the deployment complexity since we can deploy/upgrade via a hypervisor push. There's actually so many ways this could be done with exec support... What's being lost in both approaches are ovirt-guest-agent-provided events, however. We'd either need to subsume those into qemu-ga, or provide a proxying mechanism on the guest-side for event reporting, which is something we've discussed in the past with the Spice folks with regard to support for session-level agents. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel