On Sat, Apr 09, 2016 at 09:08:30PM -0400, Cole Robinson wrote: > On 04/09/2016 05:23 PM, Pavel Hrdina wrote: > > On Fri, Apr 08, 2016 at 01:40:21PM -0400, Cole Robinson wrote: > >> On 04/04/2016 09:20 AM, Pavel Hrdina wrote: > >>> If in qemu.conf vncAutoUnixSocket is enabled remove all other listens > >>> parsed from XML config. > >>> > >>> Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx> > >> > >> Sorry I should have read further before commenting on patch #15 :) > >> > >> This isn't in line with how we handle qemu.conf vnc_listen, which is 'only use > >> the qemu.conf setting if the user doesn't specify any explicit <listen> config' > >> > >> I think that's the more sensible behavior so I'd rather see the code fixed to > >> abide that instead. So, the change I suggested in patch #15, but maybe it > >> needs fixes elsewhere too > > > > I dislike this behavior too, but I'm not sure whether we can change it or no > > since it was already released and someone can count on it and libvirt has a rule > > that we don't change anything. My intention in the following patches is to make > > the address/socket attribute of listen elements optional and if only > > <listen type='address'/> is present libvirt will use a config address and for > > <listen type='socket'/> libvirt will auto-generate the socket path. The > > qemu.conf will be used only to force all graphics to use only socket if that > > option is specified. > > > > I think this is a perfectly acceptable thing to change behavior for. I really > doubt anyone is dependent on libvirt's behavior of throwing out other > graphical config and forcing the socket bits, and this change would unify > behavior with vnc_listen. Plus in my mind it's much more intuitive I've checked the qemu.conf again and even the comment for that option says this: "This will only be enabled for VNC configurations that do not have a hardcoded 'listen' or 'socket' value. This setting takes preference over vnc_listen." So yes, this is a bug and should be fixed. I'll include updated version of 15/18 patch in the next patch series. Pavel -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list