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

[Dor Laor <dlaor@redhat.com>]

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

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

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

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