Keep BOOT state for managed VMs until the running state is confirmed
|Assignee:||Abel Coronado||% Done:|
|Target version:||Release 5.6|
To avoid getting "VNC Failed to connect to server (code: 1006)" shortly after the VM has booted.
#2 Updated by Ruben S. Montero about 5 years ago
Ruben S. Montero wrote:
Probably the state machine transitions for "managed" VMs (vCenter, EC2...) may be altered, so it remains in BOOT state till their running status is confirmed through monitor, or a new state can be added BOOT->PRE-RUN...
Or probably based on the last-monitored is a better idea
#7 Updated by Miguel Ángel Álvarez Cabrerizo almost 4 years ago
- Status changed from New to Closed
- Assignee set to Miguel Ángel Álvarez Cabrerizo
- Target version set to Release 5.4
The issue in vCenter is like this:
- A VM is deployed and the status is RUNNING.
- Sunstone's VNC button is enabled as the state is RUNNING.
- The VNC connection may fail shortly after the VM is RUNNING because the VCENTER_ESX_HOST attribute is not assigned yet, so Sunstone does not know in what ESX host the VM is running so NoVNC proxy cannot forward the connection.
- Once the VMs are monitored in a host poll, Sunstone knows where's the VM and the VNC connection is successful.
This is the solution that will be committed to master:
- Once the VM has been powered on, a temporary file will store the esx host where the VM has been deployed. Also a similar file will be generated when a Wild VM is imported, so the VNC connection works right away.
- When OpenNebula's proxy tries to open a connection for the vCenter VM it will try to obtain the ESX host from the monitoring info but if it's not there yet it'll use the temporary file containing the host. If it's not possible to retreve that host, an error will be sent to Sunstone telling the user: "Could not determine the vCenter ESX host where the VM is running. Wait till the VCENTER_ESX_HOST attribute is retrieved once the host has been monitored"