Ask Your Question
1

Can Neutron tag OpenVSwitch ports on dom0 in XenServer?

asked 2014-02-11 15:12:31 -0500

Andrew Kinney gravatar image

I have what I believe to be a working setup for OpenStack Havana with Neutron networking and XenServer as the hypervisor. I have a controller VM (keystone, glance, neutron-server, nova-[api|cert|conductor|consoleauth|xenvncproxy], rabbitmq-server), a compute VM (nova-compute, neutron-plugin-openvswitch-agent), and a networking VM (neutron-server, neutron-metadata-agent, neutron-plugin-openvswitch-agent, neutron-l3-agent, neutron-dhcp-agent). All of the OpenStack control, compute, and network VMs are Debian 7.3 (wheezy).

Everything seems to be working fine as long as the VM image I use has a preprogrammed use of VLAN tags in the networking configuration of the image.

For instance, my internal network used for testing was created with a segmentation ID (VLAN ID) of "3". If I use a standard VM image without VLAN tag support, the VM created from that image cannot communicate. It's blocked by the flows set on br-int within the networking VM, so the DHCP request never makes it to dnsmasq and everything after that (cloud-init stuff) naturally fails. If, however, I use a VM image with /etc/network/interfaces setup for VLAN tagging (eth0.3 dhcp), everything works great!

Of course, being XenServer, nova creates the VIF on a switch in dom0 (defined in nova.conf on the compute VM as "xenapi_ovs_integration_bridge=xapi2"). The port that the VM VIF connects to on the openvswitch running in dom0 is left untagged with no special flows defined.

I have a several concerns with this.

First, I'm not even sure I'm doing it right (all documentation for XenServer used with OpenStack is severely out of date and incomplete). For all I know, I'm just missing one mystery config flag being set somewhere.

Second, if I am doing it right, it seems onerous to have to make a separate VM image for every internal (tenant) network that gets defined since each will use a different VLAN and there is no way that I know of to auto-discover your VLAN in the Neutron/OpenVSwitch networking paradigm. Each VM image for use on a different VLAN must be created and uploaded to glance separately. Care must be taken to ensure you use the proper VM image with the proper network or networking breaks. This doesn't seem to fit with the ideals espoused by OpenStack.

Third, if I am doing it right, a tenant could jump to another tenant's network simply by configuring the VLAN tag within their VM. This seems like a gaping security hole, presuming we don't trust tenants to behave. Network name spaces took care of this within the l3-agent and dhcp-agent, but it doesn't do anything for the VMs themselves.

Now, all of my concerns would be resolved if, instead of inside the VM, the VLAN tag were placed on the openvswitch port to which the VM connects within dom0. Some switch vendors call this port based VLAN or PVID. It takes control of the VLAN tag out of the realm of the VM user and puts it only in the hands of the cloud ... (more)

edit retag flag offensive close merge delete

Comments

That bug report I mentioned turns out to be pivotal. I had several issues besides that I resolved, but that bug is still causing headaches. I'm looking into if there are any flags I can supply when uploading the VM image to glance that tell it to start the VM in PV mode rather than HVM and later PV.

Andrew Kinney gravatar imageAndrew Kinney ( 2014-02-13 16:14:40 -0500 )edit

Adding metadata properties to the glance image did not resolve. The root is that two interfaces are created at boot: a tap and a vif. When the tap gets deleted and it was the port that got tagged, the remaining vif has no tag. Sometimes you get lucky. If the vif gets the tag, all is well.

Andrew Kinney gravatar imageAndrew Kinney ( 2014-02-13 19:46:45 -0500 )edit

The ugly workaround is to reboot the VM until it works. It sounds like the '80s all over again, but virtualized.

Andrew Kinney gravatar imageAndrew Kinney ( 2014-02-13 19:48:50 -0500 )edit

2 answers

Sort by ยป oldest newest most voted
0

answered 2014-02-14 15:13:06 -0500

Andrew Kinney gravatar image

updated 2014-02-27 23:09:36 -0500

I wrote a better workaround at the bug report: https://bugs.launchpad.net/neutron/+bug/1268955/comments/12

edit flag offensive delete link more

Comments

This workaround fails for pure HVM where both the tap and vif interface hang around indefinitely. It's indeterminate which of the vif or tap will get tagged and networking for pure HVM domU only functions when the tap gets the tag.

Andrew Kinney gravatar imageAndrew Kinney ( 2014-02-27 23:07:59 -0500 )edit
0

answered 2014-02-11 18:49:34 -0500

Andrew Kinney gravatar image

https://bugs.launchpad.net/neutron/+bug/1268955 implies VLAN tagging of openvswitch ports in dom0 should be done if I have everything setup correctly. Further implication is that I don't have something setup properly. Following the guides is problematic at best because they presume kvm, not xenapi.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

2 followers

Stats

Asked: 2014-02-11 15:12:31 -0500

Seen: 839 times

Last updated: Feb 27 '14