Choosing cluster when instantiating service template

Community Support
1

When instantiating a service template it by default deploys the VM’s on CLUSTER_ID=0 while it should be deployed on CLUSTER_ID=100

Versions of the related components and OS (frontend, hypervisors, VMs):
hypervisor: KVM
OpenNebula 6.10.0
Service template: Service OneKE 1.29

Steps to reproduce:
oneflow-template instantiate ‘Service OneKE 1.29’ /tmp/OneKE-instantiate

using default parameters with only adjusted network ID’s.

Current results:

The first VM keeps in state pending with the following error message:

Fri Jan 10 17:36:40 2025: Cannot dispatch VM: No host meets capacity and SCHED_REQUIREMENTS: (CLUSTER_ID = 0) & !(PUBLIC_CLOUD = YES) & !(PIN_POLICY = PINNED)

The VM template has the following entry:

{
  "AUTOMATIC_DS_REQUIREMENTS": "(\"CLUSTERS/ID\" @> 0)",
  "AUTOMATIC_NIC_REQUIREMENTS": "(\"CLUSTERS/ID\" @> 0)",
  "AUTOMATIC_REQUIREMENTS": "(CLUSTER_ID = 0) & !(PUBLIC_CLOUD = YES) & !(PIN_POLICY = PINNED)",
  "CONTEXT": {
    ...

Expected results:

Some way to specify the correct cluster when instantiating the service template resulting in deployment of VM’s the correct way.

2

Hello @geerd and welcome to this forum, hope we can help you with your issue.

For the service, every time you initiate an instance, the system automatically assigns VMs to a default cluster, often CLUSTER_ID=0.
In order to deploy VMs to a specific cluster, such as CLUSTER_ID=100, you can adjust the scheduling requirements in the VM template associated with your service template.

You need to find the SCHED_REQUIREMENTS attribute, on the template and adjust it to 100 (or the desired value).

Let me know if it works.

Cheers,

3

Thanks. I have added SCHED_REQUIREMENTS to the template but now it tries to schedule to both clusters. The following error is shown when trying to deploy the VM:

Mon Jan 13 11:10:25 2025: Cannot dispatch VM: No host meets capacity and SCHED_REQUIREMENTS: (CLUSTER_ID = 0) & !(PUBLIC_CLOUD = YES) & !(PIN_POLICY = PINNED) & ( (HYPERVISOR=kvm) & (CLUSTER_ID = 100) )

The adjusted VM template with the SCHED_REQUIREMENTS at the end:

{
  "CONTEXT": {
    "NETWORK": "YES",
    "ONEAPP_VNF_DNS_ENABLED": "$ONEAPP_VNF_DNS_ENABLED",
    "ONEAPP_VNF_DNS_INTERFACES": "$ONEAPP_VNF_DNS_INTERFACES",
    "ONEAPP_VNF_DNS_NAMESERVERS": "$ONEAPP_VNF_DNS_NAMESERVERS",
    "ONEAPP_VNF_DNS_USE_ROOTSERVERS": "NO",
    "ONEAPP_VNF_HAPROXY_ENABLED": "YES",
    "ONEAPP_VNF_HAPROXY_INTERFACES": "$ONEAPP_VNF_HAPROXY_INTERFACES",
    "ONEAPP_VNF_HAPROXY_LB0_IP": "$ONEAPP_VNF_HAPROXY_LB0_IP",
    "ONEAPP_VNF_HAPROXY_LB0_PORT": "$ONEAPP_VNF_HAPROXY_LB0_PORT",
    "ONEAPP_VNF_HAPROXY_LB1_IP": "$ONEAPP_VNF_HAPROXY_LB1_IP",
    "ONEAPP_VNF_HAPROXY_LB1_PORT": "$ONEAPP_VNF_HAPROXY_LB1_PORT",
    "ONEAPP_VNF_HAPROXY_LB2_IP": "$ONEAPP_VNF_HAPROXY_LB2_IP",
    "ONEAPP_VNF_HAPROXY_LB2_PORT": "$ONEAPP_VNF_HAPROXY_LB2_PORT",
    "ONEAPP_VNF_HAPROXY_LB3_IP": "$ONEAPP_VNF_HAPROXY_LB3_IP",
    "ONEAPP_VNF_HAPROXY_LB3_PORT": "$ONEAPP_VNF_HAPROXY_LB3_PORT",
    "ONEAPP_VNF_HAPROXY_ONEGATE_ENABLED": "YES",
    "ONEAPP_VNF_HAPROXY_REFRESH_RATE": "$ONEAPP_VNF_HAPROXY_REFRESH_RATE",
    "ONEAPP_VNF_KEEPALIVED_ETH0_SKIP": "YES",
    "ONEAPP_VNF_NAT4_ENABLED": "$ONEAPP_VNF_NAT4_ENABLED",
    "ONEAPP_VNF_NAT4_INTERFACES_OUT": "$ONEAPP_VNF_NAT4_INTERFACES_OUT",
    "ONEAPP_VNF_ROUTER4_ENABLED": "$ONEAPP_VNF_ROUTER4_ENABLED",
    "ONEAPP_VNF_ROUTER4_INTERFACES": "$ONEAPP_VNF_ROUTER4_INTERFACES",
    "ONEAPP_VROUTER_ETH0_VIP0": "$ONEAPP_VROUTER_ETH0_VIP0",
    "ONEAPP_VROUTER_ETH1_VIP0": "$ONEAPP_VROUTER_ETH1_VIP0",
    "ONE_SERVICE_AIRGAPPED": "NO",
    "REPORT_READY": "YES",
    "SERVICE_ID": "$SERVICE_ID",
    "SSH_PUBLIC_KEY": "$USER[SSH_PUBLIC_KEY]",
    "TOKEN": "YES"
  },
  "CPU": "2",
  "DISK": {
    "IMAGE_ID": "15"
  },
  "GRAPHICS": {
    "LISTEN": "0.0.0.0",
    "TYPE": "vnc"
  },
  "LXD_SECURITY_PRIVILEGED": "true",
  "MEMORY": "4096",
  "NIC_DEFAULT": {
    "MODEL": "virtio"
  },
  "OS": {
    "ARCH": "x86_64"
  },
  "SCHED_REQUIREMENTS": "(HYPERVISOR=kvm) & (CLUSTER_ID = 100)"
}

When looking at the VM that is being deployed in Sunstone under template, the same rules were added as previously:

{
  "AUTOMATIC_DS_REQUIREMENTS": "(\"CLUSTERS/ID\" @> 0)",
  "AUTOMATIC_NIC_REQUIREMENTS": "(\"CLUSTERS/ID\" @> 0)",
  "AUTOMATIC_REQUIREMENTS": "(CLUSTER_ID = 0) & !(PUBLIC_CLOUD = YES) & !(PIN_POLICY = PINNED)",
  "CONTEXT": {
...

Any idea how to change this behaviour?

Thanks!
Geerd

4

Now it works. The issue was that one of the networks did not belong to cluster 100. By adding the network to this cluster there was no network cluster imposed anymore:

onecluster addvnet 100 8

When looking at template in the dashboard this is stated:

{
  "AUTOMATIC_DS_REQUIREMENTS": "(\"CLUSTERS/ID\" @> 0 | \"CLUSTERS/ID\" @> 100)",
  "AUTOMATIC_NIC_REQUIREMENTS": "(\"CLUSTERS/ID\" @> 0 | \"CLUSTERS/ID\" @> 100)",
  "AUTOMATIC_REQUIREMENTS": "(CLUSTER_ID = 0 | CLUSTER_ID = 100) & !(PUBLIC_CLOUD = YES) & !(PIN_POLICY = PINNED)",