Bug 1400952 - [RFE] Resolve listen IP for graphics attached to Open vSwitch network
Summary: [RFE] Resolve listen IP for graphics attached to Open vSwitch network
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: yalzhang@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 1436760
TreeView+ depends on / blocked
 
Reported: 2016-12-02 11:52 UTC by Petr Horáček
Modified: 2018-06-05 18:49 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-05 18:49:29 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Petr Horáček 2016-12-02 11:52:14 UTC
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

Comment 2 Laine Stump 2017-04-18 14:56:10 UTC
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).

Comment 4 Petr Horáček 2017-10-05 13:32:35 UTC
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.

Comment 5 Laine Stump 2017-10-05 16:19:03 UTC
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.

Comment 6 Laine Stump 2018-06-05 18:49:29 UTC
Since there is no clear way to get the correct IP address, and a workaround is available, I'm closing this.


Note You need to log in before you can comment on or make changes to this bug.