Bug 1033704
Summary: | domain xml: libvirt should take defaultMode value into account when discarding <channel ... mode='MODE'/> entries | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | David Jaša <djasa> |
Component: | libvirt | Assignee: | Peter Krempa <pkrempa> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.0 | CC: | codong, djasa, dyuan, lhuang, mzhan, rbalakri, ydu, zhwang, zpeng |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | libvirt-1.2.7-1.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-03-05 07:28:28 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
David Jaša
2013-11-22 16:42:53 UTC
I presume you want to set mode='any' on a specific channel to enable the "use secure if possible, fall back to insecure otherwise" behavior. Is that what you request? I had a look at the qemu code that is actually parsing the command parameters: 1) If you set a default mode, than all channels you don't specify otherwise use that said default mode. 2) You can override default mode by specifying one of the other values which is then honored 3) You can't set more than one desired security mode per channel. (next set attempt overwrites the previously set value - also verified in spice server code) In libvirt, if the channel element is missing from the XML, we don't set any parameters on the channel itself thus it will inherit the default mode. If you request any non-default mode we use that mode in the command line for qemu and we record it. The current logic on handling defaultMode in libvirt will then retain any explicitly set states and allow you to change the rest using default mode at any time. Also as it's impossible to set the "fallback" behavior when using defaultMode I don't see any problem with the current logic. Could you please provide any reasons why you think the current behavior is broken? > Could you please provide any reasons why you think the current behavior is broken?
It's inconsistent:
1. <channel ... mode='any'/> isn't supported by qemu - saving such xml should return error in first place
2. defaultMode set to 'any' (or omitted) results in discarding channel mode='any' --> good, makes sense
3. defaultMode set to 'secure' (or insecure) results in discarding channel mode='any' - even if point 1. wouldn't stand, this is inconsistent with point 2.
4. defaultMode set to secure (or insecure) doesn't discard channel mode='secure' (or insecure respectively)
points 3. and 4. are the reason I filed the bug.
(In reply to David Jaša from comment #4) > > Could you please provide any reasons why you think the current behavior is broken? > > It's inconsistent: > 1. <channel ... mode='any'/> isn't supported by qemu - saving such xml > should return error in first place Channel mode any according to libvirt's docs "... and the default any (which is secure if possible, but falls back to insecure rather than erroring out if no secure path is available)" Libvirt's options are not necessarily directly mapped to qemu and this one has different semantics. > 2. defaultMode set to 'any' (or omitted) results in discarding channel > mode='any' --> good, makes sense in "<channel mode=" setting ANY means the default (use the value from defaultMode) and thus it's discarded. > 3. defaultMode set to 'secure' (or insecure) results in discarding channel > mode='any' - even if point 1. wouldn't stand, this is inconsistent with > point 2. Setting the individual channel mode to some value is meant to override the default and thus it's desired to keep the overridden value even if it is equal to the default mode. If the default mode then changes the individual channel will be kept in the desired setting. > 4. defaultMode set to secure (or insecure) doesn't discard channel > mode='secure' (or insecure respectively) No it doesn't, because you want to specifically override the channel to use the specified mode regardless of the setting of defaultMode. > > points 3. and 4. are the reason I filed the bug. I have to agree that the docs are not exactly clear on how the channel mode should be specified, so I'll propose a patch to clean up the docs. Resolved in v1.2.6-205-gbbfc826: commit bbfc826787b6d3afade5dd130f40669a92189963 Author: Peter Krempa <pkrempa> Date: Mon Jul 21 17:12:51 2014 +0200 doc: Explicitly specify how to override spice channel mode Be more clear that the "<channel mode=" attribute overrides the default set by "defaultMode". Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1033704 diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index bb6f710..8950959 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -4191,7 +4191,13 @@ qemu-kvm -net nic,model=? /dev/null configured, it can be desirable to restrict what channels can be run on each port. This is achieved by adding one or more <channel> elements inside the - main <graphics> element. Valid channel names + main <graphics> element and setting the <code>mode</code> + attribute to either <code>secure</code> or <code>insecure</code>. + Setting the mode attribute overrides the default value as set + by the <code>defaultMode</code> attribute. (Note that specifying + <code>any</code> as mode discards the entry as the channel would + inherit the default mode anyways) + Valid channel names include <code>main</code>, <code>display</code>, <code>inputs</code>, <code>cursor</code>, <code>playback</code>, <code>record</code> Verify this bug with libvirt-1.2.8-7.el7.x86_64 : Check the docs in /usr/share/doc/libvirt-docs-1.2.8/html In formatdomain.html : 4014 When SPICE has both a normal and TLS secured TCP port 4015 configured, it can be desirable to restrict what 4016 channels can be run on each port. This is achieved by 4017 adding one or more <channel> elements inside the 4018 main <graphics> element and setting the <code>mode</code> 4019 attribute to either <code>secure</code> or <code>insecure</code>. 4020 Setting the mode attribute overrides the default value as set 4021 by the <code>defaultMode</code> attribute. (Note that specifying 4022 <code>any</code> as mode discards the entry as the channel would 4023 inherit the default mode anyways) 4024 Valid channel names Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0323.html |