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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
