On Thu, Jun 15, 2017 at 10:12:51PM -0400, John Ferlan wrote:
On 06/15/2017 10:40 AM, Pavel Hrdina wrote:
On Thu, Jun 15, 2017 at 07:57:18AM -0400, John Ferlan wrote:
On 06/15/2017 03:11 AM, Pavel Hrdina wrote:
On Tue, Jun 13, 2017 at 08:00:41PM -0400, John Ferlan wrote:
[...]
Wouldn't these changes end up selecting "any" chardev if chardevStdioLogd ended up being set regardless of whether they were actually using the log file?
I don't know what you mean by this sentence?
Well let's see, chardevStdioLogd is set to true when meeting the two conditions a qemu.conf global "cfg->stdioLogd" && a per domain or emulator image capability "QEMU_CAPS_CHARDEV_FILE_APPEND".
So, conceivably chardevStdioLogd could be true for *any* domain as long as those conditions are met, right?
Yes, the two conditions are checked while starting a new domain in qemuProcessPrepareDomain() and stored in the private date of that domain.
If you have a domain that has chardev's which are not configured to use the stdio handler, then the chardevStdioLogd could still be true, right?
No, if the @chardevStdioLogd is true all char devices for that domain will use virtlogd.
This is the part I'm stuck on as to why - based on the previous assertion. I'm just not visualizing all those various chardev configs. Just so you know - I have to be out Friday, but will be back Monday. If you get someone else to ACK this one in the mean time - that's fine.
The usage of virlogd can be only set in qemu.conf, not per-chardev, not even per-domain. We need to save it per-domain, though, as it can differ for domains started before and after that setting was changed in qemu.conf and the daemon restarted (or updated to a version with support for virtlogd as that is the default if nothing is specified in the config). The hotplug should be fixed, but as you said that can be a follow-up patch. Reviewed-by: Martin Kletzander <mkletzan@redhat.com>