search

vatesfr / xen-orchestra

The global orchestration solution to manage and backup XCP-ng and XenServer.
https://xen-orchestra.com
Other
767 stars 262 forks source link

VM Start Delay not working as expected. Implement functionality similar to Proxmox (ideal) or to ESXi (simpler). #6906

Closed jbmorgado closed 1 year ago

jbmorgado commented 1 year ago

Is your feature request related to a problem? Please describe. I have some VMs in the server that depend on other VMs having previously started. Mainly, one VM acts as a NAS server, and when a webserver VM starts, I want that webserver VM mounting a share from the NAS VM.

Describe the solution you'd like There are 2 possibilities here.

  1. (Better) Similar to Proxmox. Define a priority P for each automated start. Define a time T1 to wait before starting any autostart VM with priority higher than P. Define a time T2 to wait after telling any VM higher than P to shutdown.

  2. (Acceptable) Similar to ESXi. Just define a waiting time for each autostart VM to wait before being started.

Describe alternatives you've considered I came up with some fairly involved process to get the NAS VM to issue a shell command on the XCP-ng host to start VMs (Xenorchestra API is lacking here as well).

Additional context I know some years ago in some blog post you guys said this wasn't trivial. I accept your knowledge on the matter, but it doesn't look as complex as a lot of functionality you have been put later and would be a great QoL for many of the users.

olivierlambert commented 1 year ago

Hi,

It's a complex problem and the solution might depends on what you need. It's not really trivial to manage it into XCP-ng. From Xen Orchestra perspective, it might be easier. But I'm not sure it's up to XO to deal with this.

XAPI is already capable to deal with this while using vAPP (or VM_appliances): https://docs.xenserver.com/en-us/citrix-hypervisor/vms/vapps.html

However, it's not exposed in XO API for now (we tried few years ago, but it was some UI and logic work for something not really asked/required).

Do you have any case outside a simple dependency with a storage VM? Because if it's only that, we are working on a solution to automatically replug a SR after a bit, directly from a service in XCP-ng. I think that might simply solve your issue. I just want to avoid spending too much time/efforts (and therefore money, which doesn't grow on trees) on full vApp support that nobody will use.

Anyway, closing as an issue to solve, but I'm not closing the discussion so we can be sure about your requirement

jbmorgado commented 1 year ago

Thank you for the fast response Olivier!

I was unaware of the VApps. I do have the old XCP-ng Center app installed and realized this seems exactly the functionality I described as needed here. This will do for now (I'm just afraid with some new version of XCP-ng the now defunct XCP-ng center stops working).

About the SR scenario you mention. Well, that would also be handy. The only thing we are doing now with SRs that needs that functionality, is to mount an ISO share inside a NAS (that NAS is actually a VM, so, you see the issue here...).

I think that more than a delay to retry and mount the SR, what is needed is an “on request” mounting of the SR and trust the user not to do anything with it until it's up. Then, when you try to use some image from the SR, or add something, or just even browse it, then try and mount it only then.