About VM Lifecycle

Flexible Compute Unit (FCU) virtual machines (VMs) have a specific lifecycle from the moment you create them to their termination. You can manage their lifecycle which implies different consequences regarding its allocated or attached resources.

Overview

VM Lifecycle

sch FCU InstanceLifecycle

Creation

Creating a VM corresponds to both creating it and then starting it. Once the VM is created, it enters the pending state until it is created, started, and ready to use. The state of the VM then changes to running.
Creating a VM allocates the corresponding physical resources to it. You define the hardware of its host computer thanks to a VM type, and the OS, configuration, and possibly software applications installed on it thanks to an OUTSCALE machine image (OMI). For more information, see About OMIs.

The VM receives a unique VM ID, and a private IP and an associated private DNS name that can only be contacted within the Cloud. If you create a VM in the public Cloud, it also receives a public IP and an associated public DNS name. This public IP is temporary and changes every time you stop and start the VM. For more information, see About Instances > General Information About Instances.

  • To fix a public IP to a VM of the public Cloud or to add a fixed public IP to a VM in a Net, you can attach a public IP to it, and then use the osc.fcu.eip.auto-attach OUTSCALE tag to fix it through the stop and start process. For more information, see About Public IPs.

  • To create a VM in the public Cloud without a public IP and a public DNS name, use the private-only OUTSCALE tag.

For more information, see Configuring a VM with User Data and OUTSCALE Tags.

You can also attach network interface cards (NICs) to a VM at creation or afterward to partition its network. For more information, see Network Interface Cards (NICs).

Stop and Start

You can stop a running VM at any time, and then start it again. Stopping a VM using the API corresponds to shutting it down using the operating system (OS) command.

You can also force a VM to stop. When doing so, the VM stops without properly exiting running applications.

Forcing a VM to stop may damage its system.

When you stop a VM, it enters the stopping state, and then changes to stopped. When you start a stopped VM, it enters the pending state, and then changes to running.

When stopping and starting a VM, it keeps:

  • Its VM ID

  • Its private DNS and IP

  • The public IP attached to it and fixed using the osc.fcu.eip.auto-attach OUTSCALE tag (if so)

If the VM is not tagged with the osc.fcu.eip.auto-attach OUTSCALE tag, the public IP is detached from the VM when stopping it.

  • Volumes attached to it (if so)

However, the public IP and public DNS name assigned to a VM of the public Cloud at creation change through the stop and start process. Data stored in the memory is also erased when stopping the VM.

When a VM is stopped, you can modify its attributes like its VM type (amount of vCores and memory). For more information, see Modifying a VM Attribute.

It is also recommended to stop the VM if you want to treat a volume attached to it. To do so, you need to detach the volume from the VM once it is stopped and to attach it to another VM to treat it. When reattaching the volume to the original stopped VM, beware of using the same device name as the one specified in its block device mapping before starting the VM again. For more information, see Attaching a Volume to a VM, Detaching a Volume from a VM and Defining Block Device Mappings. If the VM you want to stop is registered with a load balancer, it is recommended to deregister it before stopping it, and to start it before registering it again if needed. For more information, see Load Balancing Unit (LBU).

Force Stop

If regular stop does not work on your VM, you can also force it to stop. Forcing the VM to stop corresponds to unplugging a computer, which means that the system may not stop properly.

Forcing a VM to stop may damage its system and lose data. Ensure that you no longer need it or that you have backed it up.

You can view the console output of the VM to check if there is any issue or problem going on. To do so, see Viewing the Console Output of a VM.

The following list presents the general causes why a VM cannot stop properly:

  • A process is running, which prevents to stop the VM.
    The most frequent reason is that a process is using a filesystem, which means that an operation on the volume is not finished yet. This prevents the filesystem to be unmounted, which is required to stop the VM. Therefore, you need to ensure that no process is using a filesystem (for example, NFS or CRFS). If there is any, do one of the following three options before trying again to stop the VM:

    • Wait until the process ends.

    • Stop the process.

    • Unmount the volume on which the process is running.

  • An update is in progress (for example, a Windows update).

Do not force a VM to stop during an update, as it may damage your VM or prevent it from starting again. Some updates may take a lot of time (up to several hours) on small VM types.

  • There are issues with your ACPI calls, required by VMs to stop properly. The two main issues are:

    • The VM has crashed. In this case ACPI calls are ignored.

    • The pci-hotplug and acpiphp modules are not installed on your VM, so ACPI calls are not supported. This may happen if you used your own custom OMI to create your VM.
      You can check the /etc/modules directory to check whether they are installed or not:

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.
pci-hotplug
acpiphp

If the modules are not installed, you can create your own custom OMI using an official OMI, and then create a new VM.

If the VM does not stop when using a Force Stop, contact our Support team. Beware that the support will have no other choice but shutting the VM down which may corrupt your data. Ensure you have backed it up.

Reboot

You can reboot a running VM at any time if needed using the API, which corresponds to rebooting the OS. When rebooting, the VM restarts without going through the stop and start process.
The VM is still running and keeps all its allocated resources. Besides, data stored in its memory remains available after rebooting a VM.

Termination

You can terminate a VM that you no longer need. Terminated VMs cannot be recovered. The VM enters in the shutting-down state, and then changes to terminated once the termination is completed. The VM remains visible in the terminated state for 1 hour, without any possibility to recover it.

When terminating a VM, its corresponding physical resources are released and data stored in its memory is erased. If a public IP is attached to the VM, it is released but still allocated to your account.

The behavior of BSU volumes when terminating the VM they are attached to depends on the block device mapping. By default, the root device of the VM is deleted while other volumes attached to it are detached. For more information about how to set this behavior, see Defining Block Device Mappings.

You can also configure two types of termination protection:

  • DisableApiTermination: This attribute enables you to prevent VM termination (by default, enables termination).

  • InstanceInitiatedShutDownBehavior: This attribute enables you to define the VM behavior when you stop or terminate it. By default or it set to stop, the VM stops. If set to restart, the VM stops then automatically restarts. If set to terminate, the VM stops and is terminated. You can, for example, automatically terminate a VM at the end of an application by setting this attribute to terminate and asking the VM to stop when the running application is closed.

These two termination protection attributes can be defined when creating the VM and modified afterward. For more information, see Modifying a VM Attribute.

Related Pages

Export to PDF