vm start delay - does it work yet?

akurzawa

Hi

From my obercation the start dealy is not working - I look like the vms are stariting all together at boot. Since when this function is avaialbe in xoa?

olivierlambert

Start delay works when the VM is started with a VM.start. I'm not sure delay is meant to work with auto power.

Details on XAPI: https://xapi-project.github.io/xen-api/classes/vm.html

The delay to wait before proceeding to the next order in the startup sequence (seconds)

Regarding the feature, it's available since XOA 5.33, see https://github.com/vatesfr/xen-orchestra/blob/master/CHANGELOG.md#5330-2019-03-29

akurzawa

olivierlambert said in vm start dealy - does it work yet?:

I'm not sure delay is meant to work with auto power.

Where could I veryify the functionality of delay and autopower ?

olivierlambert

Put a large delay on a VM (eg 600 secs, 10min), and put in on autopower. Then reboot your host. Is the VM booted before 10min? If yes, then autopower in XAPI doesn't take into account the delay.

payback007

unfortunately "start delay" is not working as expected. The function what you marked above is to change the start delay of an existing "vApp". Here is an example of my setup:

The value whould change the "Delay interval" later by XOA, nothing else. Otherwise is vApp feature also not working on my XCP-ng installation, I think it was never really tested.

If you want to implement start delays to your VM's you can follow this guide:

define vApp for autostart in xcp-ng center including start order
find out the uuid of the vApp:

xe appliance-list

write autostart script containing

#!/bin/sh
xe appliance-start uuid=uuid-autostart-vApp

implement new systemd.service in /etc/systemd/system/autostart.service

[Unit]
Description=autostart script for boot VM
After=graphical.target

[Service]
Type=simple
ExecStart=/path/to/your/autostart-script.sh
TimeoutStartSec=0

[Install]
WantedBy=default.target

enable the service

systemctl enable autostart.service

Editing of boot delay time is then possible via XOA which is already a nice feature at all for "fine tuning" or adapt if new VMs are added to the autostart vApp.

olivierlambert whould it make sense to open an additional feature request? vApp-implementation was several times discussed with no "final statement" I think.

sasha

payback007
Thank you for sharing this. So far this is the one simple and reliable way to start VM in the desired order.

payback007

The only thing is to think on that script during a major update of xcp-ng to a newer version. Because after installation the autostart.service has to be implemted again.

cairoti

payback007 said in vm start delay - does it work yet?:

unfortunately "start delay" is not working as expected. The function what you marked above is to change the start delay of an existing "vApp". Here is an example of my setup:

The value whould change the "Delay interval" later by XOA, nothing else. Otherwise is vApp feature also not working on my XCP-ng installation, I think it was never really tested.

If you want to implement start delays to your VM's you can follow this guide:

define vApp for autostart in xcp-ng center including start order

find out the uuid of the vApp:
xe appliance-list
write autostart script containing
#!/bin/sh
xe appliance-start uuid=uuid-autostart-vApp
implement new systemd.service in /etc/systemd/system/autostart.service
[Unit]
Description=autostart script for boot VM
After=graphical.target

[Service]
Type=simple
ExecStart=/path/to/your/autostart-script.sh
TimeoutStartSec=0

[Install]
WantedBy=default.target
enable the service
systemctl enable autostart.service
Editing of boot delay time is then possible via XOA which is already a nice feature at all for "fine tuning" or adapt if new VMs are added to the autostart vApp.

olivierlambert whould it make sense to open an additional feature request? vApp-implementation was several times discussed with no "final statement" I think.

When I have a pool without HA, how could I use this script?

I thought about setting the script on the master server. However, in a maintenance, where a second node becomes the master, will I have to recreate the script?