I do have active directory setup in my lab environment. I just need to set aside some time to try it out between two domain joined hosts.
Thanks for trying that! That's some good debugging.
I do have active directory setup in my lab environment. I just need to set aside some time to try it out between two domain joined hosts.
Thanks for trying that! That's some good debugging.
Does XO support putting sec=krb5p in the custom mount options field for NFS remotes? Has anyone set this up?
Background on sec=krb5p and what the client needs:
https://man7.org/linux/man-pages/man5/nfs.5.html (Security Considerations)
https://man7.org/linux/man-pages/man8/rpc.gssd.8.html
@Greg_E Hello, I've gotten combustion to work just fine. You upload your combustion.vhd to an SR (not iso storage) and make sure you're using the selfinstall.iso. Then uncheck boot VM after creation so that you can mount the combustion.vhd on the next screen. Then after mounting it startup the VM and it should recognize it and start the provisioning process.
@Danp alright, thanks. I'll give that a try.
@danp The POST /vbds endpoint allows configuring both "RW" or "RO" and a bootable Boolean.
If I need to mount an OS installation ISO and a separate provisioning VDI to the same VM, I assume I must execute two distinct POST /vbds requests:
For the CD-ROM (ISO): Set "mode": "RO" and "bootable": true.
For the provisioning VDI: Set "mode": "RW" and "bootable": false.
Would this work in mounting my OS .iso to my VM in the CD-ROM and also mount the VDI to the vm so it will read it on first boot?
{
"VM": "VM-UUID",
"VDI": "VDI-UUID",
"bootable": false,
"mode": "RW"
}
@Danp How about the CD-ROM with the .iso? Can i mount that on the VM using these also ?
@Danp They're all GET methods no way to mount anything.

@Danp Thanks! Also, I converted my VM to a template and it had the .iso in it prior to doing that but then when i spin it up from the REST API the .iso is gone?
I am automating VM deployments using XOA's REST API. I am successfully deploying a VM from a template and uploading a VHD to one of my SRs. The final step in my automated deployment is attaching this existing VHD that i uploaded to the newly created, halted VM.
I also need to select which .iso is inserted into the CD drive. Is that something configured at the template level? I thought I had done that prior to converting my template.
I saw some discussions about attaching an existing VDI a year ago in the forums, so I am not sure if anyone has asked recently. I am not sure if attaching a disk to a stopped VM after it was newly created is an endpoint I might have missed.
Is this handled under an action sub-URL?
@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)
I ran that tool and tried both the US/Eastern and America/New_York but I'm still getting a time zone that does not account for daylight savings time. I did reboot inbetween each different sudo dpkg-reconfigure tzdata region selection.
[07:22 19] xoa@xoa:timesyncd.conf.d$ sudo dpkg-reconfigure tzdata
Current default time zone: 'US/Eastern'
Local time is now: Sun Oct 19 08:23:19 EDT 2025.
Universal Time is now: Sun Oct 19 12:23:19 UTC 2025.
[07:24 19] xoa@xoa:timesyncd.conf.d$ sudo dpkg-reconfigure tzdata
Current default time zone: 'America/New_York'
Local time is now: Sun Oct 19 08:25:59 EDT 2025.
Universal Time is now: Sun Oct 19 12:25:59 UTC 2025.
[07:27 19] xoa@xoa:~$ date
Sun Oct 19 07:27:30 AM EST 2025
[07:27 19] xoa@xoa:~$ last reboot
reboot system boot 6.1.0-40-amd64 Sun Oct 19 07:27 still running
reboot system boot 6.1.0-40-amd64 Sun Oct 19 07:18 - 07:26 (00:08)
Hello, the time looks correct when i run timedatectl. However, you can see that that the time in my bash prompt is not correct. This is in a different timezone. The logs are also an hour off. Is this a bug? I can't find a time setting inside XOA. How does the env variable get updated?
[14:21 18] xoa@xoa:~$ timedatectl
Local time: Sat 2025-10-18 15:24:17 EDT
Universal time: Sat 2025-10-18 19:24:17 UTC
RTC time: Sat 2025-10-18 19:24:17
Time zone: US/Eastern (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
[14:24 18] xoa@xoa:~$
[14:24 18] xoa@xoa:~$ echo $TZ
EST
[14:24 18] xoa@xoa:~$
[14:24 18] xoa@xoa:~$ last reboot
reboot system boot 6.1.0-40-amd64 Sat Oct 18 14:16 still running
reboot system boot 6.1.0-40-amd64 Sat Oct 18 14:14 - 14:15 (00:01)
reboot system boot 6.1.0-40-amd64 Fri Oct 17 20:24 - 08:55 (12:30)
reboot system boot 6.1.0-40-amd64 Fri Oct 17 20:21 - 20:24 (00:03)
reboot system boot 6.1.0-40-amd64 Fri Oct 17 20:12 - 20:20 (00:08)
@olivierlambert Good morning, I thought maybe there would be a way to re-install with UEFI enabled. I understand it's a trusted guest, I was just trying to get all my guests enabled with secure boot. Thanks!
Hello, I originally deployed XOA w/ the "Deploy XOA" button on the top right of the screen in XO Lite's dashboard. I also just installed the certs for secureboot certs for my VM's with secureboot-certs install. I wanted to enable secure boot for my XOA VM, but I saw that it had the bios set to default.

I attempted to switch it to UEFI and then enable secure boot, but that caused the VM to be unbootable. How can I enable secure boot for XOA? I don't recall getting an option for UEFI vs BIOS when i provisioned XOA.