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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
