[libvirt-users] Programmatically force shutdown a guest: possible?

[Eric Blake]

On 03/30/2014 02:47 AM, Pasquale Dir wrote:
> Yes, you are right.

[please don't top-post on technical lists]

> Listen, as the documentation is not very exaustive, can you explain briefly
> to me how a guest agent works?

There's two essential pieces - while you can add the pieces in either
order, both must be present before you have a guest agent channel.

1. You must expose the guest agent hardware to the guest.  In libvirt,
this is done with the <channel> device:
http://libvirt.org/formatdomain.html#elementCharChannel
(look at the org.qemu.guest_agent.0 example)
Newer virt-manager has some gui elements for making this a bit easier to
set up.

2. You must install the guest agent in the guest, set to run as a
daemon.  If the agent detects the hardware exposed by step 1, then you
have set up a communication channel between host and guest, where the
guest can react to host commands.

The idea is that the host issues one of the limited set of commands
understood by the agent protocol (the current list of commands
understood in qemu.git is here:
http://git.qemu.org/?p=qemu.git;a=blob;f=qga/qapi-schema.json;h=80edca14;hb=HEAD).
 Libvirt has the 'virsh qemu-agent-command' for issuing any command not
already directly utilized by formal libvirt API.  The agent then
receives that command over the virtual channel hardware, and does the
semantics of the command.  The agent has been ported at least to Linux
and Windows guests.  If there is an action you want the guest to do that
is not covered by those commands, then patches to the qemu list can be
proposed to expand the set.

> After installing it via the apt-get on the hypervisor (I am using ubuntu as
> host system) how can I create a script which would do this?

For piece 2, you would use apt-get on your guest (not your host).  The
only thing you do on the host is step 1 (xml modification to add the
device, if it isn't already present; newer virt-manager will add the xml
automatically).

> That is waiting for an acpi signal and actually shut down the guest.

I'm not sure I followed this statement.  The idea is that the 'virsh
shutdown' command knows two separate approaches to request guest
shutdown: one is by ACPI, the other by the agent.  If the agent is wired
up, then that way is preferred; but if it is not wired up, or if it is
wired up but unresponsive (for example, if the agent is not actually
running because you forgot step 2 in the guest), then libvirt falls back
to ACPI (unless you told libvirt to specifically use only 1 of the two
possible shutdown methods).

> 
> And what other operation can you actually do with a guest agent? I would be
> interested in getting the current amount of memory the guest is using
> too...as libvirt apis just tell me the max memory allocated.

See the link I posted above for the current set of agent commands.
Unfortunately, I don't see an existing command that reports the guest's
view of memory usage.

On the other hand, I do know that newer qemu has the ability to get
information about guest memory usage when doing balloon commands (in
fact, older qemu also had that ability, except that the older way
REQUIRED the guest to cooperate, and that could lead to host deadlock
for non-cooperative guests, so it was withdrawn at the time; it was only
recently re-enabled when newer qemu made the interaction more of a
status poll instead of a lockstep query-response).  If your qemu is new
enough, then libvirt's virDomainSetMemoryStatsPeriod() can control how
frequently you poll, and virDomainMemoryStats() can actually provide
details about the guest's view of memory usage according to what the
guest reported via the balloon driver.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20140331/d8b59afe/attachment.sig>