> while (cur != NULL) {
> @@ -10628,6 +10630,8 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr def,
> case VIR_DOMAIN_CHR_TYPE_UNIX:
> if (!append && def->type ==
VIR_DOMAIN_CHR_TYPE_FILE)
> append = virXMLPropString(cur, "append");
> + if (!skipRelabel && def->type ==
VIR_DOMAIN_CHR_TYPE_FILE)
> + skipRelabel = virXMLPropString(cur,
"skipRelabel");
I'm guessing you want to keep this away from users, right? You should
not be parsing it from the XML then. Or you should add a thing there
that the XML supports. Not just a random attribute.
Either keep this data in private structure or even better, just add the
same thing as you would do with:
<seclabel relabel="no"/>
What sense would it make in this case? There is only one option when we're
running virtlogd and that is no label. If they supply relabel='yes', it won't
work with virtlogd unless they change it back to 'no'. So, you've got an
option
the functionality of which depends on a service running, which is by default on
by the way.
Since I don't want to be someone who just criticizes other people's ideas
without adding anything to the discussion, I was thinking about re-using the
qemu config parameter stdioLogD. But that solution is also wrong as it turned
out. I haven't come up with anything better yet, though. So, having something in
the status XML seems like a plausible approach to me.
Erik
with all the details of course. The user can see it, can supply it, old
releases support it, all the stuff is there already.
I'm open to suggestions, but NACK to random "wannabe private" attributes.
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list