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