On 03/25/2010 10:18 AM, Alexander Graf wrote:
libqemu.so would be a C API. C is not the first choice for writing GUIs or
management applications. So it would need to be further wrapped.
We also need to allow qemu to control the display directly, without going
through vnc.
For the cu
On 03/26/2010 02:37 AM, Markus Armbruster wrote:
Adding to this C wrappers for QMP commands threatens to make QMP command
arguments part of the library ABI. Compatible QMP evolution (like
adding an optional argument) turns into a libqmp soname bump.
Counter-productive. How do you plan to avoid
On Thu, 25 Mar 2010 08:55:42 -0500
Anthony Liguori wrote:
> On 03/25/2010 08:23 AM, Luiz Capitulino wrote:
> > On Wed, 24 Mar 2010 16:40:18 -0500
> > Anthony Liguori wrote:
> >
> >
> We need to have a common management interface for third party tools.
>
>
> >>>QM
On 03/26/2010 04:51 AM, Avi Kivity wrote:
On 03/26/2010 10:37 AM, Markus Armbruster wrote:
The importances of libqemu is:
1) Providing a common QMP transport implementation that is extensible
by third parties
2) Providing a set of common transports that support automatic
discovery of command
On 03/26/2010 10:37 AM, Markus Armbruster wrote:
The importances of libqemu is:
1) Providing a common QMP transport implementation that is extensible
by third parties
2) Providing a set of common transports that support automatic
discovery of command line launched guests
3) Providing a generic
Anthony Liguori writes:
> On 03/25/2010 11:50 AM, Markus Armbruster wrote:
>>
>>> The point is, C is a lowest common denominator and it's important to
>>> support in a proper way.
>>>
>> No. The lowest truly common denominator is plain text. And we got that
>> covered already.
>>
>> A dev
Anthony Liguori wrote:
> I'm not sure. The human monitor has some features that are not
> appropriate for QMP. For instance, the ability to deal with formula
> input and some commands meant to add debugging.
>
> I guess you could do that in qemu-cmd but I don't see a compelling
> reason to.
Anthony Liguori wrote:
> On 03/25/2010 09:09 AM, Luiz Capitulino wrote:
> >
> >>We can provide a generic QMP dispatch interface that high level
> >>languages can use. Then they can do fancy dispatch, treat QErrors as
> >>exceptions, etc.
> >>
> > They can do that by accessing QMP directly. W
On 03/25/2010 11:50 AM, Markus Armbruster wrote:
The point is, C is a lowest common denominator and it's important to
support in a proper way.
No. The lowest truly common denominator is plain text. And we got that
covered already.
A developer encountered the problem of talking a simpl
Anthony Liguori writes:
> On 03/25/2010 07:37 AM, Avi Kivity wrote:
>> On 03/25/2010 02:33 PM, Anthony Liguori wrote:
From my point of view, i wouldn't want to write a high level
management toolstack in C, specially
since the API is well defined JSON which is easily available in
>>
Anthony Liguori wrote:
> On 03/25/2010 10:16 AM, Daniel P. Berrange wrote:
>> On Thu, Mar 25, 2010 at 03:14:24PM +, Vincent Hanquez wrote:
>>
>>> On Thu, Mar 25, 2010 at 03:07:20PM +, Daniel P. Berrange wrote:
>>>
I agree apps shouldn't use it for RPC, but admins using the
On 03/25/2010 10:16 AM, Daniel P. Berrange wrote:
On Thu, Mar 25, 2010 at 03:14:24PM +, Vincent Hanquez wrote:
On Thu, Mar 25, 2010 at 03:07:20PM +, Daniel P. Berrange wrote:
I agree apps shouldn't use it for RPC, but admins using the interactive user
monitor are just as deser
On 03/25/2010 09:09 AM, Luiz Capitulino wrote:
We can provide a generic QMP dispatch interface that high level
languages can use. Then they can do fancy dispatch, treat QErrors as
exceptions, etc.
They can do that by accessing QMP directly. Why would a Python developer
get in the mess
On Thu, Mar 25, 2010 at 03:14:24PM +, Vincent Hanquez wrote:
> On Thu, Mar 25, 2010 at 03:07:20PM +, Daniel P. Berrange wrote:
> > I agree apps shouldn't use it for RPC, but admins using the interactive
> > user
> > monitor are just as deserving of stable commands & args.
>
> I think, o
On Thu, Mar 25, 2010 at 03:07:20PM +, Daniel P. Berrange wrote:
> I agree apps shouldn't use it for RPC, but admins using the interactive user
> monitor are just as deserving of stable commands & args.
I think, once QMP is completely there, admins would be better using a qemu-cmd
that's just
On Thu, Mar 25, 2010 at 02:56:52PM +, Vincent Hanquez wrote:
> On Thu, Mar 25, 2010 at 01:59:22PM +, Daniel P. Berrange wrote:
> > > From my point of view, i wouldn't want to write a high level management
> > > toolstack in C, specially
> > > since the API is well defined JSON which is eas
On Thu, Mar 25, 2010 at 01:59:22PM +, Daniel P. Berrange wrote:
> > From my point of view, i wouldn't want to write a high level management
> > toolstack in C, specially
> > since the API is well defined JSON which is easily available in all high
> > level language out there.
>
> It was pret
On Thu, Mar 25, 2010 at 08:57:36AM -0500, Anthony Liguori wrote:
> Why?
>
> We can provide a generic QMP dispatch interface that high level
> languages can use. Then they can do fancy dispatch, treat QErrors as
> exceptions, etc.
Because more than likely it will be more efforts than doing the
On 03/25/2010 03:57 PM, Anthony Liguori wrote:
On 03/25/2010 08:48 AM, Avi Kivity wrote:
But an awful lot of the providers for pegasus are written in C.
But we're concerned with only one, the virt provider. None of the
others will use libqemu?
The point is, C is a lowest common denominato
On Thu, 25 Mar 2010 08:57:36 -0500
Anthony Liguori wrote:
> On 03/25/2010 08:48 AM, Avi Kivity wrote:
> >>
> >> But an awful lot of the providers for pegasus are written in C.
> >
> > But we're concerned with only one, the virt provider. None of the
> > others will use libqemu?
> >
> >> The poi
On Thu, Mar 25, 2010 at 08:26:09AM +, Vincent Hanquez wrote:
> On 24/03/10 21:40, Anthony Liguori wrote:
> >>If so, what C clients you expected beyond libvirt?
> >
> >Users want a C API. I don't agree that libvirt is the only C
> >interface consumer out there.
>
> (I've seen this written too
On 03/25/2010 08:48 AM, Avi Kivity wrote:
But an awful lot of the providers for pegasus are written in C.
But we're concerned with only one, the virt provider. None of the
others will use libqemu?
The point is, C is a lowest common denominator and it's important to
support in a proper way
On 03/25/2010 08:23 AM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 16:40:18 -0500
Anthony Liguori wrote:
We need to have a common management interface for third party tools.
QMP? :-)
Only if QMP is compatible with libvirt. I don't want a user to have to
choose betw
On 03/25/2010 03:44 PM, Anthony Liguori wrote:
On 03/25/2010 07:37 AM, Avi Kivity wrote:
On 03/25/2010 02:33 PM, Anthony Liguori wrote:
From my point of view, i wouldn't want to write a high level
management toolstack in C, specially
since the API is well defined JSON which is easily available
On 03/25/2010 07:37 AM, Avi Kivity wrote:
On 03/25/2010 02:33 PM, Anthony Liguori wrote:
From my point of view, i wouldn't want to write a high level
management toolstack in C, specially
since the API is well defined JSON which is easily available in all
high level language out there.
There'
Anthony Liguori wrote:
On 03/25/2010 03:26 AM, Vincent Hanquez wrote:
On 24/03/10 21:40, Anthony Liguori wrote:
If so, what C clients you expected beyond libvirt?
Users want a C API. I don't agree that libvirt is the only C
interface consumer out there.
(I've seen this written too many ti
On Wed, 24 Mar 2010 16:40:18 -0500
Anthony Liguori wrote:
> >> We need to have a common management interface for third party tools.
> >>
> > QMP? :-)
>
> Only if QMP is compatible with libvirt. I don't want a user to have to
> choose between QMP and libvirt.
Why not? If all they want
On 03/25/2010 02:33 PM, Anthony Liguori wrote:
From my point of view, i wouldn't want to write a high level
management toolstack in C, specially
since the API is well defined JSON which is easily available in all
high level language out there.
There's a whole world of C based management tools
On 03/25/2010 03:26 AM, Vincent Hanquez wrote:
On 24/03/10 21:40, Anthony Liguori wrote:
If so, what C clients you expected beyond libvirt?
Users want a C API. I don't agree that libvirt is the only C
interface consumer out there.
(I've seen this written too many times ...)
How do you know
On 03/25/2010 10:26 AM, Vincent Hanquez wrote:
On 24/03/10 21:40, Anthony Liguori wrote:
If so, what C clients you expected beyond libvirt?
Users want a C API. I don't agree that libvirt is the only C
interface consumer out there.
(I've seen this written too many times ...)
How do you know
On 24/03/10 21:40, Anthony Liguori wrote:
If so, what C clients you expected beyond libvirt?
Users want a C API. I don't agree that libvirt is the only C
interface consumer out there.
(I've seen this written too many times ...)
How do you know that ? did you do a poll or something where *ac
On 25.03.2010, at 07:37, Avi Kivity wrote:
> On 03/24/2010 10:32 PM, Anthony Liguori wrote:
>>
>> So far, a libqemu.so with a flexible transport that could be used directly
>> by a libvirt user (ala cairo/gdk type interactions) seems like the best
>> solution to me.
>
>
> libqemu.so would be
On 24.03.2010, at 22:33, Luiz Capitulino wrote:
> On Wed, 24 Mar 2010 21:54:09 +0100
> Alexander Graf wrote:
>
>>
>> On 24.03.2010, at 21:32, Anthony Liguori wrote:
>>
>>> On 03/24/2010 03:12 PM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 21:49:45 +0200
Avi Kivity wrote:
On 03/24/2010 10:32 PM, Anthony Liguori wrote:
So far, a libqemu.so with a flexible transport that could be used
directly by a libvirt user (ala cairo/gdk type interactions) seems
like the best solution to me.
libqemu.so would be a C API. C is not the first choice for writing GUIs
or mana
Anthony Liguori wrote:
> But the advantage is that if libvirt provided an API for a QMP transport
> encapsulated in their secure protocol, then provided the plumbed that
> API through their Python interface, you could use it for free in Python
> without having to reinvent the wheel.
It's not fr
Avi Kivity wrote:
> On 03/24/2010 02:32 PM, Anthony Liguori wrote:
> >>You don't get a directory filled with a zillion socket files pointing
> >>at dead guests. Agree that's a poor return on investment.
> >
> >
> >Deleting it on atexit combined with flushing the whole directory at
> >startup is
On 03/24/2010 04:25 PM, Luiz Capitulino wrote:
I see it as a related problem, because what seems to be under discussion
is the quality of our interfaces with humans and tools.
Also, when we were discussing the usuability problems I remember that
you
*WARNING: I might be wrong here, please
On Wed, 24 Mar 2010 21:54:09 +0100
Alexander Graf wrote:
>
> On 24.03.2010, at 21:32, Anthony Liguori wrote:
>
> > On 03/24/2010 03:12 PM, Luiz Capitulino wrote:
> >> On Wed, 24 Mar 2010 21:49:45 +0200
> >> Avi Kivity wrote:
> >>
> >>
> >>> On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
>
On Wed, 24 Mar 2010 15:32:42 -0500
Anthony Liguori wrote:
> On 03/24/2010 03:12 PM, Luiz Capitulino wrote:
> > On Wed, 24 Mar 2010 21:49:45 +0200
> > Avi Kivity wrote:
> >
> >
> >> On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
> >>
> >>> On Wed, 24 Mar 2010 12:42:16 +0200
> >>> Avi Ki
On 24.03.2010, at 21:32, Anthony Liguori wrote:
> On 03/24/2010 03:12 PM, Luiz Capitulino wrote:
>> On Wed, 24 Mar 2010 21:49:45 +0200
>> Avi Kivity wrote:
>>
>>
>>> On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
>>>
On Wed, 24 Mar 2010 12:42:16 +0200
Avi Kivity wrote:
On 03/24/2010 03:12 PM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 21:49:45 +0200
Avi Kivity wrote:
On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 12:42:16 +0200
Avi Kivity wrote:
So, at best qemud is a toy for people who are annoyed by libvirt.
On Wed, 24 Mar 2010 21:49:45 +0200
Avi Kivity wrote:
> On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
> > On Wed, 24 Mar 2010 12:42:16 +0200
> > Avi Kivity wrote:
> >
> >
> >> So, at best qemud is a toy for people who are annoyed by libvirt.
> >>
> > Is the reason for doing this in q
On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 12:42:16 +0200
Avi Kivity wrote:
So, at best qemud is a toy for people who are annoyed by libvirt.
Is the reason for doing this in qemu because libvirt is annoying?
Mostly.
I don't see
how adding yet another la
On Wed, 24 Mar 2010 12:42:16 +0200
Avi Kivity wrote:
> So, at best qemud is a toy for people who are annoyed by libvirt.
Is the reason for doing this in qemu because libvirt is annoying? I don't see
how adding yet another layer/daemon is going to improve ours and user's life
(the same applies f
> Paul Brook writes:
> >> > IMO the no_user flag is a bug, and should not exist.
> >>
> >> Sorry, what's that?
> >
> > Usually an indication that a device has been incorrectly or inproperly
> > converted to the qdev interface.
>
> Can also be an indication that the device can't support multiple
>
Paul Brook writes:
>> > IMO the no_user flag is a bug, and should not exist.
>>
>> Sorry, what's that?
>
> Usually an indication that a device has been incorrectly or inproperly
> converted to the qdev interface.
Can also be an indication that the device can't support multiple
instances. For
> > IMO the no_user flag is a bug, and should not exist.
>
> Sorry, what's that?
Usually an indication that a device has been incorrectly or inproperly
converted to the qdev interface.
Paul
On 03/24/2010 07:25 AM, Paul Brook wrote:
I can't quite see what such a libqemu would buy us compared to straight
QMP.
Talking QMP should be easy, provided you got a suitable JSON library.
I agree. My undesranding is this was one of the large motivations behind using
JSON: It's a common p
On 03/24/2010 02:23 PM, Anthony Liguori wrote:
On 03/24/2010 05:42 AM, Avi Kivity wrote:
The filtering access part of this daemon is also not mapping well onto
libvirt's access model, because we don't soley filter based on UID in
libvirtd. We have it configurable based on UID, policykit, SASL,
On 03/24/2010 02:30 PM, Paul Brook wrote:
On 03/23/2010 09:24 PM, Anthony Liguori wrote:
We also provide an API for guest creation (the qemu command line).
As an aside, I'd like to see all command line options have qmp
equivalents (most of them can be implemented with a 'set' comm
On 03/24/2010 07:27 AM, Avi Kivity wrote:
On 03/24/2010 02:19 PM, Anthony Liguori wrote:
qemud
- daemonaizes itself
- listens on /var/lib/qemud/guests for incoming guest connections
- listens on /var/lib/qemud/clients for incoming client connections
- filters access according to uid (SCM
> On 03/23/2010 09:24 PM, Anthony Liguori wrote:
> > We also provide an API for guest creation (the qemu command line).
>
> As an aside, I'd like to see all command line options have qmp
> equivalents (most of them can be implemented with a 'set' command that
> writes qdev values). This allows a
On 03/24/2010 07:29 AM, Avi Kivity wrote:
On 03/24/2010 02:23 PM, Anthony Liguori wrote:
On 03/24/2010 05:42 AM, Avi Kivity wrote:
The filtering access part of this daemon is also not mapping well onto
libvirt's access model, because we don't soley filter based on UID in
libvirtd. We have it
On 03/24/2010 02:32 PM, Anthony Liguori wrote:
You don't get a directory filled with a zillion socket files pointing
at dead guests. Agree that's a poor return on investment.
Deleting it on atexit combined with flushing the whole directory at
startup is a pretty reasonable solution to this (
On 03/24/2010 02:30 PM, Anthony Liguori wrote:
On 03/24/2010 07:27 AM, Avi Kivity wrote:
On 03/24/2010 02:19 PM, Anthony Liguori wrote:
qemud
- daemonaizes itself
- listens on /var/lib/qemud/guests for incoming guest connections
- listens on /var/lib/qemud/clients for incoming client conn
On 03/24/2010 02:19 PM, Anthony Liguori wrote:
qemud
- daemonaizes itself
- listens on /var/lib/qemud/guests for incoming guest connections
- listens on /var/lib/qemud/clients for incoming client connections
- filters access according to uid (SCM_CREDENTIALS)
- can pass a new monitor to
> I can't quite see what such a libqemu would buy us compared to straight
> QMP.
>
> Talking QMP should be easy, provided you got a suitable JSON library.
I agree. My undesranding is this was one of the large motivations behind using
JSON: It's a common protocol that already has convenient bindi
On 03/24/2010 05:42 AM, Avi Kivity wrote:
The filtering access part of this daemon is also not mapping well onto
libvirt's access model, because we don't soley filter based on UID in
libvirtd. We have it configurable based on UID, policykit, SASL,
TLS/x509
already, and intend adding role base
On 03/24/2010 12:17 AM, Avi Kivity wrote:
On 03/23/2010 08:00 PM, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest
enumeration. So the fundamental topic he
On 03/24/2010 12:36 PM, Daniel P. Berrange wrote:
On Wed, Mar 24, 2010 at 07:17:26AM +0200, Avi Kivity wrote:
On 03/23/2010 08:00 PM, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
I thought the monitor protocol *was* our API. If not, why not?
I
On Wed, Mar 24, 2010 at 07:17:26AM +0200, Avi Kivity wrote:
> On 03/23/2010 08:00 PM, Avi Kivity wrote:
> >On 03/23/2010 06:06 PM, Anthony Liguori wrote:
> >>>I thought the monitor protocol *was* our API. If not, why not?
> >>
> >>It is. But our API is missing key components like guest
> >>enumer
Anthony Liguori writes:
> On 03/23/2010 06:25 PM, Jamie Lokier wrote:
>> Alexander Graf wrote:
>>
>>> I don't see why we shouldn't be able to automatically generate
>>> libqemu.so. We have the *.hx files that describe the syntax of
>>> parameters plus list all available options / commands. I'
On 03/23/2010 09:24 PM, Anthony Liguori wrote:
We also provide an API for guest creation (the qemu command line).
As an aside, I'd like to see all command line options have qmp
equivalents (most of them can be implemented with a 'set' command that
writes qdev values). This allows a uniform
On 03/23/2010 08:00 PM, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest
enumeration. So the fundamental topic here is, do we introduce these
missing compo
On 03/23/2010 06:25 PM, Jamie Lokier wrote:
Alexander Graf wrote:
I don't see why we shouldn't be able to automatically generate
libqemu.so. We have the *.hx files that describe the syntax of
parameters plus list all available options / commands. I'm not sure
how exactly QMP works, but havin
Alexander Graf wrote:
> I don't see why we shouldn't be able to automatically generate
> libqemu.so. We have the *.hx files that describe the syntax of
> parameters plus list all available options / commands. I'm not sure
> how exactly QMP works, but having a generic QMP command to list all
> avail
Anthony Liguori wrote:
> On 03/23/2010 10:57 AM, Paul Brook wrote:
> >I thought the monitor protocol *was* our API. If not, why not?
>
> It is. But our API is missing key components like guest enumeration.
Is that simply enumerating running qemu instances, and asking each one
about things like i
Anthony Liguori wrote:
> (like mDNS or SLP). The later mechanism scales better and tends to
> be more robust.
(Aside: mDNS is blocked on some larger networks because it creates too
much load. On those networks, an aggregator is essential - or a
protocol which scales better (less broadcasting)).
On 03/23/2010 01:07 PM, Daniel P. Berrange wrote:
On Tue, Mar 23, 2010 at 11:06:20AM -0500, Anthony Liguori wrote:
On 03/23/2010 10:57 AM, Paul Brook wrote:
I think there is a serious divergence of approach there, instanciating
API stating 'we are gonna deprecate them sooner or later'
On 03/23/2010 01:00 PM, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest
enumeration. So the fundamental topic here is, do we introduce these
missing compo
On Tue, Mar 23, 2010 at 11:06:20AM -0500, Anthony Liguori wrote:
> On 03/23/2010 10:57 AM, Paul Brook wrote:
> >>>I think there is a serious divergence of approach there, instanciating
> >>>API stating 'we are gonna deprecate them sooner or later' tell the
> >>>application developper 'my time is mo
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest enumeration.
So the fundamental topic here is, do we introduce these missing
components to allow people to build directly to
> > I think there is a serious divergence of approach there, instanciating
> > API stating 'we are gonna deprecate them sooner or later' tell the
> > application developper 'my time is more important than yours' and not
> > really something I like to carry to the API users.
> > The main goal of lib
On 03/23/2010 10:57 AM, Paul Brook wrote:
I think there is a serious divergence of approach there, instanciating
API stating 'we are gonna deprecate them sooner or later' tell the
application developper 'my time is more important than yours' and not
really something I like to carry to the API use
On 03/23/10 11:31, Jes Sorensen wrote:
On 03/23/10 11:25, Gerd Hoffmann wrote:
[r...@xenb ~]# virsh dumpxml fedora | grep emulator
/root/bin/qemu-wrapper
[r...@xenb ~]# cat /root/bin/qemu-wrapper
Ah right thanks! However, it's a hack to get around the real problem
with libvirt.
Sure. It is
On 03/23/10 11:25, Gerd Hoffmann wrote:
On 03/23/10 09:54, Jes Sorensen wrote:
One problem I have found, and I am not sure how to fix this in this
context. Sometimes when hacking on qemu, I want to try out a new
qemu binary on an existing image, without replacing the system wide
one and may want
On 03/23/10 09:54, Jes Sorensen wrote:
On 03/22/10 22:53, Anthony Liguori wrote:
On 03/22/2010 04:33 PM, Gerd Hoffmann wrote:
libvirt is very unfriendly to qemu hackers. There is no easy way to
add command line switches. There is no easy way to get access to the
monitor. I can get it done by po
On 03/22/10 22:53, Anthony Liguori wrote:
On 03/22/2010 04:33 PM, Gerd Hoffmann wrote:
libvirt is very unfriendly to qemu hackers. There is no easy way to
add command line switches. There is no easy way to get access to the
monitor. I can get it done by pointing to a wrapper script
and mangle t
On 22.03.2010, at 22:49, Anthony Liguori wrote:
> On 03/22/2010 03:10 PM, Daniel P. Berrange wrote:
>>
>>
>>> What's the feeling about this from the libvirt side of things? Is there
>>> interest in support hypervisor specific interfaces should we be looking
>>> to provide our own management
On 03/22/2010 05:33 PM, Gerd Hoffmann wrote:
> Hi,
>
>> Stepping back a bit first, there are the two core areas in which
>> people can
>> be limited by libvirt currently.
>
>> 2. Command line flags
>
> For me: This one, and monitor access.
>
> libvirt is very unfriendly to qemu hackers. T
On 03/22/2010 04:33 PM, Gerd Hoffmann wrote:
Hi,
Stepping back a bit first, there are the two core areas in which
people can
be limited by libvirt currently.
2. Command line flags
For me: This one, and monitor access.
libvirt is very unfriendly to qemu hackers. There is no easy way
Hi,
Stepping back a bit first, there are the two core areas in which people can
be limited by libvirt currently.
2. Command line flags
For me: This one, and monitor access.
libvirt is very unfriendly to qemu hackers. There is no easy way to add
command line switches. There is no ea
82 matches
Mail list logo
