Nodes created in virsh pod always use 'default' virtual network for NIC

[Nathaniel W. Turner]

Cool pod feature! Looks very promising.

If I compose a new VM in a libvirt-based pod, everything works, but the VM gets a virtual network interface that is connected to the default virtual network, which is pretty useless (behind NAT).

If I create a VM by hand using virt-manager, I can choose a network source for the NIC, and in addition to the virtual network 'default', I can choose to connect to a host device using macvtap in bridged mode. This is actually useful (the node can be reached from outside the vm host).

It would be great if at a minimum, the default network source could be specified as a property of the pod itself, so that newly composed machines had a functional default network setup.

MAAS version: 2.2.0 (bzr6054-0ubuntu1~16.04.1)

[Nathaniel W. Turner (nturner)]

Oh, I should mention that one of the problems with the current behavior is that while the VM host has a network interface on a VLAN managed by MAAS, since the newly composed VM gets a network interface on the useless default virtual network, it's not on that VLAN, and thus cannot PXE boot from the rack controller.

I realize I could add a rack controller VM to each and every such VM host to solve this issue (at the expense of using up resources better used for other VMs), but that still wouldn't solve the problem that the newly composed VM is not reachable from the outside world because it's behind the default virtual network's NAT.

[Blake Rouse (blake-rouse)]

At the moment no networking discovery or creation is used for Pods. For now the pod creation for virsh will look for a network named 'maas', then it will look for 'default' network, and then if neither exists it will just pick the first.

[Nathaniel W. Turner (nturner)]

The simplicity of not having to configure the network in the Pod UI is appealing.

How hard would it be to have maas first check for a *bridge* with the name "maas" before it checks for a virtual network with that name? That would work well for me.

[Nathaniel W. Turner (nturner)]

To clarify, for example, if maas finds this situation:

root@srv3866:~# virsh iface-dumpxml maas
<interface type='bridge' name='maas'>
      ...
</interface>

... instead of generating the following VM interface definition:

    <interface type='network'>
      ...
      <source network='default'/>
      ...

... could we generate:

    <interface type='bridge'>
      ...
      <source bridge='maas'/>
      ...

perhaps?

[Xav Paice (xavpaice)]

Using 2.3.2, I have pods with a virsh network named 'maas' and that handles most of my needs.

However, I have a Juju environment and would like to be able to compose a machine that has an interface in more than one space, and that doesn't seem possible with the feature as it stands without me going to the KVMs and editing them by hand (and, of course, adding the bridge on the host).

Would be awesome to have all the spaces available to the host set up as bridges and virsh networks named after the spaces.

[Mike Pontillo (mpontillo)]

Quick note on this: in MAAS 2.5+, if MAAS can determine (based on the IP address of the virsh pod - such as if it is on a deployed node whose network model has not changed, or a MAAS controller), the behavior will be much improved.

MAAS will still look at the `maas` and `default` networks, but if both of those networks are DHCP enabled in libvirt, MAAS will prefer to attach to a bridge known to be connected to a DHCP-enabled network.

In addition, interface constraints can be used to select specific networks or spaces.