To change a network - It’s just a foot gun drop down, how hard can it be?

story time

In testing the VMware to Vates (V2V) machinery in XCP-ng with Xen Orchestra, I found that the imports were taking longer than I had expected or hoped. In searching the web for others with similar experiences, I found a forum thread where someone highlighted that traffic for the import goes from your ESXi host, through Xen Orchestra, then to your XCP-ng host & relevant Storage Repository. In order to set this process up for success, you’ll want to have maximum performance available for all network paths involved.

It then dawned on me that I had set up XOA on a 1 gigabit network (because we’re just testing, right?). 💡Perhaps if I moved XOA over to the 10 gigabit network that the other VMs were using, I could decrease the import times.

There are a few things that make this a little difficult (at least from an XCP-ng newbie perspective.) XCP-ng 8.2 is architected to maintain a pool (cluster) of hosts and resources, but is intended to be managed through Xen Orchestra. The console of any host will expose basic VM control (start, stop, reboot), but no pathway to the console of any given virtual machine. This becomes a little risky & tricky when you’re attempting to change the interface through which you access your primary administration tool.

I had the Xen Orchestra Appliance set to DHCP for network, so I thought it should be as easy as changing the network for the Xen Orchestra virtual machine from within Xen Orchestra and it would just change interfaces, request new network information via DHCP, and be right back at the new address. This was not the case, and in hindsight I’m sure there are a number of requests that have to happen with the XAPI on the resource pool to ensure the change occurs with confirmation along the way and is finally agreed to have been successful. Once the interface changes, XO is now out of the chain and can not participate in the process.

options

Mentioned previously, the resource pool (clustered hosts, storage, and networking) maintains the state and health of the pool. It also exposes management through the Xen API or XAPI. While Xen Orchestra is the primary administration tool, it is not necessarily the only way to interact with the pool.

XCP-ng Center

XCP-ng Center is a desktop application that interacts with the resource pool via the XAPI. This exposes many Xen Orchestra features through a convenient desktop application that is not tied to the resources that you’re administrating. This application served as an excellent way to access the console of my Xen Orchestra Appliance and is ultimately the tool that let me unwind the problem I had made for myself.

XO-Lite

Coming with XCP-ng 8.3, XO-Lite should provide a web based path to accessing your host including console access. A big caveat is that I haven’t tried XO-Lite with a resource pool so I don’t know if it has limitations in that scenario.

Think smarter and additional interface

In my particular stumble, I think a smarter approach would have been to add a secondary vif to the XOA and attempt to get it accessible through the new interface before removing the old one.

closing

I’ll certainly be keeping XCP-ng Center in my back pocket. It can really serve as a life boat in scenarios where you lose an aspect of your resource pool that XO depends on. Aside from the learning experience, V2V migrations are noticeably faster with Xen Orchestra positioned a bit better in the process.

• Xcp-Ng
• Sysadmin