On Thu, Mar 10, 2016 at 02:56:04PM +0100, Marc-André Lureau wrote: > Hi > > On Thu, Mar 10, 2016 at 2:00 PM, Jiri Denemark <jdenemar@xxxxxxxxxx> wrote: > > On Thu, Mar 10, 2016 at 13:54:57 +0100, Marc-André Lureau wrote: > >> QEMU (somewhere around 2.0) added a new sub-option to the -name flag > >> -name debug-threads=on > >> > >> This causes the naming of individual QEMU threads to be helpful; e.g. > >> 'CPU/KVM 0' or 'migration' these show up in top once the H key is > >> pressed, and also show up in a core dump, making it easy to figure > >> out which thread is which. > >> > >> The following 2 patches add a capability check and a qemu-conf key to > >> enable debug-threads. > > > > Is there any reason against enabling this unconditionally? It sounds > > like a nice thing to have if possible so I'd just always enable it if > > QEMU supports that... > > > > That would be fine for me, I just wanted to be as careful as qemu is. > They were probably thinking some monitoring tool could be confused. I > suppose in libvirt case, there should not be furthere such monitoring, > and libvirt is not confused. So why not? Keep the first patch, > simplify the second? As far as libvirt is concerned, any monitoring tool should be using the libvirt APIs. Any tool that is talking straight to QEMU for a libvirt managed VM is in unsupported territory and gets to keep both pieces if it breaks. So while I understand QEMU's caution, I don't think it is needed in libvirt. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list