8:37 a.m.
On Fri, Oct 14, 2016 at 03:49:13PM -0400, John Ferlan wrote:
On 10/14/2016 11:30 AM, Pavel Hrdina wrote:
> On Fri, Oct 14, 2016 at 10:58:12AM -0400, John Ferlan wrote:
>> [...]
>>>>
>>>> UGH... mea culpa - in my mind the TLS hadn't been added to the
chardev
>>>> yet and that was the rest of this series... Of course the rest of this
>>>> series is adding the passphrase for the environment (<sigh>).
>>>>
>>>> If I could have got that review earlier, then this situation
wouldn't be
>>>> a problem (see in my mind it wasn't).
>>>>
>>>> If a domain is already running, then encryption is occurring and this
>>>> setting has no effect except for hotplug.
>>>>
>>>> If we were using encryption in 2.3.0... stopped our domain... installed
>>>> 2.4.0... started our domain, then yes, I see/agree.... Frustrating
>>>> since there's really no "simple" way to determine this.
>>>>
>>>>>
>>>>> The correct solution is:
>>>>>
>>>>> - if chardev_tls is set to 1 and tls attribute is not configured
in the XML
>>>>> the default after starting the domain should be tls=yes
>>>>
>>>> So IOW:
>>>>
>>>> + if (cfg->chardevTLS &&
>>>> + dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_YES) {
>>>>
>>>> changes to
>>>>
>>>> + if (cfg->chardevTLS &&
>>>> + dev->data.tcp.haveTLS != VIR_TRISTATE_BOOL_NO) {
>>>>
>>>> or (haveTLS == YES || haveTLS == ABSENT)
>>>>
>>>> This of course is essentially the logic from v6 which said disableTLS
on
>>>> a case by case basis.... All we have now is the positive form...
>>>>
>>>> So for both qemuBuildChrChardevStr and qemuDomainAttachChrDevice
I'd
>>>> have a similar change. Does that suffice and do you need to see the
change?
>>>
>>> I think that we should reflect the state in live XML if the attribute
exists.
>>>
>>> Add a code to qemuProcessPrepareDomain() that will set
dev->data.tcp.haveTLS
>>> to config value if dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_ABSENT and
in
>>> qemuBuildChrChardevStr() you can just check if
>>> dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_YES. This will also ensure
that
>>> the live XML contains the 'tls' attribute. But make sure, that
migration works
>>> properly for all combinations.
>>>
>>
>> I don't see the advantage... Altering the running domain would involve
>
> The advantage is in case when the chardevTLS is set but the offline XML doesn't
> have 'tls' attribute configured. If the domain is started than it's
perfectly
> clear from the live XML that the tls is enabled or not.
>
Maybe I didn't explain it well enough... I don't see the advantage of
modifying qemuProcessPrepareDomain or qemuProcessAttach to try and
determine whether we should "enable" this property. I see no need to
introspect to inspect a setting in order to then make some assumption
whether the property should be enabled or not. We'll get ourselves in
trouble doing so. Too much complexity, too much danger for making a bad
assumption or decision.
There is a small complexity but noting danger and nothing slick
- in qemuProcessPrepareDomain:
if (dev->data.tcp.haveTLS == VIR_TRISTATE_BOOL_ABSENT) {
dev->data.tcp.haveTLS = cfg->chardevTLS;
dev->data.tcp.tlsFromConfig = true;
}
- in qemuProcessAttach:
the detection of TCP chardev is broken and doesn't even work, but if
someone fix it than it's also simple
if (opt && strstr(opt, "tls-creds"))
dev->data.tcp.haveTLS = true;
NOTE: this domain was executed outside of libvirt so it was not based
on config
- in virDomainChrSourceDefParseXML:
add code to parse "fromConfig" if (flags &
VIR_DOMAIN_DEF_PARSE_STATUS)
- in virDomainChrSourceDefFormat:
if (def->data.tcp.haveTLS != VIR_TRISTATE_BOOL_ABSENT &&
!(flags & VIR_DOMAIN_DEF_FORMAT_MIGRATABLE &&
def->data.tcp.tlsFromConfig))
virBufferAsprintf(buf, " tls='%s'",
virTristateBoolTypeToString(def->data.tcp.haveTLS));
if (flags & VIR_DOMAIN_DEF_FORMAT_STATUS)
virBufferAsprintf(buf, " fromConfig='%d'",
def->data.tcp.tlsFromConfig);
I can see that someone may not like this approach, but this is how it works in
libvirt. It's our mess that we introduce a feature and in next release we
introduce an attribute to control/reflect that feature via XML.
Try to look at it from user POV, there is a config option that can enable TLS
encryption for all domains and all chardevs, but there is also 'tls' attribute
that can be used to disable TLS encryption if it's set in qemu.conf or enable
TLS encryption if only proper certificates are set in qemu.conf. So if someone
looks at the live XML, if there is an 'tls' attribute, it's clear, but if the
attribute is missing, I would have to remember/check some different place to see
whether TLS encryption is configured or not. I would not like this and I
would asking a question why libvirt cannot reflect this case in live XML?
[...]
>> Finally, yeah migration is the final nail in the coffin for
this. How
>> does one migrate from 2.4 to 2.3 if 2.3 doesn't have this attribute we
>> just quietly set to YES for them?
>
> Well if the attribute is set to YES and the chardevTLS is set to 1 or if the
> attribute is set to NO and chardevTLS is set to 0 we can safely remove the
> attribute from migratable XML, because it's on user to ensure that the
> configuration is properly set on both sides, for other cases that migration
> should not be allowed because whether the encryption is enabled or not could be
> changed.
I think avoiding touching the migration XML is far more important than
trying to figure out all the possible permutations in order to come up
with some slick way to modify XML on the fly.
I don't agree and we already do a lot of stuff to create a proper migratable XML
that is backward compatible if no new feature was used. Unfortunately the
'tls' attribute isn't a new feature, the feature already exists in previous
libvirt release and therefore we have to handle it properly to not break
migration.
Pavel