@olivierlambert I already have an issue liked in my original post. do you want me to make a new issue about how the vm Id is retrieved? or just comment on the issue I already have?

@olivierlambert Unfortunatly, the UUID is getting pulled by kubernetes itself for XO-CCM, so I have no control over that that Im aware.

OK. back where I started. that was a garbage AI-written "help" article that just spewed out garbage commands as if they actually worked. Still looking for a way to resetset the dmi UUID

@olivierlambert Ah. Ok. It looks like I can update the system uuid via

sudo dmidecode -s system-uuid -s <new_uuid>

found from here, but if you happen to know if that should work, Id love a confirmation before I go and make a mess of a worker node.

This is related to a bug I filed on the XO-CCM (which is why I put it here). I have a series of Kubernetes worker node VM's created by loading the a base k8s node from a template. It appears that in this process, the UUID returned from dmidecode has been changed and does not reflect the UUID in XO.

I was wondering if there was a way to get the UUID to match up again so that I can get the CCM to start functioning.

@nathanael-h yeah, the installation finished, tho as mentioned above I would prefer to assign my ips via dhcp, so it's not perfect.

(mind, I'm currently using a manually deployed cluster just fine, so I'm in no rush to really figure out why the automatic ups are failing)

Unrelated, are there plans to eventually allow for up/down scaling the recipe later? With the CCM, setting up vm auto scaling should be possible if the recipe supports it right?

@Cyrille The network does have the ability to reach out to the internet to update&install.

Ive attempted to do an install with Manually entering some IPs. That does appear to be getting it to go further along the initialization process.

The control plane atleast was able to reach a point where it could show me the login prompt, and the worker appears to be installing now.

Hihi @Cyrille

Confirmed the IP is getting set in DHCP as expected in my router & the data all looks correct as to what I would expect it to be.

I am able to ping the address, but ssh still just connection-refused's me.

Rebooting the VM to attempt to force it is resulting in the same ssh result.

For some details that might help, pool-wide eth5 is the network that all my other VMs are on, and is the only one actively connected to the network. 0-4 are all unplugged. The listed NFS storage is a networked storage, not an on-machine storage (hosted on truenas, thus its name)

I tried using a different network real quick just to see, and got the same results as previously (tho with no DHCP assigned as the network is not connected to my DHCP server) with getting stuck at 4 seconds before spewing out that table at 400~ with the network info.

Ive Attempted to create a kubernetes cluster using the recipe several times now on several different versions of Xen Orchestra (most recently on the just released latest, 5.108), but have never managed to get any particular configuration of settings to load. The first VM initialized always gets stuck, and at what appears to be quite an early step.

The VM will load and show grub, and start up, but then hang at the cloud-init log line. (apperently attempting to raise network interfaces)

When I initialized the cluster from the settings, I did not pick specific IP addresses as I use DHCP to centralize control of IP addresses.

Ive tried to SSH into the machine to determine what is wrong from logs, but have been unable to connect. I am unsure what to do from here to debug this situation.

Assistance is appreciated. Thanks.

Thanks for the tip. Requested.