| Summary: | [RFE] Resolve listen IP for graphics attached to Open vSwitch network | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Petr Horáček <phoracek> |
| Component: | libvirt | Assignee: | Laine Stump <laine> |
| Status: | CLOSED DEFERRED | QA Contact: | yalzhang <yalzhang> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | dyuan, jsuchane, laine, libvirt-maint, rbalakri, xuzhang, yalzhang |
| Target Milestone: | rc | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-06-05 18:49:29 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: | |
| Bug Depends On: | |||
| Bug Blocks: | 1436760 | ||
Without extra configuration, libvirt doesn't have a way of knowing that the IP address of the device named "net1" should be used.
There is a workaround with current libvirt though - create a network pointing directly at "net1" as the "bridge", but only use that network as the object of the graphics listen. For your example, you would create a network like this:
<network>
<name>net1-listen</name>
<forward mode='bridge'/>
<bridge name='net1'/>
</network>
Now set up your graphics device like this:
<graphics type='spice'>
<listen type='network' network='net1-listen'/>
</graphics>
This is a bit of trickery, since the device "net1" isn't a bridge device, but since you're only using it for the graphics listen, libvirt will only use the standard ioctls for getting its IP address (and won't ever attempt to attach another network device to it).
Thank you very much, Laine. It works for us and it helped us to clean up our code, the only problem is that it feels risky to exploit it like that. Can we be sure that the implementation won't change? Maybe at least a comment in libvirt codebase referencing this bug would be sufficient. It's safe to do this, and libvirt's code won't change in a way that would affect your usage. As long as you don't reference this network in an <interface>, you won't see any bad behavior. Since there is no clear way to get the correct IP address, and a workaround is available, I'm closing this. |
Description of problem: libvirt allows us to attach graphics device to a network, then it resolves IP on its own. However, when OVS network is used and not attached to a fake-bridge, but rather to OVS bridge and specific VLAN tag, libvirt is not able to resolve IP (it tries to use IP of bridge, whereas it should check another port). Version-Release number of selected component (if applicable): libvirt-2.2.0 How reproducible: Always Steps to Reproduce: 1. Create OVS devices: ovs-vsctl add-br ovsbr0 ovs-vsctl add-port ovsbr0 net1 tag=20 -- set Interface net1 type=internal ip address add 192.168.10.1/24 dev net1 2. Create libvirt network: <network> <name>net1</name> <forward mode='bridge'/> <bridge name='ovsbr0'/> <virtualport type='openvswitch'/> <vlan> <tag id='20'/> </vlan> </network> 3. Configure VM graphics device to listen on the network: <graphics type='spice'> <listen type='network' network='net1'/> </graphics> Actual results: libvirt fails, unable to find an IP on ovsbr0. Expected results: libvirt should use ip address on port 'net1'. Additional info: We need graphics to listen on IP 192.168.10.1. In order to do that, libvirt should use first IP found on given bridge's (ovsbr0) ports with given vlan tag (20). When no vlan tag is given, it should also check the bridge itself (as it does now). It should also work with portgroups (as interface does). Note: Interface attached to this type of networks works OK. Do you think it would be possible to implement/fix this scenario? Thanks a lot, Petr