9:19 a.m.
Hi all,
In order to nicely support domains that use qemu's SDL support,
libvirt-cim is looking for a way to confirm if the underlying qemu
emulator can support SDL. Libvirt already knows this information
internally. It seems to me that the best way to provide this
information is by reporting it as a guest feature via the capabilities
API call. I was thinking the node '/capabilities/guest/features/sdl'
could be added when qemu supports SDL.
Is this a good idea?
--
Adam Litke
IBM Linux Technology Center
10:14 a.m.
On Fri, Jul 08, 2011 at 09:19:46AM -0500, Adam Litke wrote:
Hi all,
In order to nicely support domains that use qemu's SDL support,
libvirt-cim is looking for a way to confirm if the underlying qemu
emulator can support SDL. Libvirt already knows this information
internally. It seems to me that the best way to provide this
information is by reporting it as a guest feature via the capabilities
API call. I was thinking the node '/capabilities/guest/features/sdl'
could be added when qemu supports SDL.
Is this a good idea?
Seems like clearly a good idea to me. (Although I don't have
to code it :-)
Would it be worth having a separate <graphics> element underneath
features, so the path would be /capabilities/guest/features/graphics/sdl ?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
10:56 a.m.
On 07/08/2011 10:14 AM, Richard W.M. Jones wrote:
On Fri, Jul 08, 2011 at 09:19:46AM -0500, Adam Litke wrote:
> Hi all,
>
> In order to nicely support domains that use qemu's SDL support,
> libvirt-cim is looking for a way to confirm if the underlying qemu
> emulator can support SDL. Libvirt already knows this information
> internally. It seems to me that the best way to provide this
> information is by reporting it as a guest feature via the capabilities
> API call. I was thinking the node '/capabilities/guest/features/sdl'
> could be added when qemu supports SDL.
>
> Is this a good idea?
Seems like clearly a good idea to me. (Although I don't have
to code it :-)
Don't worry :) I think we have a motivated party.
Would it be worth having a separate <graphics> element
underneath
features, so the path would be /capabilities/guest/features/graphics/sdl ?
I only think this would be needed if we are going to add other
graphics-related features. Can you think of other features that would
fit? I think libvirt always assumes some form of vnc support so there
may not be a need to enumerate graphics types. We might want to
advertise spice support, but that wouldn't fit strictly under graphics
because spice affects much more than the graphics device.
Is there a desire to eventually add support for enumerating the
different models of devices that qemu can emulate? For example,
[ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet, virtio] for
network models? If so, we may want to place this information in a more
structured hierarchy /capabilities/guest/devices/net/models/. Either
way, SDL support isn't part of the device model so it would probably
make sense to place it directly under 'features' IMO.
--
Adam Litke
IBM Linux Technology Center
4:38 a.m.
On Fri, Jul 08, 2011 at 09:19:46AM -0500, Adam Litke wrote:
Hi all,
In order to nicely support domains that use qemu's SDL support,
libvirt-cim is looking for a way to confirm if the underlying qemu
emulator can support SDL. Libvirt already knows this information
internally. It seems to me that the best way to provide this
information is by reporting it as a guest feature via the capabilities
API call. I was thinking the node '/capabilities/guest/features/sdl'
could be added when qemu supports SDL.
Is this a good idea?
Yes & no. I think in general it would be desirable to expose more info
about supported features, but this is really opening a can of worms
because figuring out just what info needs exposing & in what format
is non-trivial. Even QEMU itself still can't provide this info in any
usable fashion, hence we're still parsing -help which really sucks.
Just adding an '/sdl' element seems simple but I don't think it is
a long term sustainable strategy.
If we added info about all supported features to the capabilities XML,
we will end up with an absolutely enourmous XML document that will no
longer be practically useful to administrators because it will be 99%
irrelevant info about devices hiding the 1% they really want about the
supported virt options.
So if we are to expose info about supported device model properties
then I think it would have to be in a separate API / XML schema, and
I think we want to get QEMU to provide the data in a more usable
manner than currently.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
4919
days inactive
4922
days old
3 comments
3 participants
participants (3)
-
Adam Litke -
Daniel P. Berrange -
Richard W.M. Jones