On 04/26/2010 05:48 PM, Anthony Liguori wrote:
We could easily reuse that. Any other security context code would
be custom written; so it can be written as a qemud plugin instead of
a bit of code that goes before a qemu launch.
I think we're mostly in agreement with respect to the need to
On 04/26/2010 09:38 AM, Avi Kivity wrote:
On 04/26/2010 05:28 PM, Anthony Liguori wrote:
Or a library that the user-written launcher calls. Or a plugin that
qemud calls.
A plugin would lose the security context. It could attempt to
recreate it that seems like a lot of unnecessary complexit
On 04/26/2010 05:28 PM, Anthony Liguori wrote:
Or a library that the user-written launcher calls. Or a plugin that
qemud calls.
A plugin would lose the security context. It could attempt to
recreate it that seems like a lot of unnecessary complexity.
A plugin would create the security c
On Mon, Apr 26, 2010 at 09:26:55AM -0500, Anthony Liguori wrote:
> On 04/26/2010 08:58 AM, Daniel P. Berrange wrote:
> >On Mon, Apr 26, 2010 at 08:46:46AM -0500, Anthony Liguori wrote:
> >
> >>On 04/26/2010 08:41 AM, Avi Kivity wrote:
> >>
> >>
> (3) The system management application ca
On 04/26/2010 09:25 AM, Avi Kivity wrote:
On 04/26/2010 05:19 PM, Anthony Liguori wrote:
On 04/26/2010 09:01 AM, Avi Kivity wrote:
On 04/26/2010 04:43 PM, Anthony Liguori wrote:
The reason I lean toward the direct launch model is that it gives
the user a lot of flexibility in terms of using th
On 04/26/2010 08:58 AM, Daniel P. Berrange wrote:
On Mon, Apr 26, 2010 at 08:46:46AM -0500, Anthony Liguori wrote:
On 04/26/2010 08:41 AM, Avi Kivity wrote:
(3) The system management application can certainly create whatever
context it wants to launch a vm from. It's comes down to w
On 04/26/2010 05:19 PM, Anthony Liguori wrote:
On 04/26/2010 09:01 AM, Avi Kivity wrote:
On 04/26/2010 04:43 PM, Anthony Liguori wrote:
The reason I lean toward the direct launch model is that it gives
the user a lot of flexibility in terms of using things like
namespaces, DAC, cgroups, capabi
On 04/26/2010 09:01 AM, Avi Kivity wrote:
On 04/26/2010 04:43 PM, Anthony Liguori wrote:
The reason I lean toward the direct launch model is that it gives the
user a lot of flexibility in terms of using things like namespaces,
DAC, cgroups, capabilities, etc. A lot of potential features are
l
On 04/26/2010 04:43 PM, Anthony Liguori wrote:
The reason I lean toward the direct launch model is that it gives the
user a lot of flexibility in terms of using things like namespaces,
DAC, cgroups, capabilities, etc. A lot of potential features are lost
when you do indirect launch because you
On Mon, Apr 26, 2010 at 08:46:46AM -0500, Anthony Liguori wrote:
> On 04/26/2010 08:41 AM, Avi Kivity wrote:
>
> >>(3) The system management application can certainly create whatever
> >>context it wants to launch a vm from. It's comes down to who's
> >>responsible for creating the context the
On 04/26/2010 04:46 PM, Anthony Liguori wrote:
(3) The system management application can certainly create whatever
context it wants to launch a vm from. It's comes down to who's
responsible for creating the context the guest runs under. I think
doing that at the libvirt level takes away a ton
On 04/26/2010 08:41 AM, Avi Kivity wrote:
Today, you have to make changes to libvirt whereas in a direct launch
model, you get all of the neat security features linux supports for
free.
But you lose tap networking, unless you have a privileged helper. And
how is the privileged helper to auth
On 04/26/2010 08:31 AM, Daniel P. Berrange wrote:
What you describe is not inherant to the daemon model. This is why we have
two separate models in libvirt. The system instance is pre-spawned with
high privileges, to allow use of hosts resources which require high
privileges to access. The sessio
On 04/26/2010 04:14 PM, Anthony Liguori wrote:
IOW, libvirt does not run guests as separate users which is why it
needs to deal with security in the first place.
What if one user has multiple guests? isolation is still needed.
Don't confuse a management application's concept of users with
On Mon, Apr 26, 2010 at 08:13:03AM -0500, Anthony Liguori wrote:
> On 04/26/2010 04:59 AM, Daniel P. Berrange wrote:
> >On Sun, Apr 25, 2010 at 08:53:17PM -0500, Anthony Liguori wrote:
> >
> >>On 04/25/2010 06:51 AM, Avi Kivity wrote:
> >>
> >>> Qemu is special due to the nonexistence of q
On 04/26/2010 12:56 AM, Avi Kivity wrote:
On 04/26/2010 04:53 AM, Anthony Liguori wrote:
On 04/25/2010 06:51 AM, Avi Kivity wrote:
It depends on what things you think are important. A lot of
libvirt's complexity is based on the fact that it uses a daemon and
needs to deal with the security im
On 04/25/2010 09:50 AM, Avi Kivity wrote:
On 04/23/2010 09:33 PM, Anthony Liguori wrote:
This is a different ambiguity, about the semantic results of the
commands,
where as I'm refering to the execution order. If I look at a libvirt
log
file and see a set of JSON commands logged, I want to know
On 04/26/2010 04:59 AM, Daniel P. Berrange wrote:
On Sun, Apr 25, 2010 at 08:53:17PM -0500, Anthony Liguori wrote:
On 04/25/2010 06:51 AM, Avi Kivity wrote:
Qemu is special due to the nonexistence of qemud.
Why is sVirt implemented in libvirt? it's not the logical place for
it; ra
On Sun, Apr 25, 2010 at 08:53:17PM -0500, Anthony Liguori wrote:
> On 04/25/2010 06:51 AM, Avi Kivity wrote:
> > Qemu is special due to the nonexistence of qemud.
> >
> >Why is sVirt implemented in libvirt? it's not the logical place for
> >it; rather the logical place doesn't exist.
>
> sVirt
On 04/26/2010 04:53 AM, Anthony Liguori wrote:
On 04/25/2010 06:51 AM, Avi Kivity wrote:
It depends on what things you think are important. A lot of
libvirt's complexity is based on the fact that it uses a daemon and
needs to deal with the security implications of that. You don't
need explic
On 04/25/2010 06:51 AM, Avi Kivity wrote:
It depends on what things you think are important. A lot of
libvirt's complexity is based on the fact that it uses a daemon and
needs to deal with the security implications of that. You don't need
explicit labelling if you don't use a daemon.
I do
On 04/23/2010 09:33 PM, Anthony Liguori wrote:
This is a different ambiguity, about the semantic results of the
commands,
where as I'm refering to the execution order. If I look at a libvirt log
file and see a set of JSON commands logged, I want to know that this
ordering
from the logs, was ind
On 04/25/2010 06:39 AM, Anthony Liguori wrote:
On 04/24/2010 04:46 AM, Avi Kivity wrote:
On 04/23/2010 09:29 PM, Anthony Liguori wrote:
Maybe. We'll still have issues. For example, sVirt: if a QMP
command names a labeled resource, the non-libvirt user will have no
way of knowing how to label
On 04/24/2010 04:46 AM, Avi Kivity wrote:
On 04/23/2010 09:29 PM, Anthony Liguori wrote:
Maybe. We'll still have issues. For example, sVirt: if a QMP
command names a labeled resource, the non-libvirt user will have no
way of knowing how to label it.
This is orthogonal to QMP and has to do
On 04/23/2010 09:29 PM, Anthony Liguori wrote:
Maybe. We'll still have issues. For example, sVirt: if a QMP
command names a labeled resource, the non-libvirt user will have no
way of knowing how to label it.
This is orthogonal to QMP and has to do strictly with how libvirt
prepares a resou
On 04/23/2010 09:21 AM, Daniel P. Berrange wrote:
Say libvirt is running a 'offline core dump' operation. This consists of
us invoking
stop
migrate exec:cat> foo.dump
cont
I don't want other debug commands accidentally being issued in between
these steps. These 3 commands are in e
On 04/23/2010 09:24 AM, Avi Kivity wrote:
On 04/23/2010 04:48 PM, Anthony Liguori wrote:
On 04/23/2010 07:48 AM, Avi Kivity wrote:
On 04/22/2010 09:49 PM, Anthony Liguori wrote:
real API. Say, adding a device libvirt doesn't know about or
stopping the VM
while libvirt thinks it's still runnin
Anthony Liguori writes:
> On 04/23/2010 07:48 AM, Avi Kivity wrote:
>> On 04/22/2010 09:49 PM, Anthony Liguori wrote:
real API. Say, adding a device libvirt doesn't know about or
stopping the VM
while libvirt thinks it's still running or anything like that.
>>> Another problem is
On Fri, Apr 23, 2010 at 08:48:51AM -0500, Anthony Liguori wrote:
> On 04/23/2010 07:48 AM, Avi Kivity wrote:
> >On 04/22/2010 09:49 PM, Anthony Liguori wrote:
> >>>real API. Say, adding a device libvirt doesn't know about or
> >>>stopping the VM
> >>>while libvirt thinks it's still running or anyt
On 04/23/2010 04:48 PM, Anthony Liguori wrote:
On 04/23/2010 07:48 AM, Avi Kivity wrote:
On 04/22/2010 09:49 PM, Anthony Liguori wrote:
real API. Say, adding a device libvirt doesn't know about or
stopping the VM
while libvirt thinks it's still running or anything like that.
Another problem
On Fri, Apr 23, 2010 at 08:40:49AM -0500, Anthony Liguori wrote:
> On 04/23/2010 05:28 AM, Daniel P. Berrange wrote:
> >On Thu, Apr 22, 2010 at 01:45:27PM -0500, Anthony Liguori wrote:
> >
> >>On 04/09/2010 09:27 AM, Daniel P. Berrange wrote:
> >>
> >>>On Fri, Apr 09, 2010 at 09:41:39AM -04
On 04/23/2010 07:48 AM, Avi Kivity wrote:
On 04/22/2010 09:49 PM, Anthony Liguori wrote:
real API. Say, adding a device libvirt doesn't know about or
stopping the VM
while libvirt thinks it's still running or anything like that.
Another problem is issuing Monitor commands that could confuse
On 04/23/2010 05:28 AM, Daniel P. Berrange wrote:
On Thu, Apr 22, 2010 at 01:45:27PM -0500, Anthony Liguori wrote:
On 04/09/2010 09:27 AM, Daniel P. Berrange wrote:
On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote:
myguest
...
q
On 04/22/2010 09:49 PM, Anthony Liguori wrote:
real API. Say, adding a device libvirt doesn't know about or stopping
the VM
while libvirt thinks it's still running or anything like that.
Another problem is issuing Monitor commands that could confuse
libvirt's
We need to make libvirt and qem
On Thu, Apr 22, 2010 at 01:45:27PM -0500, Anthony Liguori wrote:
> On 04/09/2010 09:27 AM, Daniel P. Berrange wrote:
> >On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote:
> >
> >
> >>
> >> myguest
> >> ...
> >>
> >>
> >>
> >> qemu arguments
> >>
> >>
On 04/22/2010 01:45 PM, Anthony Liguori wrote:
Which in turn, could be embedded as:
myguest
...
Operon_G3
5
AuthenticAMD
With respect to injecting QMP commands directly, I think the proposed
debug API is probably reasonable. We could build a libqemu that used
that API as a transport w
On 04/12/2010 10:20 AM, Luiz Capitulino wrote:
On Fri, 9 Apr 2010 15:27:17 +0100
"Daniel P. Berrange" wrote:
On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote:
Hello,
In response to a lot of the talk of qemud lately on qemu-devel, the
libvirt community would lik
On 04/09/2010 09:27 AM, Daniel P. Berrange wrote:
On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote:
Hello,
In response to a lot of the talk of qemud lately on qemu-devel, the
libvirt community would like to put forward a proposal to help enable
debug/advanced options wh
On Fri, 9 Apr 2010 15:27:17 +0100
"Daniel P. Berrange" wrote:
> On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote:
> > Hello,
> > In response to a lot of the talk of qemud lately on qemu-devel, the
> > libvirt community would like to put forward a proposal to help enable
> > d
On Mon, Apr 12, 2010 at 09:56:50AM -0400, Chris Lalancette wrote:
> On 04/12/2010 08:41 AM, Daniel P. Berrange wrote:
> >>> I don't think there's much to be gained from having an XML element to
> >>> turn on/off use of these APIs. If an app doesn't want to use them, it
> >>> can simply not link to
On 04/12/2010 08:41 AM, Daniel P. Berrange wrote:
>>> I don't think there's much to be gained from having an XML element to
>>> turn on/off use of these APIs. If an app doesn't want to use them, it
>>> can simply not link to libvirt-qemu.so
>>
>> The reason I wanted to do this was mostly for debug/
On Sun, Apr 11, 2010 at 11:17:38PM +0100, Jamie Lokier wrote:
> Richard W.M. Jones wrote:
> > On Fri, Apr 09, 2010 at 10:06:51PM +0100, Jamie Lokier wrote:
> > > Daniel P. Berrange wrote:
> > > > I think this alteration of existing args is fr too complex &
> > > > fragile,
> > > > and way over
On Fri, Apr 09, 2010 at 02:16:06PM -0400, Chris Lalancette wrote:
> On 04/09/2010 10:27 AM, Daniel P. Berrange wrote:
> >> Raw access to the qemu monitor will be disabled by default; the
> >> tag enables the ability to send QMP (or
> >> text, if you are using older qemu) messages straight through
Richard W.M. Jones wrote:
> On Fri, Apr 09, 2010 at 10:06:51PM +0100, Jamie Lokier wrote:
> > Daniel P. Berrange wrote:
> > > I think this alteration of existing args is fr too complex & fragile,
> > > and way overkill.
> >
> > Would it not be simpler, for the target audience, for the config t
On Fri, Apr 09, 2010 at 10:06:51PM +0100, Jamie Lokier wrote:
> Daniel P. Berrange wrote:
> > I think this alteration of existing args is fr too complex & fragile,
> > and way overkill.
>
> Would it not be simpler, for the target audience, for the config to
> contain a one-line shell script to
On 04/09/2010 07:41 AM, Chris Lalancette wrote:
> Caveats:
> 3) Application developers will be strongly discouraged from using
> this API because of the above 2 issues. To help in this, the
> API's will be in a separate library that developers will explicitly
> have to link to, and it will have a
Daniel P. Berrange wrote:
> I think this alteration of existing args is fr too complex & fragile,
> and way overkill.
Would it not be simpler, for the target audience, for the config to
contain a one-line shell script to transform particular matched
arguments in any way that's wanted?
> If th
On 04/09/2010 10:27 AM, Daniel P. Berrange wrote:
> The concept of command line & monitor is something that is QEMU specific
> and thus is not suitable for the primary XML schema. IMHO, this needs to be
> done as a separate schema, linked in via an XML namespace. For example
>
> http://libvirt.o
On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote:
> Hello,
> In response to a lot of the talk of qemud lately on qemu-devel, the
> libvirt community would like to put forward a proposal to help enable
> debug/advanced options when using various hypervisors. The goals of
> this
49 matches
Mail list logo
