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. This
So 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
