Pool Management

McHenry

Edit: Reworded for clarity:

We have a number of individual clients each with an onprem production host and an onprem DR host. The DR host is lower spec'd. We have been placing both hosts in a client specific pool, named after the client, as a logical grouping of hosts.
i.e.

the ClientA pool has only the ClientA production host and ClientA DR host
the ClientB pool has only the ClientB production host and ClientB DR host

We are now setting up ClientC & ClientD using shared cloud hosts so the prodction host and DR host will be used by ClientC & ClientD. Accordingly, the host is no longer specific to the client so placing the host in a client specific pool no longer works.

So, my question is how should we best use pools if they are not simply a way a categorising client hosts into a logical group.

olivierlambert

Hi,

I'm not sure to understand exactly what's your problem Can you rephrase, thanks

nick.lloyd

@McHenry If I'm understanding this correctly, Client Site A, B, n... will each have a server and all share multiple instances at OVH for DR. First off, I hope you give the person that's doing the networking for this a raise .

Second, are you and/or a team the sole manager of the infrastructure? If clients have their own IT team that assists/uses XO(A), this will be more difficult. For the sake of this solution, I'm going to assume that the client can use XO(A) to start VMs in case of a DR scenario.

If I were to build it out, I would build an XO host in OVH and utilize the XO-proxy and the Self Service feature. This way, you can register the XO Proxy to all of the client sites, and manage who can see what VMs, networking/VLANS, and storage.

If I'm wrong about an assumption or solution, let me know!

john.c

@nick-lloyd said in Pool Management:

@McHenry If I'm understanding this correctly, Client Site A, B, n... will each have a server and all share multiple instances at OVH for DR. First off, I hope you give the person that's doing the networking for this a raise .

Second, are you and/or a team the sole manager of the infrastructure? If clients have their own IT team that assists/uses XO(A), this will be more difficult. For the sake of this solution, I'm going to assume that the client can use XO(A) to start VMs in case of a DR scenario.

If I were to build it out, I would build an XO host in OVH and utilize the XO-proxy and the Self Service feature. This way, you can register the XO Proxy to all of the client sites, and manage who can see what VMs, networking/VLANS, and storage.

If I'm wrong about an assumption or solution, let me know!

@McHenry @nick-lloyd If you use an up to date stable (or latest) release channel in XOA you can use tags and maintain a list of clients and a customer number. Then you can use the custom tags (scoped tags) feature of Xen Orchestra to tag each client's pool(s) with a specific customer number tag (relevant to their list entry).

This feature was introduced in Xen Orchestra version 5.90, so is present in every version since then.

The tags will be applied to the VMs so each VM created self service by the client would be tagged with a scoped tag for their customer (client) number. The appropriate pools and thus their hosts would have an affinity for their customer number and anti affinity for other customer number.

john.c

@McHenry @nick-lloyd With todays release of Xen Orchestra (XOA) version 5.100 there's now support for custom ACLs based around tags. These will prove really useful when your setting up the XOA with its ACL for your clients to access self service, while ensuring that they can't access the other's pools and VMs etc.