Auto IP assignment to a dom0 virtual interface – Part #2

As we saw eariler, with careful configuration and the use of my small service, we’re able to remote in the dom0 no problem, but the main pitfall I didn’t realize was there until a couple days ago, is that in that iteration of the service, now updated, we lost console and performance monitor for most of the VMs spawning after the UTM. I tried asking for pointers, but given the “experimental” nature of my setup, I was left on my own.

The problem

First of all, while I was setting things up I left an ip outside of the class I was using to the management interface, in order for it not to interfere. This resulted in consoles not working for about any VM, since instead of a specified class it was using

# xe console-list
uuid ( RO)             : <uuid>
         protocol ( RO): RFB
         location ( RO): https://192.168.4.x/console?ref=OpaqueRef:<ref>

Reconfiguration through `xsconsole` or Center don’t work, obviously, so the only thing left to do was to restart in safe mode and change to the proper subnet. So far so good.

Upon restart everything seems working, up to the time I actually start a different VM:

# xe console-list
uuid ( RO)             : <uuid>
         protocol ( RO): RFB
         location ( RO): https:///console?ref=OpaqueRef:<ref>

This time everything was configured properly, but it still wouldn’t work. As it turns out, somewhere between starting the VMs and setting up the network, the bridge loses its ip. Xapi doesn’t care in the slightest what IP you’re connecting to, so when it has to pass a link to a management section, it just looks up its management network bridge for the address binded to it and generates it.

The solution

The solution is pretty simple: on top of adding a /24 mask to the VIF you’re connecting to, you also need to add the same ip with a /32 mask to the management bridge:

# ifconfig
xapi1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast

xenbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast

Thanks to [SkiD] for moral support and reminding me that this configuration is actually valid, since in routing terms `xenbr0` doesn’t go anywhere.

Leave a Reply

Your email address will not be published. Required fields are marked *