|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] converging around a single guest agent |
Date: | Thu, 17 Nov 2011 08:42:59 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 |
On 11/17/2011 02:59 AM, Ayal Baron wrote:
----- Original Message -----On 11/16/2011 11:53 AM, Barak Azulay wrote:On Wednesday 16 November 2011 17:28:16 Michael Roth wrote:2) You'd also need a schema, similar to qemu.git/qapi-schema-guest.json, to describe the calls you're proxying. The existing infrastructure in QEMU will handle all the work of marshalling/unmarshalling responses back to the QMP client on the host-side. It's a bit of extra work, but the benefit is unifying the qemu/guest-level management interface into a single place that's easy for QMP/libvirt to consume.The issue is not whether it's possible or not or the amount of efforts need to be done for that to happen, either for qemu-ga or ovirt-guest-agent this work needs to be done. the question is whether all comminication should go through the monitor (hence double proxy) or ... only a subset of the commands that are closly related to hypervisor functionality and separate it from general management-system related actions (e.g. ovirt or any other management system that wants to communicate to the guest).Yes, all guest interaction should be funnelled through QEMU. QEMU has one job in life--to expose an interface to guests and turn it into something more useful to the host. QEMU expose an emulated AHCI controller and turns that into VFS operations. Likewise, QEMU should expose a paravirtual "agent" device to a guest, and then turn that into higher level management interfaces.Exposing higher level management interfaces means that qemu would have to do policy.
No, the way we plan on doing this is having a guest agent schema (qapi-schema-guest.json) that we can use to (1) white list valid operations and (2) decode and re-encode operations.
(1) let's us validate that guest state isn't escaping which keeps migration safe(2) let's us scrub any potentially malicious input from the guest before we hand it off to the management tool.
Otherwise, we don't get in the middle and don't really care what the verbs are.
QEMU's job is to sanitize information from the guest and try to turn that into something that is safer for the broader world to consume. QEMU also deals with isolating state in order to support things like live migration. ThisSo are you suggesting that when a user reads a file you would automatically encode the contents?
I'm not sure I understand what you're suggesting.Here's another way to think of this. In a typical enterprise environment, you would secure your network infrastructure using isolated zones. You may have a red zone (guest networking), a yellow zone (management network), and a green zone (broader intranet). The zones are physically separate with very few things that exist on two zones.
You pay special attention to anything that crosses zones and try to minimize them as much as possible. You never allow something to live on more than two zones.
The guest is the red zone and the rest of the host environment is the yellow zone. QEMU bridges between the red and yellow zone. That is fundamentally its job in the stack.
Other than the guest agent, VDSM lives purely in the yellow zone. In fact, VDSM bridges from the yellow zone to the green zone (broader management infrastructure).
It may be easier to skip QEMU and have VDSM also stride into the red zone. It's always easier to cross zones. But it's not good security practice. There is tremendous value in having clean security layers.
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |