qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Ayal Baron <abaron@redhat.com>
Cc: Gal Hammer <ghammer@redhat.com>,
	Barak Azulay <bazulay@redhat.com>,
	arch@ovirt.org, qemu-devel@nongnu.org,
	vdsm-devel@lists.fedorahosted.org
Subject: Re: [Qemu-devel] converging  around a single guest agent
Date: Wed, 16 Nov 2011 07:36:39 -0600	[thread overview]
Message-ID: <4EC3BC67.6030005@codemonkey.ws> (raw)
In-Reply-To: <e9c42db1-2506-4c55-8e59-ee7d27cb9cb7@zmail07.collab.prod.int.phx2.redhat.com>

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?

Regards,

Anthony Liguori

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

  parent reply	other threads:[~2011-11-16 13:36 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-15 17:24 [Qemu-devel] converging around a single guest agent Barak Azulay
2011-11-15 17:33 ` Alon Levy
2011-11-16 13:08   ` Gal Hammer
2011-11-15 18:01 ` Perry Myers
2011-11-15 18:08   ` Subhendu Ghosh
2011-11-15 19:45     ` Perry Myers
2011-11-16  6:48       ` Barak Azulay
2011-11-15 19:08 ` Anthony Liguori
2011-11-15 22:39   ` Ayal Baron
2011-11-16  7:53     ` Hans de Goede
2011-11-16  8:16       ` Ayal Baron
2011-11-16 14:59         ` Michael Roth
2011-11-17 15:11           ` Alon Levy
2011-11-16 12:07       ` Alon Levy
2011-11-16 13:45         ` Dor Laor
2011-11-16 13:47         ` Anthony Liguori
2011-11-16 17:55           ` Hans de Goede
2011-11-17 10:16             ` Alon Levy
2011-11-16 13:36     ` Anthony Liguori [this message]
2011-11-16 13:39       ` Dor Laor
2011-11-16 13:42         ` Anthony Liguori
2011-11-16 14:10           ` Ayal Baron
2011-11-16 14:20           ` Paolo Bonzini
2011-11-17  7:17             ` Itamar Heim
2011-11-17 14:31             ` Jamie Lokier
2011-11-16 13:45     ` Anthony Liguori
2011-11-15 19:09 ` Anthony Liguori
2011-11-15 23:01 ` Michael Roth
2011-11-16  0:42   ` Alexander Graf
2011-11-16  7:05     ` Barak Azulay
2011-11-16  8:16       ` Alexander Graf
2011-11-16 12:13         ` Barak Azulay
2011-11-16 15:28           ` Michael Roth
2011-11-16 17:53             ` Barak Azulay
2011-11-16 21:44               ` Michael Roth
2011-11-17  0:03               ` Anthony Liguori
2011-11-17  8:59                 ` Ayal Baron
2011-11-17 14:42                   ` Anthony Liguori
2011-11-16 10:18   ` Daniel P. Berrange
2011-11-16 20:24 ` Adam Litke
2011-11-17  2:09   ` Michael Roth
2011-11-17  8:46   ` Ayal Baron
2011-11-17 14:58     ` Michael Roth
2011-11-17 15:58     ` Adam Litke
2011-11-17 16:14       ` Daniel P. Berrange
2011-11-17 16:53         ` Eric Gaulin
2011-11-25 19:33         ` Barak Azulay
2011-11-17 17:09   ` Barak Azulay
2011-11-18  0:47     ` Luiz Capitulino
2011-11-17  0:48 ` [Qemu-devel] wiki summary Michael Roth
2011-11-17 16:34   ` Barak Azulay
2011-11-17 19:58     ` Michael Roth
2011-11-18 11:25       ` Barak Azulay
2011-11-18 14:10         ` Adam Litke
2011-11-18 14:21         ` Michael Roth
2011-11-24 12:40       ` Dor Laor
2011-11-24 16:47         ` Richard W.M. Jones
2011-11-25 10:07         ` Daniel P. Berrange
2011-11-27 12:19           ` Dor Laor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EC3BC67.6030005@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=abaron@redhat.com \
    --cc=arch@ovirt.org \
    --cc=bazulay@redhat.com \
    --cc=ghammer@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vdsm-devel@lists.fedorahosted.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).