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
>>> collecting requirements. We can then figure out if the two sets of
>>> are strictly overlapping or if there are any requirements that are
>>> in opposition.
>> 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
>> 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
>> 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
> 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 ...
> Anthony Liguori
>>> Anthony Liguori
>>> Arch mailing list
vdsm-devel mailing list