@McHenry said in pfSense Guest Tools: I have been using pfSense with xcp-ng for a while now without installing the guest tools. Due to some networking complications I have decided to install the guest tools to eliminate this as the cause. Q1) Are the guest tools required on pfSense and what do they do? Actually no, their main functionnality is to provide some data (memory usage, IPs) to XCP-ng to report them upward, AFAICT, it doesn't impact behavior in a significant way. It's actually not "PV drivers". Q2) Are these tools being maintained? This version of the guest agent is very limited and ancient (I don't exactly what it does, but not much IIRC). We're working on a new guest agent in Rust, which actually works pretty well on Linux, Windows (actually used in latest Windows drivers) and FreeBSD (NetBSD is also possible, but current code lacks some platform-specific bits). But we still need to sort-out some issues (some technical and some others non-technical) before making it broadly available / making it packaged.

I see, it also says name ( RO): sdn-controller-ca.pem host ( RO): <not in database> Like in the issue, but the file exists. [11:28 ovbh-pprod-xen05 ~]# xe certificate-list uuid ( RO) : afdd9c8e-dcae-17c7-c35c-0fd7cebd387a type ( RO): host name ( RO): host ( RO): f0cec10f-ad05-48e4-893c-414b3a3e15be not-before ( RO): 20251110T23:15:51Z not-after ( RO): 20351108T23:15:51Z fingerprint ( RO): BF:83:23:BB:7B:E9:30:DE:86:EA:9D:AF:DF:F8:BA:34:39:D0:81:AD:34:E5:C6:AB:0C:49:41:7B:4A:3C:8B:9E uuid ( RO) : b8dcd1f0-ef65-e762-f189-46bb78766c6b type ( RO): ca name ( RO): sdn-controller-ca.pem host ( RO): <not in database> not-before ( RO): 20200416T00:17:31Z not-after ( RO): 20470901T00:17:31Z fingerprint ( RO): 63:1F:89:3F:0E:1F:86:52:34:95:3C:6C:3F:9C:C8:B3:5A:61:6B:4D:EE:8F:A7:11:F0:BA:79:8B:C7:15:A0:E0 uuid ( RO) : e7daedf2-7f35-ba40-093a-e0c011d91633 type ( RO): host_internal name ( RO): host ( RO): f0cec10f-ad05-48e4-893c-414b3a3e15be not-before ( RO): 20251110T23:15:46Z not-after ( RO): 20351108T23:15:46Z fingerprint ( RO): 71:41:B0:25:88:AA:E4:56:EE:F7:A9:8E:0A:A9:FE:C5:6A:0D:D5:37:30:BF:C8:81:C2:D7:B8:20:7A:6C:7F:B7 [13:50 ovbh-pprod-xen05 ~]# ll /etc/stunnel/certs/sdn-controller-ca.pem -rw-r--r-- 1 root root 1907 Nov 12 09:45 /etc/stunnel/certs/sdn-controller-ca.pem Removing it did not help, same error [13:54 ovbh-pprod-xen05 ~]# xe certificate-list uuid ( RO) : afdd9c8e-dcae-17c7-c35c-0fd7cebd387a type ( RO): host name ( RO): host ( RO): f0cec10f-ad05-48e4-893c-414b3a3e15be not-before ( RO): 20251110T23:15:51Z not-after ( RO): 20351108T23:15:51Z fingerprint ( RO): BF:83:23:BB:7B:E9:30:DE:86:EA:9D:AF:DF:F8:BA:34:39:D0:81:AD:34:E5:C6:AB:0C:49:41:7B:4A:3C:8B:9E uuid ( RO) : e7daedf2-7f35-ba40-093a-e0c011d91633 type ( RO): host_internal name ( RO): host ( RO): f0cec10f-ad05-48e4-893c-414b3a3e15be not-before ( RO): 20251110T23:15:46Z not-after ( RO): 20351108T23:15:46Z fingerprint ( RO): 71:41:B0:25:88:AA:E4:56:EE:F7:A9:8E:0A:A9:FE:C5:6A:0D:D5:37:30:BF:C8:81:C2:D7:B8:20:7A:6C:7F:B7 I also confirmed that all the certs for the hosts are current and not expired.

That's unrelated. This might need a deeper investigation, I'm not sure to get why nothing is displayed while you have a working IPMI plugin…

@cmanos No problem, glad I could helped. As Olivier also pointed above, it's not an issue anymore when using QCOW2 which is currently in beta, so hopefully it's only a short workaround

@edsilber After exploring the UI, I confirmed that it's not possible to schedule a one-time cron job from the XO-5 interface. We're prioritizing the development of new features for XO-6, so we'll take your suggestions regarding scheduling into account for the new interface. I propose an alternative: using the REST API to run schedules by creating your own execution script (if you are on linux: https://www.veeble.com/kb/scheduling-one-time-jobs-in-linux-using-at-command/). The REST API link is: {your-xo-url}/rest/v0/docs/#/schedules Please feel free to contact me if you have any further questions.

@dinhngtu Hi For my i made on offline Install to solve my issue, installed failed when downloading the kernel from servers, so offline install worked fine for me.

@olivierlambert Thought so just wanted to check. Thank you.

See https://docs.xen-orchestra.com/load_balancing

The problem with those providers is, that the additional IP is usually L3 routed to the physical hosts IP. A better solution would be to get a /29 subnet or similar, where the gateway is handled by the provider and then configure that subnet on a specific VLAN which is available on all hosts where you want the VM's to be able to run. More work for the provider, since they have to setup the gateway IP within the /29 subnet on their router and then configure the VLAN on the switchports towards your hosts, but its the best way to make the VM's agile.

Ping @mathieuRA about this

@Andrew Hey budd, thanks for the pointer. That ISO worked, thanks.

@lsouai-vates Thanks for the response. I was just looking for a way to create a full screen display for a NOC, without requiring interactive login. Sounds like that's not possible at the moment?

i found that whole pool is not alive enough. Can't reboot or mirgate anything. Have issue only with this 1 pool. Is it safe to reboot hosts? https://paste.vates.tech/?7e565d3abe23fd11#7JcQbjRguFpNfw281asxdmb2Zrd7GKXpuE17iDtwt3KG

@Danp Yup, that fixed the time and the logs also. Thanks! [12:42 19] xoa@xoa:~$ timedatectl Local time: Sun 2025-10-19 12:42:55 EDT Universal time: Sun 2025-10-19 16:42:55 UTC RTC time: Sun 2025-10-19 16:42:55 Time zone: America/New_York (EDT, -0400) System clock synchronized: yes NTP service: active RTC in local TZ: no [12:42 19] xoa@xoa:~$ last reboot reboot system boot 6.1.0-40-amd64 Sun Oct 19 12:42 still running reboot system boot 6.1.0-40-amd64 Sun Oct 19 08:27 - 12:42 (04:15) reboot system boot 6.1.0-40-amd64 Sun Oct 19 08:18 - 08:26 (00:08) reboot system boot 6.1.0-40-amd64 Sat Oct 18 15:16 - 08:17 (17:01)

Don't worry, you did right to ask! Quick explanation: it's exposed in XO because it's a special parameter given to the VM (a kind of a special device) detected by Windows, making it install the driver for it.

Good catch Dan and good decision @McHenry Even if you don't run VM, dom0 is used for VM transfer/backup/replication, so having 4GiB or RAM is a lot better in your case

@Kptainflintt said in Cloning Windows 11 with vTPM: No reply to this topic but just seen same thing. And same "workaround" : disabling vTPM at VM creation from template to avoid crashing. I can confirm that XOA want to add a second vTPM, any fix ? Sharing for temporal context: This appears to still be be happening when creating a VM using my custom Windows 11 template (didn't do any cloudbase stuff, just some really basic stuff like updates, then sysprep). Once I click "Open advanced settings" then toggle "Enable vTPM" into the disabled state, my attempt to create the VM succeeds, and the newly cloned VM has a vTPM with a different UUID. This is literally my first attempt at creating and then cloning a windows 11 template, but it seems to be working.

@McHenry like @olivierlambert said, keep in mind that a VM with 16 CPUs will be less available than a VM with 4 vCPUs, because it's easier to have 4 vCPUs ready to work than 16 simultaneously beware of this graph, it only graph the first 16 vCPU, but you can have more working ! the visual widget is failing you. think of topology too : if you have two sockets, you can have a topology of 2 sockets with 4 cores for a 8 vCPU VM. If you have only one socket, try to keep the topology to "1 socket xx cores" for your VMs, performance wise.

@psafont thats good to know the system will prevent you from uploading the same ISO. Since my latest testing i cant seeem to get XO-CE to show the incorrect file name .img of the iso that was uploaded. But know @plaidypus is not alone in this as I have seen it myself and that is why you will see most of the iso in the picture have a date just a few days prior to this recent testing. I manually deleted the iso that were .img and manually uploaded the ISOs again.

@Pilow said in "ACLs" and "VM creator" options on the VM´s Advanced tab: @panzersrmm I tried to snapshot and revert on a VM with Resource set + ACLs and they did not disappear... ? [image: 1759935440961-b316a971-e2cf-4843-9d05-a96b2299d12a-image.png] @Pilow Yes, yours were kept because you didn't modify them manually. My test case was: Set ACLs + VM creator for a working VM Make a snapshot of this VM Change various VM advanced properties including ACLs + VM creator (simulate evolution of VM) Revert the VM to that snapshot state Check if the set properties were restored: all were restored except ACLs I was wrong about VM creator. That is indeed restored, but ACLs isn't. @olivierlambert Thank you for the explanation. I wasn't trying to judge, just to understand how it actually works.