@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 ?

Updated now!

@Danp

@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)

@olivierlambert

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.