A virtual machine (VM) is a virtual machine launched in the public Cloud or in a Net, composed of compute, storage and memory elements, which runs an Operating System (OS) and can host any of your business applications. You can choose between different hardware configurations called VM types, and between different machine images to serve as a template for the VMs to be launched.
A VM is the exact equivalent of a physical machine, virtualized and launched in the Cloud using an OUTSCALE machine image (OMI) as a template and an VM type as hardware configuration. An OMI provides at least an OS and possibly other software applications. For more information, see About OMIs.
VMs are composed of virtualized cores (vCores), memory and storage. This storage is composed of permanent Block Storage Unit (BSU) volumes: the root device of the VM is a BSU volume used to store all the OS files and other data if needed. You can launch VMs using an OMI composed of several volumes, or attach additional volumes to this VM at any time. For more information, see Block Storage Unit (BSU).
3DS OUTSCALE provides three categories of VM types, between which you can choose depending on your needs in terms of compute and memory performance:
Custom VMs, for which you can define the amount of vCores and memory you want
3DS OUTSCALE-specific predefined VMs, for dedicated purposes (for example, Big Data or high performance computing), with a predefined amount of vCores and memory
AWS-compatible predefined VMs
You can modify the VM type after launch. For more information, see Modifying a VM Attribute.
VMs can be either in the public Cloud or in a Net. By default, a VM is launched in the public Cloud on Cockpit. You can also place a VM in the Subregion of your choice, within the Region of your account. If you do not specify any Subregion, the Subregion A is used by default.
VMs are assigned a private IP at launch. If you launch VMs in the public Cloud, they also receive a public IP, unless you specified the
private_only tag in the user data. This public IP can be replaced by a public IP that can be fixed to the VM. public IPs can also be used to add a public IP to a VM in a Net. For more information, see About Public IPs.
You can add additional IPs to VMs in a Net through network interfaces. For more information, see About NICs.
For more information, see About VM Lifecycle > Launch. For the list of available public IP ranges, see OUTSCALE Public IPs.
You can launch multiple VMs with the same attributes at the same time. Therefore, several VMs can have the same name. The Count attribute enables you to define a minimum and a maximum number of VMs to launch. If the maximum number of VMs cannot be launched because of insufficient capacity, the highest possible number of VMs above the specified minimum count are launched. If the minimum number of VMs you specified cannot be launched because of insufficient capacity, no VMs are launched at all.
Each launch request creates a reservation that contains all the VMs launched in the request, identified with a reservation ID. Each VM of a same reservation receives an
ami-launch-index that you can use to apply some parameters to specific VMs within the reservation. The first launched VM is numbered zero (0), the second is numbered one (1), and so on.
To identify your resources more easily, you can add tags to them. For more information, see Tagging Your Resources.
When launching a VM, you need to specify a keypair to use to connect to this VM. For more information about keypairs, see About Keypairs.
When launching a VM, you need to select several defining attributes. These attributes can be modified afterward. For more information, see Modifying a VM Attribute.
A VM has the following attributes:
Block device mappings which define volume attachments and whether the volumes are deleted when the VM is terminated. For more information, see Defining Block Device Mappings.
A VM type, which determines compute, memory and storage capabilities. For more information, see VM Types.
The possibility to disable termination to prevent accidental termination of the VM.
A keypair, which is a pair of SSH keys (public and private) with which you can connect to the VM. For more information, see About Keypairs.
Security groups, which enable you to manage traffic to and from the VM. For more information, see About Security Groups.
A shutdown behavior, which determines whether the VM stops, terminates or restarts when you initiate its shutdown.
Whether source/destination check of network traffic is enabled for the VM (VPC only).
User data, which enables further fine-tuning of your VM. For more information, see Configuring a VM with User Data and OUTSCALE Tags.
Every VM must be launched behind a security group. Security groups act as a network virtual appliance for switching and firewalling, and therefore allow or deny traffic for one or more VMs. For more information, see About Security Groups.
By default, a security group does not allow any inbound flow to your VMs. You must specify the rules for this security group depending on your needs and your architecture. You can add or remove security group rules at any time, but you cannot associate an existing VM with another security group once launched.
A Default security group is available for your account. This security group only enables interactions between VMs using this same security group. You can however modify its rules if needed.
In the public Cloud, security groups only filter inbound flows. In a Net, security groups filter both inbound and outbound flows.
A security group rule is composed of the following elements:
Flow: Inbound or outbound.
Protocol: TCP, UDP or ICMP.
From port: The beginning port.
To port: The ending port.
Source CIDR: The CIDR network address to filter on.
Source security group: Another security group to filter on.
By default, VMs are placed on servers shared by other OUTSCALE accounts. However, you can specify that you want to place your VMs on dedicated servers at launch. For more information, see the VM tenancy in Creating / Launching VMs.
Dedicated VMs do not share allocated hardware with other accounts, but only share it with non-dedicated VMs belonging to the same account.
Using dedicated VMs enables you to benefit of the full capacity of the server. The following tenancy options are available:
default: Your VM is placed on a shared allocated hardware.
dedicated: Your VM is placed on a dedicated allocated hardware.
You need to specify the VM tenancy at launch. You cannot set a VM as
dedicated after launch. For more information, see Creating / Launching VMs.
When using a Net, you can set the tenancy option for the whole Net when creating it. If you set the Net tenancy to
default, you have to set the
tenancy attribute to
dedicated for each VM you want to be on a dedicated server. If you set the Net tenancy to
tenancy attribute of VMs launched in the Net is automatically set to
dedicated. You cannot modify the tenancy option of your Net once created.
Creating dedicated VMs requires more quotas than those allocated to your account by default. To increase the corresponding quota, please contact our Support team at firstname.lastname@example.org, copying in your Technical Account Manager or at least email@example.com.
For more information about the price of dedicated VMs, see Billing Glossary > Instance - Dedicated Instance - Additional price - per hour.
You can run VMs within other VMs by using nested virtualization. To do so, you need to take into account the following requirements:
Nested VMs share the capacity of the host VM. Make sure your host VM has enough memory, cores, and volume space to run nested VMs.
Nested VMs can only be based on outside images (.iso files), not OUTSCALE machine images (OMIs).
For more information about how to enable nested virtualization, see our technical guide Enabling Nested Virtualization.
Reserved VMs are VMs you can reserve in a specific Subregion and for a specific duration. This enables you to benefit from a discounted price, while avoiding any insufficient capacity in the Subregion.
For more information about reserved VMs, contact our Sales department at firstname.lastname@example.org.
AWS™ and Amazon Web Services™ are trademarks of Amazon Technologies, Inc or its affiliates in the United States and/or other countries.