Re: [libvirt] [PATCH v10 2/4] domain: Add optional 'tls' attribute for TCP chardev

On 10/21/2016 02:29 AM, Pavel Hrdina wrote: > On Thu, Oct 20, 2016 at 03:48:30PM -0400, John Ferlan wrote: >> [...] >> Since I assume you have these changes in your local branch - let's go with the two patches and move on. It would be nice while it's still fresh to update the documentation, but that's a separate patch. So "officially" it's an ACK of your changes on top of and in addition to my changes. John

[...] > Now I see why we are not able to agree on this change. The modification done > in qemuProcessPrepareDomain() are only to live definition, the config > definition remains untouched, which means the *tls* attribute (if it's based on > qemu.conf) will appear only in live XML. The config XML will remain the same > after the guest is stopped. > >> I think it should be strictly optional and that's where we differ. I see >> no reason to change the domain xml unless as a consumer that's what you >> want to do - be able to control which domains will have the setting. >> What else would be the purpose of a host wide setting to go with a >> domain optional setting? >> >> Finally, if your idea is accepted, that means for any configuration with >> chardev_tls=0 (either because it's commented or set that way), every >> domain that starts will be updated to have this new attribute >> "tls='no'". Then one day, I read up on this wonderful new feature and > > Not the domain, only the live XML which is not saved as config XML ... > >> modify my qemu.conf file to set chardev_tls=1 and set up the TLS >> environment properly. I go to start my domain, but wait it's not using > > And after you start the domain there will be "tls='yes'" because the config XML > doesn't contain any *tls* attribute. > > I've tested all of those cases before proposing this patch: > > prerequisite: prepare certificate files to be used for chardev devices > > for running domain: > live XML - virsh dumpxml $domain > config XML - virsh dumpxml $domain --config > migratable XML - virsh dumpxml $domain --migratable > > 1. set chardev_tls = 1 > a) start domain where there is no *tls* attribute in config XML > - the domain is started and TLS is properly configured > - in the live XML there is "tls='yes'" > - in the config XML there is no *tls* attribute > - in the migratable XML there is no *tls* attribure > > b) start domain where there is "tls='no'" in config XML > - the domain is started and TLS is not configured > - in the live XML there is "tls='no'" > - in the config XML there is "tls='no'" > - in the migratable XML there is "tls='no'" > > c) start domain where there is "tls='yes'" in config XML > - the domain is started and TLS is properly configured > - in the live XML there is "tls='yes'" > - in the config XML there is "tls='yes'" > - in the migratable XML there is "tls='yes'" > > 2. set chardev_tls = 0 > a) start domain where there is no *tls* attribute in config XML > - the domain is started and TLS is not configured > - in the live XML there is "tls='no'" > - in the config XML there is no *tls* attribute > - in the migratable XML there is no *tls* attribure > > b) start domain where there is "tls='no'" in config XML > - the domain is started and TLS is not configured > - in the live XML there is "tls='no'" > - in the config XML there is "tls='no'" > - in the migratable XML there is "tls='no'" > > c) start domain where there is "tls='yes'" in config XML > - the domain is started and TLS is properly configured > - in the live XML there is "tls='yes'" > - in the config XML there is "tls='yes'" > - in the migratable XML there is "tls='yes'" > > Pavel > >> it. Closer inspection finds, someone put "tls='no'" into my domain... To >> me that's not right. And I won't necessarily know unless I know to look >> at the cmdline of the started domain to find that 'tls-creds' or I in >> some way "track" when TLS is being used. >> >> >> John >> >> -- >> libvir-list mailing list >> libvir-list(a)redhat.com >> https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list