IMHO this should really be out of scope for QEMU guest agent / libvirt. The guest agent scope is really aimed at providing functions necessary for managing the operation of virtual machine. This is things like CPU hotplug, disk quiesce for snapshotting, and similar things.   Reporting guest OS uptime is getting into the area of managing the guest operating system. That area is absolutely enormous in scope and there are countless existing tools that fill that can role. As such IMHO it doesn't make sense to add uptime reporting into QEMU guest agent, nor libvirt.

(In reply to Daniel Berrange from comment #1)
> IMHO this should really be out of scope for QEMU guest agent / libvirt. The
> guest agent scope is really aimed at providing functions necessary for
> managing the operation of virtual machine. This is things like CPU hotplug,
> disk quiesce for snapshotting, and similar things.   Reporting guest OS
> uptime is getting into the area of managing the guest operating system. That
> area is absolutely enormous in scope and there are countless existing tools
> that fill that can role. As such IMHO it doesn't make sense to add uptime
> reporting into QEMU guest agent, nor libvirt.

I agree with you, and I sometime wonder why the guest-agent already has support for guest-exec, or file read/write etc. At least, those fairly low-level commands can let people build others on top without the need to modify qga. I guess it's the case for uptime too.

nevertheless the line is sometime blurry, and qga also has get-time/set-time, so why not uptime (as a get-time flag?)...

(In reply to Marc-Andre Lureau from comment #2)
> (In reply to Daniel Berrange from comment #1)
> > IMHO this should really be out of scope for QEMU guest agent / libvirt. The
> > guest agent scope is really aimed at providing functions necessary for
> > managing the operation of virtual machine. This is things like CPU hotplug,
> > disk quiesce for snapshotting, and similar things.   Reporting guest OS
> > uptime is getting into the area of managing the guest operating system. That
> > area is absolutely enormous in scope and there are countless existing tools
> > that fill that can role. As such IMHO it doesn't make sense to add uptime
> > reporting into QEMU guest agent, nor libvirt.
> 
> I agree with you, and I sometime wonder why the guest-agent already has
> support for guest-exec, or file read/write etc. At least, those fairly
> low-level commands can let people build others on top without the need to
> modify qga. I guess it's the case for uptime too.

From a libvirt POV, we certainly don't intend to ever expose guest-exec, or the file read/write functions in the libvirt API as they are far too low level. These particular commands have the added major downside that they make it impossible to provide any meaningful SELinux security policy for the guest agent, because they essentially imply the guest agent can run any command or write any file. I'm not sure Fedora selinux policy even allows these commands to be used.

(In reply to Marc-Andre Lureau from comment #3)
> nevertheless the line is sometime blurry, and qga also has
> get-time/set-time, so why not uptime (as a get-time flag?)...

The ability to set time is needed as part of the virtual machine management, so that we can fix the guest time after restoring from a saved state image, hence is in scope.

I like the idea of restricting qemu-ga to virtualization-only features, but it might be too late:

# @guest-set-user-password
#
# @username: the user account whose password to change
# @password: the new password entry string, base64 encoded
# @crypted: true if password is already crypt()d, false if raw

(In reply to Ademar Reis from comment #6)
> I like the idea of restricting qemu-ga to virtualization-only features, but
> it might be too late:
> 
> # @guest-set-user-password
> #
> # @username: the user account whose password to change
> # @password: the new password entry string, base64 encoded
> # @crypted: true if password is already crypt()d, false if raw

That's providing a mechanism for host admin to get back into a running guest. There's not really any alternative mechanism for that that exists, unless you want a public network service with no auth that lets you reset the root password ;-) IOW, I think guest-set-user-password is in scope for virt, as there's no general alternative.

If there's consensus we don't want qemu-ga to enter the area of non-virt system info or features, then feel free to close this BZ.

closing, per comment #8