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>
Description: Digital signature