1:31 a.m.
Currently consumers of libvirt's APIs must assume/attempt to define a
VM that uses spice, vnc, or sdl without knowing if the actual
hypervisor supports it. Obviously my discussion is very QEMU oriented
but it would be good to leave expansion for the future. I was thinking
that under the <guest> element for the capabilities we can add
something like:
<graphics>
<spice/>
<vnc/>
<sdl/>
</graphics>
It would be at the same level as <arch> and <features>. But before I
implemented this I wanted a sanity check if people think this is the
best place or the best naming convention.
Thanks.
--
Doug Goldstein
1:56 a.m.
On 19.10.2012 08:31, Doug Goldstein wrote:
Currently consumers of libvirt's APIs must assume/attempt to
define a
VM that uses spice, vnc, or sdl without knowing if the actual
hypervisor supports it. Obviously my discussion is very QEMU oriented
but it would be good to leave expansion for the future. I was thinking
Indeed. I look at libvirt as (sane) superset of hypervisor's features.
Not their bare intersection.
that under the <guest> element for the capabilities we can add
something like:
<graphics>
<spice/>
<vnc/>
<sdl/>
</graphics>
It would be at the same level as <arch> and <features>. But before I
implemented this I wanted a sanity check if people think this is the
best place or the best naming convention.
Thanks.
Makes sense to me.
Michal
3:26 p.m.
On 10/19/2012 02:31 AM, Doug Goldstein wrote:
Currently consumers of libvirt's APIs must assume/attempt to
define a
VM that uses spice, vnc, or sdl without knowing if the actual
hypervisor supports it. Obviously my discussion is very QEMU oriented
but it would be good to leave expansion for the future. I was thinking
that under the <guest> element for the capabilities we can add
something like:
<graphics>
<spice/>
<vnc/>
<sdl/>
</graphics>
This is something I've wanted to do for a long long time but my scope is much
bigger: libvirt really needs to report near everything it knows about qemu
emulator capabilities to the API user so we don't need to keep large
whitelists in apps like virt-manager. That doesn't mean we couldn't start here
though.
The simplest place to put it is capabilties for sure, but if the scope is
going to grow to cover more XML parameters it might be worth considering a
separate API (but maybe we don't care if capabilities output is 100 pages long).
The XML format could quickly get hairy if you assume that in the future maybe
we want to report what graphics types support password or other arbitrary XML
elements, but maybe that's getting into the realm of rng schema.
- Cole
4:29 p.m.
On Sun, Oct 21, 2012 at 3:26 PM, Cole Robinson <crobinso(a)redhat.com> wrote:
On 10/19/2012 02:31 AM, Doug Goldstein wrote:
> Currently consumers of libvirt's APIs must assume/attempt to define a
> VM that uses spice, vnc, or sdl without knowing if the actual
> hypervisor supports it. Obviously my discussion is very QEMU oriented
> but it would be good to leave expansion for the future. I was thinking
> that under the <guest> element for the capabilities we can add
> something like:
>
> <graphics>
> <spice/>
> <vnc/>
> <sdl/>
> </graphics>
>
This is something I've wanted to do for a long long time but my scope is much
bigger: libvirt really needs to report near everything it knows about qemu
emulator capabilities to the API user so we don't need to keep large
whitelists in apps like virt-manager. That doesn't mean we couldn't start here
though.
The simplest place to put it is capabilties for sure, but if the scope is
going to grow to cover more XML parameters it might be worth considering a
separate API (but maybe we don't care if capabilities output is 100 pages long).
The XML format could quickly get hairy if you assume that in the future maybe
we want to report what graphics types support password or other arbitrary XML
elements, but maybe that's getting into the realm of rng schema.
- Cole
I completely agree with you. My vision was bigger as well but I was
trying to start small. The next item I was thinking of supporting
would be IDE, SCSI, virtio, virtio-scsi. I really see this as being
necessary per QEMU binary since you might have an ARM QEMU that
supported different items than your x86_64 binary. I agree that XML
could definitely get hairy once we start incorporating other systems
like PPC, ARM, etc. We should probably look at breaking the
capabilities up into some logical-ish sections.
- host
-- machine (power management, pae, acpi)
-- cpu / memory /numa
-- network
-- security (apparmor, selinux)
- guest (per arch)
-- machine (power management, pae, acpi)
-- cpu / memory / numa
-- output (graphics)
-- input (mouse, keyboard, usbredir?)
enum virCapMachine {
VIR_CAP_MACHINE_HOST,
VIR_CAP_MACHINE_GUEST_X86,
VIR_CAP_MACHINE_GUEST_AMD64,
VIR_CAP_MACHINE_GUEST_ARM,
VIR_CAP_MACHINE_GUEST_PPC,
};
enum virCapType {
VIR_CAP_TYPE_MACHINE,
VIR_CAP_TYPE_CPUMEM,
VIR_CAP_TYPE_OUTPUT,
VIR_CAP_TYPE_INPUT,
VIR_CAP_TYPE_NETWORK,
VIR_CAP_TYPE_SECURITY,
};
char *virCapabilitiesGet(enum virCapMachine, enum virCapType);
or maybe just
enum virCapHost {
VIR_CAP_HOST_MACHINE,
VIR_CAP_HOST_CPUMEM,
VIR_CAP_HOST_NETWORK,
VIR_CAP_HOST_SECURITY,
};
enum virCapArch {
VIR_CAP_ARCH_X86,
VIR_CAP_ARCH_AMD64,
VIR_CAP_ARCH_ARM,
VIR_CAP_ARCH_PPC,
};
enum virCapGuest {
VIR_CAP_GUEST_MACHINE,
VIR_CAP_GUEST_CPUMEM,
VIR_CAP_GUEST_OUTPUT,
VIR_CAP_GUEST_INPUT,
};
char *virCapabilitiesGetHost(enum virCapHost);
char *virCapabilitiesGetGuest(enum virCapArch, enum virCapGuest);
Just an initial off the cuff thought. Definitely needs refinement and
some better suggestions.
--
Doug Goldstein
10:21 a.m.
On Sun, Oct 21, 2012 at 04:26:39PM -0400, Cole Robinson wrote:
On 10/19/2012 02:31 AM, Doug Goldstein wrote:
> Currently consumers of libvirt's APIs must assume/attempt to define a
> VM that uses spice, vnc, or sdl without knowing if the actual
> hypervisor supports it. Obviously my discussion is very QEMU oriented
> but it would be good to leave expansion for the future. I was thinking
> that under the <guest> element for the capabilities we can add
> something like:
>
> <graphics>
> <spice/>
> <vnc/>
> <sdl/>
> </graphics>
>
This is something I've wanted to do for a long long time but my scope is much
bigger: libvirt really needs to report near everything it knows about qemu
emulator capabilities to the API user so we don't need to keep large
whitelists in apps like virt-manager. That doesn't mean we couldn't start here
though.
The simplest place to put it is capabilties for sure, but if the scope is
going to grow to cover more XML parameters it might be worth considering a
separate API (but maybe we don't care if capabilities output is 100 pages long).
The XML format could quickly get hairy if you assume that in the future maybe
we want to report what graphics types support password or other arbitrary XML
elements, but maybe that's getting into the realm of rng schema.
On the one hand we already have per-emulator capabilities in the current
XML document, we machine types and the <features> block showing
<cpuselection/> and <deviceboot/> flags.
I think we should *not* put it in the existing capabilities XML document
though, because I think this will get enourmous very quickly - particularly
if you consider that we need to report this same data for every single
QEMU emulator we detect - and there are alot of them now. So I think we
ought to have a separate API that can be used to query just the specific
emulator you want to use.
Regards,
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 :|
4414
days inactive
4418
days old
4 comments
4 participants
participants (4)
-
Cole Robinson -
Daniel P. Berrange -
Doug Goldstein -
Michal Privoznik