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 192.168.4.0:
# 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 192.168.0.1 netmask 255.255.255.0 broadcast 0.0.0.0 xenbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.1 netmask 255.255.255.255 broadcast 0.0.0.0
Thanks to [SkiD] for moral support and reminding me that this configuration is actually valid, since in routing terms `xenbr0` doesn’t go anywhere.