In a physical world, machines communicate with each other without routers when they belong to the same network. This is the same case with openstack, VMs communicate over the same network without routers.
When two VMs belonging to the same network happen to get deployed on the same compute host, their logical diagram looks like this
As we can see above, each VM will have its own tap device, qbr bridge, qvb-qvo veth pair and they both connect to br-int. br-int is in charge of VLAN tagging the traffic, and in this case it will VLAN tag this traffic to the same VLAN, since they belong to the same network.
We can verify this in the following example: 2 VMs test and test belong to the same network and the same subnet.
One thing to mention here, VLAN tags for the same network on the same host are the same. This applies regardless whether the VMs are on the same subnet or different subnets. Now let’s look into the VMs test & test2 logical diagram and focus on the qbr bridges definitions and the integration bridges definitions
using br-ctl show , we can see the qbr bridge for every VM and the associated interfaces
now let’s look at the definition of integration bridge using ovs-vsctl show
as we see in the previous image, there are two qvo interfaces with VLAN tag “1”. So the idea is that since the VMs are on the same network, their qvo interfaces belong to the same VLAN tag on the same host. This way traffic can flow normally as with physical world, where switch ports are segregated using VLAN tags.
Unicast traffic flows between test and test2 VMs within the same host using the br-int bridge over dedicated VLAN tag for this particular network.
In openstack, as in physical world, switches have no idea if your machines/VMs are on different IP subnets. Switches operate at layer 2 so for them subnets are not visible. This is the reason that VLAN tag IDs are dedicated per network, not per subnet. So if you have a network with 2 subnets and you have a VM on each, their qvo interfaces will have the VLAN tag if they end up on the same compute host
Next post will be about VM to VM communication, same network but different compute hosts