Feature #4242

Keep BOOT state for managed VMs until the running state is confirmed

Added by OpenNebula Systems Support Team over 5 years ago. Updated almost 4 years ago.

Status:PendingStart date:12/14/2015
Priority:HighDue date:
Assignee:Abel Coronado% Done:

0%

Category:vCenter
Target version:Release 5.6
Resolution: Pull request:

Description

To avoid getting "VNC Failed to connect to server (code: 1006)" shortly after the VM has booted.

History

#1 Updated by Ruben S. Montero over 5 years ago

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

#2 Updated by Ruben S. Montero over 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

#3 Updated by OpenNebula Systems Support Team over 5 years ago

For vCenter the VMware tools may be used to ascertain that the VM is running

To preserve the hook functionality, the state machine transition change may be the right path.

#4 Updated by Daniel Molina over 5 years ago

  • Subject changed from Hold VNC button activation until connection is up to Keep BOOT state for managed VMs until the running state is confirmed
  • Category changed from Sunstone to Drivers - VM

#5 Updated by Ruben S. Montero over 5 years ago

  • Category changed from Drivers - VM to vCenter

#6 Updated by Ruben S. Montero about 5 years ago

  • Tracker changed from Feature to Backlog
  • Priority changed from Normal to High
  • Target version deleted (Release 5.0)

#7 Updated by Miguel Ángel Álvarez Cabrerizo about 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"

#8 Updated by Ruben S. Montero almost 4 years ago

  • Status changed from Closed to Pending
  • Target version changed from Release 5.4 to Release 5.6

Just to review the file procedure, it'd may be better to add that directly to the VM template of the imported VM.

#9 Updated by Ruben S. Montero almost 4 years ago

  • Assignee changed from Miguel Ángel Álvarez Cabrerizo to Abel Coronado

#10 Updated by Ruben S. Montero almost 4 years ago

  • Tracker changed from Backlog to Feature

Also available in: Atom PDF