Anthony Liguori anth...@codemonkey.ws 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
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
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 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 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 a C API.
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
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
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
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
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
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.
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 08:23 AM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 16:40:18 -0500
Anthony Liguorianth...@codemonkey.ws 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
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
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 many times
On Thu, 25 Mar 2010 08:57:36 -0500
Anthony Liguori anth...@codemonkey.ws 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
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
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 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 easily
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 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, once QMP
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
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
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
interactive user
Anthony Liguori anth...@codemonkey.ws 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
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
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. Why would a
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.
Would
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
enumeration. So the
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?
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
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 bindings
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
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
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 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/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: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
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'
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,
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
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
Paul Brook p...@codesourcery.com 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 p...@codesourcery.com 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
On Wed, 24 Mar 2010 12:42:16 +0200
Avi Kivity a...@redhat.com 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
On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 12:42:16 +0200
Avi Kivitya...@redhat.com 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
On Wed, 24 Mar 2010 21:49:45 +0200
Avi Kivity a...@redhat.com wrote:
On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 12:42:16 +0200
Avi Kivitya...@redhat.com wrote:
So, at best qemud is a toy for people who are annoyed by libvirt.
Is the reason for
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 Kivitya...@redhat.com wrote:
On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 12:42:16 +0200
Avi Kivitya...@redhat.com
On Wed, 24 Mar 2010 21:54:09 +0100
Alexander Graf ag...@suse.de 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 Kivitya...@redhat.com wrote:
On 03/24/2010 06:42 PM, Luiz Capitulino
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
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 a pretty
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 free
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 interface for
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 emulator to a wrapper script
and
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
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
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
emulator/root/bin/qemu-wrapper/emulator
[r...@xenb ~]# cat /root/bin/qemu-wrapper
Ah right thanks! However, it's a hack to get around the real problem
with
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
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 libvirt
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
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 more important
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
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
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)).
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 it's
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
available
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
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
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
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
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
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. There is no
72 matches
Mail list logo
