Out of curiosity, I dumped the DMI into a bin and opened it up in a hex editor.
I am seeing ASCII of the ID, but also a variant encoded in binary. In both cases, its formatted as 0b08f477-491a-a982-23c4-d224723624ea.
I believe the ASCII version is the one that gets populated into the serial number as it comes after ASCII encoded versions of the 3 lines above it in the decode.
@dinhngtu Updated through xo. These are the current values.
mellanox-mlnxen.x86_64 5.9_0.5.5.0-2.1.xcpng8.3 @xcp:main/$releasever
python2-xapi-storage.x86_64 24.19.2-1.10.xcpng8.3 @xcp-ng-updates
xapi-core.x86_64 25.6.0-1.9.xcpng8.3 @xcp-ng-updates
xapi-nbd.x86_64 25.6.0-1.9.xcpng8.3 @xcp-ng-updates
xapi-rrd2csv.x86_64 25.6.0-1.9.xcpng8.3 @xcp-ng-updates
xapi-storage-script.x86_64 25.6.0-1.9.xcpng8.3 @xcp-ng-updates
xapi-tests.x86_64 25.6.0-1.9.xcpng8.3 @xcp-ng-updates
xapi-xe.x86_64 25.6.0-1.9.xcpng8.3 @xcp-ng-updates
xcp-ng-xapi-plugins.noarch 1.12.0-1.xcpng8.3 @xcp-ng-updates
xen-crashdump-analyser.x86_64 2.6.1-1.xcpng8.3 @xcp:main/$releasever
xen-dom0-libs.x86_64 4.17.5-15.1.xcpng8.3 @xcp-ng-updates
xen-dom0-tools.x86_64 4.17.5-15.1.xcpng8.3 @xcp-ng-updates
xen-hypervisor.x86_64 4.17.5-15.1.xcpng8.3 @xcp-ng-updates
xen-libs.x86_64 4.17.5-15.1.xcpng8.3 @xcp-ng-updates
xen-tools.x86_64 4.17.5-15.1.xcpng8.3 @xcp-ng-updates
xengt-userspace.noarch 4.0.0-1.xcpng8.3 @xcp:main/$releasever
xenopsd.x86_64 25.6.0-1.9.xcpng8.3 @xcp-ng-updates
xenopsd-cli.x86_64 25.6.0-1.9.xcpng8.3 @xcp-ng-updates
xenopsd-xc.x86_64 25.6.0-1.9.xcpng8.3 @xcp-ng-updates
xenserver-dracut.noarch 10-2.xcpng8.3 @xcp:main/$releasever
xenserver-hwdata.noarch 20240411-1.xcpng8.3 @xcp:main/$releasever
xenserver-status-report.noarch 2.0.11-1.xcpng8.3 @xcp-ng-updates
Gave one of the VMs a reboot and got the same result as previous.
Full DMI Decode as requested @TeddyAstie
# dmidecode
# dmidecode 3.5
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
19 structures occupying 691 bytes.
Table at 0xEE6FC000.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Xen
Version: 4.17
Release Date: 07/10/2025
Address: 0xE8000
Runtime Size: 96 kB
ROM Size: 64 kB
Characteristics:
PCI is supported
EDD is supported
Targeted content distribution is supported
BIOS Revision: 4.17
Handle 0x0100, DMI type 1, 27 bytes
System Information
Manufacturer: Xen
Product Name: HVM domU
Version: 4.17
Serial Number: 0b08f477-491a-a982-23c4-d224723624ea
UUID: 77f4080b-1a49-82a9-23c4-d224723624ea
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
Handle 0x0300, DMI type 3, 21 bytes
Chassis Information
Manufacturer: Xen
Type: Other
Lock: Not Present
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: Unknown
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: Unspecified
Contained Elements: 0
Handle 0x0401, DMI type 4, 35 bytes
Processor Information
Socket Designation: CPU 1
Type: Central Processor
Family: Other
Manufacturer: Intel
ID: F1 06 04 00 FF FB CB 0F
Version: Not Specified
Voltage: Unknown
External Clock: Unknown
Max Speed: 2100 MHz
Current Speed: 2100 MHz
Status: Populated, Enabled
Upgrade: Other
L1 Cache Handle: Not Provided
L2 Cache Handle: Not Provided
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0402, DMI type 4, 35 bytes
Processor Information
Socket Designation: CPU 2
Type: Central Processor
Family: Other
Manufacturer: Intel
ID: F1 06 04 00 FF FB CB 0F
Version: Not Specified
Voltage: Unknown
External Clock: Unknown
Max Speed: 2100 MHz
Current Speed: 2100 MHz
Status: Populated, Enabled
Upgrade: Other
L1 Cache Handle: Not Provided
L2 Cache Handle: Not Provided
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0403, DMI type 4, 35 bytes
Processor Information
Socket Designation: CPU 3
Type: Central Processor
Family: Other
Manufacturer: Intel
ID: F1 06 04 00 FF FB CB 0F
Version: Not Specified
Voltage: Unknown
External Clock: Unknown
Max Speed: 2100 MHz
Current Speed: 2100 MHz
Status: Populated, Enabled
Upgrade: Other
L1 Cache Handle: Not Provided
L2 Cache Handle: Not Provided
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0404, DMI type 4, 35 bytes
Processor Information
Socket Designation: CPU 4
Type: Central Processor
Family: Other
Manufacturer: Intel
ID: F1 06 04 00 FF FB CB 0F
Version: Not Specified
Voltage: Unknown
External Clock: Unknown
Max Speed: 2100 MHz
Current Speed: 2100 MHz
Status: Populated, Enabled
Upgrade: Other
L1 Cache Handle: Not Provided
L2 Cache Handle: Not Provided
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0405, DMI type 4, 35 bytes
Processor Information
Socket Designation: CPU 5
Type: Central Processor
Family: Other
Manufacturer: Intel
ID: F1 06 04 00 FF FB CB 0F
Version: Not Specified
Voltage: Unknown
External Clock: Unknown
Max Speed: 2100 MHz
Current Speed: 2100 MHz
Status: Populated, Enabled
Upgrade: Other
L1 Cache Handle: Not Provided
L2 Cache Handle: Not Provided
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0406, DMI type 4, 35 bytes
Processor Information
Socket Designation: CPU 6
Type: Central Processor
Family: Other
Manufacturer: Intel
ID: F1 06 04 00 FF FB CB 0F
Version: Not Specified
Voltage: Unknown
External Clock: Unknown
Max Speed: 2100 MHz
Current Speed: 2100 MHz
Status: Populated, Enabled
Upgrade: Other
L1 Cache Handle: Not Provided
L2 Cache Handle: Not Provided
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0B00, DMI type 11, 5 bytes
OEM Strings
String 1: Xen
String 2: MS_VM_CERT/SHA1/bdbeb6e0a816d43fa6d3fe8aaef04c2bad9d3e3d
Handle 0x1000, DMI type 16, 15 bytes
Physical Memory Array
Location: Other
Use: System Memory
Error Correction Type: Multi-bit ECC
Maximum Capacity: 24568 MB
Error Information Handle: Not Provided
Number Of Devices: 2
Handle 0x1100, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x1000
Error Information Handle: 0x0000
Total Width: 64 bits
Data Width: 64 bits
Size: 16 GB
Form Factor: DIMM
Set: None
Locator: DIMM 0
Bank Locator: Not Specified
Type: RAM
Type Detail: None
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x1300, DMI type 19, 15 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x003FFFFFFFF
Range Size: 16 GB
Physical Array Handle: 0x1000
Partition Width: 1
Handle 0x1400, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x003FFFFFFFF
Range Size: 16 GB
Physical Device Handle: 0x1100
Memory Array Mapped Address Handle: 0x1300
Partition Row Position: 1
Handle 0x1101, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x1000
Error Information Handle: 0x0000
Total Width: 64 bits
Data Width: 64 bits
Size: 8184 MB
Form Factor: DIMM
Set: None
Locator: DIMM 1
Bank Locator: Not Specified
Type: RAM
Type Detail: None
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x1301, DMI type 19, 15 bytes
Memory Array Mapped Address
Starting Address: 0x00400000000
Ending Address: 0x005FF7FFFFF
Range Size: 8184 MB
Physical Array Handle: 0x1000
Partition Width: 1
Handle 0x1401, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00400000000
Ending Address: 0x005FF7FFFFF
Range Size: 8184 MB
Physical Device Handle: 0x1101
Memory Array Mapped Address Handle: 0x1301
Partition Row Position: 1
Handle 0x2000, DMI type 32, 11 bytes
System Boot Information
Status: No errors detected
Handle 0xFEFF, DMI type 127, 4 bytes
End Of Table
Only difference looks to be xen-dom0 etc. on 4.17.5-13.1.xcpng8.3 vs your 4.17.5-15.2.xcpng8.3
# unbuffer yum list installed | grep xen\\\|xapi
mellanox-mlnxen.x86_64 5.9_0.5.5.0-2.1.xcpng8.3 @xcp:main/$releasever
python2-xapi-storage.x86_64 24.19.2-1.10.xcpng8.3 @xcp-ng-updates
xapi-core.x86_64 25.6.0-1.5.xcpng8.3 @xcp-ng-updates
xapi-nbd.x86_64 25.6.0-1.5.xcpng8.3 @xcp-ng-updates
xapi-rrd2csv.x86_64 25.6.0-1.5.xcpng8.3 @xcp-ng-updates
xapi-storage-script.x86_64 25.6.0-1.5.xcpng8.3 @xcp-ng-updates
xapi-tests.x86_64 25.6.0-1.5.xcpng8.3 @xcp-ng-updates
xapi-xe.x86_64 25.6.0-1.5.xcpng8.3 @xcp-ng-updates
xcp-ng-xapi-plugins.noarch 1.12.0-1.xcpng8.3 @xcp-ng-updates
xen-crashdump-analyser.x86_64 2.6.1-1.xcpng8.3 @xcp:main/$releasever
xen-dom0-libs.x86_64 4.17.5-13.1.xcpng8.3 @xcp-ng-updates
xen-dom0-tools.x86_64 4.17.5-13.1.xcpng8.3 @xcp-ng-updates
xen-hypervisor.x86_64 4.17.5-13.1.xcpng8.3 @xcp-ng-updates
xen-libs.x86_64 4.17.5-13.1.xcpng8.3 @xcp-ng-updates
xen-tools.x86_64 4.17.5-13.1.xcpng8.3 @xcp-ng-updates
xengt-userspace.noarch 4.0.0-1.xcpng8.3 @xcp:main/$releasever
xenopsd.x86_64 25.6.0-1.5.xcpng8.3 @xcp-ng-updates
xenopsd-cli.x86_64 25.6.0-1.5.xcpng8.3 @xcp-ng-updates
xenopsd-xc.x86_64 25.6.0-1.5.xcpng8.3 @xcp-ng-updates
xenserver-dracut.noarch 10-2.xcpng8.3 @xcp:main/$releasever
xenserver-hwdata.noarch 20240411-1.xcpng8.3 @xcp:main/$releasever
xenserver-status-report.noarch 2.0.11-1.xcpng8.3 @xcp-ng-updates
Ah, I see the pattern now. That is bizarre.
deef@k31-w-3bfbbe:~$ sudo cat /sys/devices/virtual/dmi/id/product_serial
0b08f477-491a-a982-23c4-d224723624ea
deef@k31-w-3bfbbe:~$ sudo cat /sys/devices/virtual/dmi/id/product_uuid
77f4080b-1a49-82a9-23c4-d224723624ea
deef@k31-w-3bfbbe:~$ sudo cat /sys/hypervisor/uuid
0b08f477-491a-a982-23c4-d224723624ea
Heres the output from a series of commands I ran to get the info of the worker. Seeing 6.8 and 24.04 myself.
deef@k31-w-3bfbbe:~$ cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="Ubuntu 24.04.2 LTS"
PRETTY_NAME="Ubuntu 24.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.2 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo
deef@k31-w-3bfbbe:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.2 LTS
Release: 24.04
Codename: noble
deef@k31-w-3bfbbe:~$ hostnamectl
Static hostname: k31-w-3bfbbe
Icon name: computer-vm
Chassis: vm 🖴
Machine ID: 9bae21fe1e10d9da92da72599fd7b4a3
Boot ID: 959ebf2dc51e403eaf00103d51e8397e
Virtualization: xen
Operating System: Ubuntu 24.04.2 LTS
Kernel: Linux 6.8.0-64-generic
Architecture: x86-64
Hardware Vendor: Xen
Hardware Model: HVM domU
Firmware Version: 4.17
Firmware Date: Tue 2025-05-13
Firmware Age: 2month 2w 3d
deef@k31-w-3bfbbe:~$ uname -r
6.8.0-64-generic
LMK if there is anything else you want me to throw at it, or any other debug info you want me to get. I'm out of my depth when it comes to debugging this kind of thing.
@Cyrille I am seeing /sys/hypervisor/uuid matching dmidecode's Serial Number matching VM ID in xen orchestra.
dmidecode's UUID however is different from those three.
@Cyrille Genuinly no idea unfortunately. The only thing I can think that I've done is that the VMs are being loaded in from a template.
I had to deploy new VMs through my terraform recently, and I AM still seeing an incorrect system UUID on those, so I can only guess its somehow the template?
I am also seeing the serial number from DMIDECODE match the VM ID in xen orchestra as well still.
@Cyrille It would be nice if (assuming integration with the ccm) there was a way to integrate the horizontal scaling tooling that exists to automatically scale up&down (setting minimum/maximum VM counts), but that is 100% out of scope for the CCM as is Im sure.
If you are asking for a dream wishlist tho, Id love if I could
@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.
Ok, Looking through the logs when creating a new cluster, I just noticed something I missed. I screwed up the CIDR notation.
Im surprised the fiends aren't validated on creation.
I've been looking forward to the k8s cluster recipe for some time, but have only gotten a chance to experiment with it today.
I created a quick cluster with 5 nodes, and while the images all created, k8s never started. As far as I am aware, it should be plug and play yes? or am I missing something? I cant find the documentation other than the blog post announcing it.