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

Pavel Hrdina phrdina at redhat.com
Fri Oct 21 11:57:07 UTC 2016


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 at redhat.com
> >> https://www.redhat.com/mailman/listinfo/libvir-list
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161021/416eae76/attachment-0001.sig>


More information about the libvir-list mailing list