On Tue, Nov 21, 2017 at 12:57:36PM +0100, Pavel Hrdina wrote:
On Tue, Nov 21, 2017 at 11:24:06AM +0000, Daniel P. Berrange wrote:
> On Tue, Nov 14, 2017 at 02:45:08PM +0100, Pavel Hrdina wrote:
> > If there is no sound device configured for the guest we can disable the
> > audio output because hot-plugging sound devices isn't supported.
>
> Are you sure about that. While libvirt may not have wired up ability to
> hotplug sound devices, I'm pretty sure that QEMU is able to hotplug
> them.
>
> Ff libvirt forceably disables the audio backend, now, and then future
> libvirt enables the pre-existing QEMU support for hotplug, existing VMs
> will be doomed.
>
> IOW, I don't think this patch is desirable.
Right, I meant from libvirt POV. Anyway, if we allow to hot-plug sound
device, you have no control where the audio output will be connected.
Configuration of audio output is really stupid in QEMU. You need to use
environment variable, you have only one so you cannot configure
different sound devices to have different audio output and from
documentation it is not clear what is the default if you don't set the
QEMU_AUDIO_DRV. Checking the code gives you headache :).
The default audio output depends on what audio drivers are enabled and
compiled in QEMU and on the order of the audio drivers, these can be
used as default: alsa, dsound, core, none, oss, pa, sdl, spice
(if there is spice graphics).
So based on all of the findings, if we allow hot-plugging sound device
and the QEMU_AUDIO_DRV is not configured in advance there is no way how
you can configure the audio output and no way how we can tell which one
will be the default.
I would rather have this limitation that you should start the domain
with sound device configured instead of allowing hot-plug since the
audio output design in QEMU is foobar.
As mentioned in my reply to Peter, I don't think ability to configure
the sound output is a blocker for hotplug, as there's valid reasons
for hotplug whih don't involve multiple cards being present at once.
Also 95+% of users of libvirt will have SPICE enabled, so all audio will
get routed via SPICE regardless. So what would be most interesting there
is not the ability to pick output backend, but the ability to pick which
spice server instance is used. This is a more general task of wiring up
multi-seat support that QEMU has had for a while, but libvirt doesn't yet
support.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|