Using tags or custom fields for VM placement
-
Affinity is only for one host. Also, affinity is just a preference on placement when you boot the VM, not after that. You must use the load balancer plugin to manage placement for running VMs.
-
@olivierlambert OK, then perhaps you could update the UI please, because it shows "host(s)", indicating that you can select more than one.
It would also be really helpful if the docs could show how to configure this, please.
I have multiple servers in one pool. There are two different types of servers, type A and type B. How can I guarantee that my special VMs with tags "type_a" ONLY run on the type A servers? I am not concerned with anti-affinity to the other VMs running on the host.
If we cannot do it, that is fine, we will find another solution. It is easy with VMware or CloudStack for example. However I would REALLY like to deploy XOA premium in our company. But this functionality is a showstopper for us.
Many thanks,
Graham -
I checked in XAPI, indeed it's one host only. For the UI, I'm afraid that's a component that will be hard to modify, but be assured we'll make it clear for our next UI revamp
About your request (enforce that VMs with specific tags running on specific hosts), it seems doable, like "tag affinity" or something, to monitor and enforce that during all the VM life (when running). On boot, it's not possible, but if it's quickly migrated afterward, is it OK? (you can also select to boot on a specific host manually, and then the load balancer will enforce it)
-
@graham_p Just write a simple script to check what host the VMs re running on and migrate them VMs as needed to the appropriate host. You can check the host its running on with a cron or similar scheduler as well as hard-code the migrtion options. There is no way to ensure what host a VM will start on in a pool, other than to some degree through WLB, and that still only will optimize according to its limited options.
-
@tjkreidl we have an XO plugin that is doing what WLB does
I think it's not that hard to get an "tag affinity" feature, since we already have "anti affinity" 
-
@olivierlambert @olivierlambert Yes, it is "tag affinity" that we need exactly in this case.
Agreed we could start the VM on one of the correct hosts, so that is good. The load balancer needs to keep it running on a host with the correct tags (and HA failover to the correct tagged hosts as well.)
@tjkreidl thanks for the information. We are trying to get away from the simple scripts
which end up as a monster. But I do appreciate the suggestion.To give you some more background examples of how we would use the tags:
-
CPU clock speed. We have some servers with much faster CPU that are used for running very long simulation jobs (over several days) on multiple cores in parallel. We would want to start the simulation VMs on any free host with the right clock tags.
-
Custom hardware. Some servers are fitted with custom PCIe cards and some VMs need to target the right hardware.
A lot of the config / VM startup will be done with automation. I will also have a look at the APIs as well.
Many thanks for your time.
Graham -
-
Thanks for the context. That would be wonderful if you can contact us via https://vates.tech/contact/ so we can have a phone call to understand most of the details, and talk about prioritizing this feature in our roadmap.
-
@graham_p Sounds like a configuration to do this would include the following:
- List of hosts in order of preference the VM should run on, with automatic fallback in order of priority.
- List of hosts to not start the VM on, no matter what
- Means of notifying sysadmins of changes (email?) or at least add additional logging information.
@olivierlambert , that would be great if those features could be incorporated!
-
The most straightforward path is to add an affinity mode in our existing load balancer plugin, with a "map" between tags and hosts. This way, the LB will enforce placement of VMs while they run.
-
@olivierlambert Was this ever added to the roadmap?
I recently had a power failure which took down my entire setup. Upon starting the pool master, I was unable to connect to XO because it had been running on another host. If I had an affinity tag I could set XO to prefer to run on the master.
This way I could more easily check the status of each thing as I brought it back online. Instead, I had to boot the entire pool because the master thought that XO was still running on the other host.
-
I'm in a train, almost 3h late and it's the end of the week, so my brain is a bit slow. I'm not sure to understand how XO LB could have help in that context? Remember that VM placement on boot is handled by XAPI, not XO.
-
@olivierlambert No worries. I really was just asking about the status of affinity tags.
-
So placement on boot falls under XAPI realm: where to start a VM (eg you have affinity host). But when the VM is up, XAPI won't do anything else, and it's up to the XO LB plugin. If your problem is on boot, then use affinity host setting in XAPI (you can configure it from XO UI). If it's after boot, then we can discuss how to deal with it in XO LB
-
@olivierlambert The LB plugin is what I'm referring to. I'd like to keep XO on the master but currently there's no way to do that. As you mentioned, if I set boot affinity there's nothing preventing it from getting load balanced to another host.
-
Okay so to have the LB taking into account the XAPI host affinity if possible, right?
-
@olivierlambert I was thinking of tags like the anti-affinity ones but the XAPI host affinity would work as well. I'm not sure if it would work for the OP's use case, though.
-
For my original use case, "affinity" isn't quite strong enough. This VM "X" MUST run on a host with tag "Y". If no resource is available on a host with tag Y, don't start X.
-
So it's better to NOT have the VM running than running on another host, right?
-
@olivierlambert in my original case - yes.
For example, if the VM needs PCI passthrough to a specific device (or very fast network or fast CPU in one or two servers in the larger pool) it is absolutely better not to start the VM, because the VM is useless without this resource.
(Like a hard affinity to a tag - not a single host - which takes priority over general softer affinity settings).
(I do realise that this is complex and a big ask!)
-
It's already the case: you won't be able to boot a VM on another host with hard requirements (like local SR or PCI passthrough). It will simply not boot.
