On Fri, Oct 21, 2016 at 07:15:55AM -0400, John Ferlan wrote:
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
We should probably figure out also rng, smartcard and redirdevs before pushing. They also use the source as you've pointed out and currently they can be configured to use TLS with the chardev_tls config option. I'll send a new version of patch series to cover all users of TCP source type. Pavel
[...]
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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list