VM Networks

[RBarlow92]

We created some private networks for testing vlan segmentation.

When VMs were on different hosts the pings worked fine, when on the same host they couldn’t ping.

We had to run these commands to change the macvtap mode from private to bridge:

ip link set macvtap24 type macvtap mode bridge

ip link set macvtap25 type macvtap mode bridge

Is this expected after creating the networks?

Is there a way to create networks without needing to do this.

We need vm traffic to flow if vms are on the same host or not.

Any help would be greatly appreciated.

[dya]

https://support.hpe.com/hpesc/public/docDisplay?docId=sd00008401en_us&page=GUID-6E5E7B48-5F12-4A46-9A1A-F7AE3EA9BC4D.html

For your reference regarding the above network.
Private networks will be created as confirmed. First, why not try the "HVM Standard Network"?

*Sorry if this is hard to understand as it is a machine translation.

[CalvinZito]

I have a Copilot notebook based on v9.0.1 documentation. It says this:

What you're seeing is expected for HVM Private Networks.

Per the documentation, an HVM Private Network is implemented as a MacVTAP-backed libvirt network. When a VM is attached to this network, VM Essentials creates a macvtap interface and maps it to the VLAN-tagged host interface.  SOURCE: pages 401-481

The documentation states:

"The HVM Private Network creates a MacVTAP-backed libvirt network on each host... When a VM connects to this network, libvirt automatically creates a macvtap interface on the host..."   SOURCE: pages 401-481

However, the documentation does not describe changing the macvtap mode from private to bridge, nor does it state that same-host VM-to-VM communication is enabled by default for HVM Private Networks. 

Based on the documented architecture, HVM Private Networks are designed to provide:

"isolated VM-to-physical network connectivity with minimal overhead" using MacVTAP interfaces. SOURCE: pages 401-481

Therefore, if same-host VMs could not communicate until you changed:

ip link set macvtap24 type macvtap mode bridge

ip link set macvtap25 type macvtap mode bridge

that behavior is consistent with how MacVTAP networking commonly operates when not using bridge mode, although the VM Essentials documentation does not explicitly document the default macvtap mode.

At this time I could not find any documented option in VM Essentials 9.0.1 to create an HVM Private Network with macvtap interfaces automatically configured in bridge mode. The documented network creation workflow only exposes VLAN ID and host interface selection for HVM Private Networks.

If your requirement is:

VMs must communicate whether they are on the same host or different hosts

you may want to consider an HVM Standard Network or HVM Overlay Network, both of which are designed around OVS/libvirt networking rather than MacVTAP-based networking. The documentation describes HVM Standard Networks as OVS-backed port groups and HVM Overlay Networks as VXLAN-based overlays for VM-to-VM communication across hosts.

Additionally, not from the documentation:

In Linux/libvirt environments, MacVTAP in private mode typically prevents direct communication between endpoints on the same lower device, while bridge mode allows local switching between them. What you observed is a classic symptom of that behavior. If this is an HVM Private Network, I'd expect the current implementation to favor isolation over same-host switching unless the mode is explicitly changed. This may be worth opening as an enhancement request if you need a UI option to create Private Networks with bridge-mode macvtap by default.

[RBarlow92]

So in order to use a standard network you need a router creating.

We are wanting to set up the below for example:

Customer A on vlan 200

Customer B on vlan 300

So if we have say 50 customers we need to use standard and create 50 routers?

Or do we create one client network router and then use the standard networks to split out the traffic?

We currently have 4 NICs on the hosts 2 for management/vm traffic and 2 for iscsi.

This is currently working in vcenter as we use distributed switches.

Many Thanks

Ryan

[CalvinZito]

Again, from the documentation (not me as I don't have hands-on experience):

You should only need one OVS Bridge Domain (router object) for a given physical uplink/bond, not one per customer VLAN.

Based on the HVM networking documentation, an OVS Bridge Domain is the underlying virtual switch. HVM Standard Networks are then created as OVS port groups that attach to that bridge and are assigned VLAN IDs. The workflow is:

1. Create an OVS Bridge Domain (router) backed by your compute network interface or bond.
2. Create multiple HVM Standard Networks that reference the same OVS Bridge Domain.
3. Assign a different VLAN ID to each Standard Network.

The documentation specifically describes the OVS Bridge Domain as the backing virtual switch for Standard Networks, and Standard Networks are where the VLAN ID is configured. 

So for your example:

OVS Bridge Domain (bond0)

├─ Customer-A-Network  VLAN 200

├─ Customer-B-Network  VLAN 300

├─ Customer-C-Network  VLAN 400

├─ Customer-D-Network  VLAN 500

...

That would be 1 OVS Bridge Domain + 50 Standard Networks, not 50 routers. The Standard Networks are the tenant/customer networks and carry the VLAN definitions.

The documentation also notes that a single physical VM NIC can carry multiple VLANs and that Standard Networks support VLAN-based segmentation through the VLAN ID and trunk configuration. 

Given your current design:

• 2 NICs for management/VM traffic
• 2 NICs for iSCSI

I would expect the VM/customer traffic bond/uplink to back a single OVS Bridge Domain, then create one Standard Network per customer VLAN. This is conceptually much closer to how you're using a VMware Distributed Switch today, where one distributed switch carries many port groups/VLANs rather than one distributed switch per VLAN. However, the documentation does not explicitly compare the architecture to VMware vDS.

One thing worth noting: when the cluster is originally provisioned, the COMPUTE VLANS field can create OVS port groups for VLANs on the compute interface, and HVM networking is built around OVS networks and VLANs.

Documentation-based summary:

+  1 OVS Bridge Domain (router) per physical compute uplink/bond is a valid design.
+  Create multiple HVM Standard Networks on that bridge.
+  Assign VLAN 200, 300, 400, etc. to the individual Standard Networks.
x  Documentation does not indicate creating one OVS Bridge Domain per customer VLAN.