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.