<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
forwarding and added to subscription list.<br>
<br>
Carl.<br>
<br>
<br>
On 11/17/2011 09:43 AM, <a class="moz-txt-link-abbreviated" href="mailto:arch-bounces@ovirt.org">arch-bounces@ovirt.org</a> wrote:
<blockquote cite="mid:mailman.168.1321540984.1875.arch@ovirt.org"
type="cite">
<fieldset class="mimeAttachmentHeader"><legend
class="mimeAttachmentHeaderName">Re: [Qemu-devel] converging
around a single guest agent.eml</legend></fieldset>
<table class="header-part1" border="0" cellpadding="0"
cellspacing="0" width="100%">
<tbody>
<tr>
<td>
<div class="headerdisplayname" style="display:inline;">Subject:
</div>
Re: [Qemu-devel] converging around a single guest agent</td>
</tr>
<tr>
<td>
<div class="headerdisplayname" style="display:inline;">From:
</div>
Anthony Liguori <a class="moz-txt-link-rfc2396E" href="mailto:anthony@codemonkey.ws"><anthony@codemonkey.ws></a></td>
</tr>
<tr>
<td>
<div class="headerdisplayname" style="display:inline;">Date:
</div>
11/17/2011 09:42 AM</td>
</tr>
</tbody>
</table>
<table class="header-part2" border="0" cellpadding="0"
cellspacing="0" width="100%">
<tbody>
<tr>
<td>
<div class="headerdisplayname" style="display:inline;">To:
</div>
Ayal Baron <a class="moz-txt-link-rfc2396E" href="mailto:abaron@redhat.com"><abaron@redhat.com></a></td>
</tr>
<tr>
<td>
<div class="headerdisplayname" style="display:inline;">CC:
</div>
Barak Azulay <a class="moz-txt-link-rfc2396E" href="mailto:bazulay@redhat.com"><bazulay@redhat.com></a>, Michael Roth
<a class="moz-txt-link-rfc2396E" href="mailto:mdroth@linux.vnet.ibm.com"><mdroth@linux.vnet.ibm.com></a>, Gal Hammer
<a class="moz-txt-link-rfc2396E" href="mailto:ghammer@redhat.com"><ghammer@redhat.com></a>,
<a class="moz-txt-link-abbreviated" href="mailto:vdsm-devel@lists.fedorahosted.org">vdsm-devel@lists.fedorahosted.org</a>, <a class="moz-txt-link-abbreviated" href="mailto:qemu-devel@nongnu.org">qemu-devel@nongnu.org</a>,
<a class="moz-txt-link-abbreviated" href="mailto:arch@ovirt.org">arch@ovirt.org</a></td>
</tr>
</tbody>
</table>
<br>
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 12px;" lang="x-unicode">On 11/17/2011 02:59 AM, Ayal
Baron wrote:
<br>
<blockquote type="cite" style="color: #000000;">
<br>
<br>
----- Original Message -----
<br>
<blockquote type="cite" style="color: #000000;">On 11/16/2011
11:53 AM, Barak Azulay wrote:
<br>
<blockquote type="cite" style="color: #000000;">On Wednesday
16 November 2011 17:28:16 Michael Roth wrote:
<br>
<blockquote type="cite" style="color: #000000;">2) You'd
also need a schema, similar to
<br>
qemu.git/qapi-schema-guest.json,
<br>
to describe the calls you're proxying. The existing
infrastructure
<br>
in
<br>
QEMU will handle all the work of
marshalling/unmarshalling
<br>
responses
<br>
back to the QMP client on the host-side.
<br>
<br>
It's a bit of extra work, but the benefit is unifying
the
<br>
qemu/guest-level management interface into a single
place that's
<br>
easy
<br>
for QMP/libvirt to consume.
<br>
<br>
</blockquote>
<br>
The issue is not whether it's possible or not or the
amount of
<br>
efforts need to
<br>
be done for that to happen, either for qemu-ga or
ovirt-guest-agent
<br>
this work
<br>
needs to be done.
<br>
<br>
the question is whether all comminication should go
through the
<br>
monitor (hence
<br>
double proxy) or ... only a subset of the commands that
are closly
<br>
related to
<br>
hypervisor functionality and separate it from general
<br>
management-system
<br>
related actions (e.g. ovirt or any other management system
that
<br>
wants to
<br>
communicate to the guest).
<br>
</blockquote>
<br>
Yes, all guest interaction should be funnelled through
QEMU. QEMU
<br>
has one job
<br>
in life--to expose an interface to guests and turn it into
something
<br>
more useful
<br>
to the host. QEMU expose an emulated AHCI controller and
turns that
<br>
into VFS
<br>
operations.
<br>
<br>
Likewise, QEMU should expose a paravirtual "agent" device to
a guest,
<br>
and then
<br>
turn that into higher level management interfaces.
<br>
</blockquote>
<br>
Exposing higher level management interfaces means that qemu
would have to do policy.
<br>
</blockquote>
<br>
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.
<br>
<br>
(1) let's us validate that guest state isn't escaping which
keeps migration safe
<br>
<br>
(2) let's us scrub any potentially malicious input from the
guest before we hand it off to the management tool.
<br>
<br>
Otherwise, we don't get in the middle and don't really care what
the verbs are.
<br>
<br>
<blockquote type="cite" style="color: #000000;">
<blockquote type="cite" style="color: #000000;">
<br>
QEMU's job is to sanitize information from the guest and try
to turn
<br>
that into
<br>
something that is safer for the broader world to consume.
QEMU also
<br>
deals with
<br>
isolating state in order to support things like live
migration. This
<br>
</blockquote>
<br>
So are you suggesting that when a user reads a file you would
automatically encode the contents?
<br>
</blockquote>
<br>
I'm not sure I understand what you're suggesting.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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).
<br>
<br>
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.
<br>
<br>
Regards,
<br>
<br>
Anthony Liguori
</div>
</blockquote>
<br>
</body>
</html>