At OVHcloud, we are proud to continuously evolve our infrastructure to help customers run their virtualized workloads with greater efficiency, flexibility and performance.

Today, we announce the availability of Premier 2027 hardware generation for Managed VMware vSphere solution, bringing significant improvements in compute power, memory capacity, storage capacity, and configuration flexibility.

The new generation improves upon its predecessors, being designed to better support enterprise virtualization environments, modern cloud workloads, as well as evolving VMware licensing models.

Managed VMware vSphere Welcomes a New Generation of Hardware

The Premier 2027 hardware range is replacing the previous Premier generation introduced in 2020, delivering stronger performance and broader configuration options for a wide variety of use cases.
Powered by the latest Intel Emerald Rapids processors, the new infrastructure enables customers to run demanding workloads while maintaining excellent price-performance efficiency.

Key highlights of the new generation include:

• Up to 40% more CPU cores compared to the previous Premier hardware
• Up to 1.5 TB RAM per host
• High-performance NVMe storage
• Up to 50 Gbps private bandwith included

Together, these improvements provide a more powerful and scalable foundation for virtual infrastructures hosted on OVHcloud, our latest pride and joy.

Premier 2027 Hardware Specifications

Latest Intel Emerald Rapids processors

The new servers use Intel Emerald Rapids CPUs, available in both mono-socket and bi-socket configurations, offering a flexible range from 16 to 72 cores.
This allows organizations to choose the right compute capacity for their workloads while benefiting from:

• up to 40% more cores compared to the previous Premier hardware
• up to 50% more CPU cache compared to the previous Premier hardware
• improved performance for compute-intensive applications
• broader servers’ options with global purpose (GP-x) and storage-optimized (STO-x) configurations.

Expanded memory capacity

Premier 2027 servers support up to 1.5 TB of RAM per host, enabling:

• larger virtual machines
• improved consolidation ratios
• better performance for memory-intensive applications such as databases and analytics platforms.

High-performance NVMe storage

The new hardware generation includes NVMe storage, enabling lower latency and faster data throughput.
Storage-optimized configurations (STO-x) leverage vSAN NVMe drives and can support up to 70 TB of storage per host.
This allows organizations to efficiently run storage-intensive workloads, including large databases (such as CRM), analytics platforms and enterprise applications (such as ERP).

High-speed networking

Premier 2027 servers feature up to 50 Gbps private networking included, providing a fast and reliable connectivity for virtual machines and distributed workloads.
This high bandwidth improves performance for applications requiring high data throughput, such as:

• distributed systems
• backup operations
• large-scale data processing.

View prices

Designed for a Wide Range of Enterprise Use Cases

The Premier 2027 hardware generation is designed to support a wide range of enterprise virtualization scenarios.

Cloud migration

Organizations migrating workloads from on-premises VMware environments to the cloud can benefit from performance consistency and familiar tooling, making migration simpler and reducing operational complexity.

The additional compute and memory capacity also make it easier to consolidate workloads and optimize infrastructure costs.

Disaster recovery and business continuity

For disaster recovery environments, infrastructure performance and scalability are critical.
With high-performance NVMe storage and up to 50 Gbps networking, the new hardware enables faster replication, improved recovery times and reliable failover environments.

Customers also benefit from compatible and resilient backup solutions such as Veeam Managed Backup, a managed backup solution to protect and back up their virtual machines, and/or Zerto, a replication platform installed and updated by OVHcloud, that allows them to resume activity quickly and easily.

Enterprise application hosting

Many enterprise applications require predictable performance and large memory capacity.
The Premier 2027 range allows customers to run demanding applications such as:

• large databases, such as CRM
• ERP systems
• data analytics platforms
• containerized workloads on VMware environments.

Seamless Infrastructure Evolution

Customers already running Managed VMware vSphere can integrate the Premier 2027 servers, either global purpose (GP-x) or storage-optimized (STO-x) configurations, into existing environments.

The new hardware is compatible with the current Premier generation, allowing the creation of heterogeneous clusters and enabling customers to scale their infrastructure without requiring a full migration.

This flexibility allows organizations to expand their infrastructure progressively while maintaining operational continuity.

Future-Ready Infrastructure

The Premier 2027 hardware generation provides a strong foundation for future virtualization needs.

With the latest CPU architecture, NVMe storage and high-speed networking, organizations can confidently support evolving workloads and future platform upgrades while maintaining the performance and reliability expected from enterprise VMware environments.

Conclusion

The introduction of Premier 2027 hardware for Managed VMware vSphere marks an important evolution of the OVHcloud Private Cloud platform.

With more powerful processors, increased memory and storage capacity, and flexible configurations, we are delighted to welcome this new generation of infrastructure enabling organizations to run modern workloads more efficiently, while maintaining full control of their VMware environments.

Discover the new Premier 2027 range: https://www.ovhcloud.com/en-ie/hosted-private-cloud/vmware/prices/

Find out more about VMware on OVHcloud solutions: https://www.ovhcloud.com/en-ie/solutions/vmware/

Chez OVHcloud, nous faisons évoluer en continu notre infrastructure afin de permettre à nos clients d’exécuter leurs charges de travail virtualisées avec toujours plus d’efficacité, de flexibilité et de performance.

Dans cette dynamique, nous annonçons aujourd’hui la disponibilité de la nouvelle génération de serveurs Premier 2027 pour la solution Managed VMware vSphere. Cette évolution apporte des améliorations significatives en matière de puissance de calcul, de capacité mémoire, de stockage et de flexibilité de configuration.

Conçue pour s’inscrire dans la continuité des versions précédentes, cette nouvelle génération a été pensée pour mieux répondre aux exigences des environnements de virtualisation d’entreprise, des charges de travail cloud modernes, ainsi qu’à l’évolution des modèles de licence VMware.

Managed VMware vSphere s’enrichit d’une nouvelle génération de serveurs

La gamme de serveurs Premier 2027 succède à la gamme Premier introduite en 2020. Elle propose des performances renforcées, tout en élargissant les possibilités de configuration afin de couvrir un large éventail de cas d’usage.
Grâce aux derniers processeurs Intel Emerald Rapids, cette infrastructure permet d’exécuter des charges de travail exigeantes, tout en conservant un excellent équilibre entre performance et coût.

Principaux points clés de cette évolution : jusqu’à 40 % de cœurs CPU supplémentaires par rapport aux serveurs Premier précédents

• jusqu’à 1,5 To de RAM par hôte
• stockage NVMe haute performance
• bande passante privée jusqu’à 50 Gbit/s incluse

Ensemble, ces améliorations fournissent une base plus puissante et évolutive pour les infrastructures virtuelles hébergées sur OVHcloud, notre dernière fierté.

Spécifications des serveurs Premier 2027

Derniers processeurs Intel Emerald Rapids

Les nouveaux serveurs reposent sur des CPU Intel Emerald Rapids, disponibles en configurations mono-socket et bi-socket, avec une gamme granulaire allant de 16 à 72 cœurs.
Cette diversité permet aux organisations d’ajuster précisément la capacité de calcul à leurs besoins, tout en tirant parti de plusieurs améliorations notables :

• jusqu’à 40 % de cœurs supplémentaires par rapport aux serveurs Premier précédents
• jusqu’à 50 % de cache CPU supplémentaire par rapport aux serveurs Premier précédents
• des performances accrues pour les applications intensives en calcul
• des options de serveurs élargies, avec des configurations polyvalentes (GP-x) et optimisées pour le stockage (STO-x)

Capacité de mémoire étendue

Avec une prise en charge allant jusqu’à 1,5 To de RAM par hôte, les serveurs Premier 2027 permettent :

• le déploiement de machines virtuelles de plus grande taille
• une meilleure consolidation des ressources
• des performances accrues pour les applications exigeantes en mémoire, telles que les bases de données et les plateformes analytiques

Stockage NVMe haute performance

La nouvelle génération de serveurs intègre du stockage NVMe, ce qui se traduit par une latence réduite et un débit de données nettement supérieur.
Dans ce cadre, les configurations optimisées pour le stockage (STO-x) s’appuient sur des disques NVMe vSAN et peuvent atteindre jusqu’à 70 To de capacité par hôte.
Cette architecture permet d’exécuter efficacement des charges de travail intensives en stockage, comme de grandes bases de données telles que les CRM, des plateformes analytiques, ainsi que des applications d’entreprise comme les ERP.

Réseau haut débit

Enfin, les serveurs Premier 2027 intègrent une bande passante privée jusqu’à 50 Gbit/s, assurant une communication rapide et fiable pour les machines virtuelles et les charges de travail distribuées.
Cette bande passante élevée contribue directement à améliorer les performances des applications nécessitant des échanges de données importants, notamment :

• les systèmes distribués
• les opérations de sauvegarde 
• le traitement de données à grande échelle

Voir les prix

Conçu pour une large gamme de cas d’usages Entreprise

La nouvelle génération de serveurs Premier 2027 a été conçue pour prendre en charge un large éventail de scénarios de virtualisation d’entreprise.

Migration vers le cloud

Les organisations qui migrent leurs charges de travail depuis des environnements VMware on-premises vers le cloud bénéficient d’une continuité en matière de performances ainsi que d’outils familiers, simplifiant la migration et réduisant la complexité opérationnelle.

Par ailleurs, l’augmentation des capacités de calcul et de mémoire facilite la consolidation des charges de travail et contribue à optimiser les coûts d’infrastructure.

Reprise après sinistre et continuité d’activité

Pour les environnements de reprise après sinistre, les performances de l’infrastructure et son évolutivité jouent un rôle déterminant.
Grâce au stockage NVMe haute performance et à la connectivité réseau privé jusqu’à 50 Gbit/s, cette gamme permet d’accélérer la réplication, d’améliorer les temps de reprise et de garantir des environnements de basculement fiables.

Les clients peuvent également s’appuyer sur des solutions de sauvegarde compatibles et résilientes, telles que Veeam Managed Backup, une solution managée dédiée à la protection des machines virtuelles, ainsi que Zerto, une plateforme de réplication installée et maintenue par OVHcloud, permettant une reprise d’activité rapide et simplifiée.

Hébergement d’applications d’entreprise

De nombreuses applications d’entreprise nécessitent des performances prévisibles ainsi qu’une capacité de mémoire élevée.
La gamme Premier 2027 permet d’exécuter efficacement des applications exigeantes, telles que :

• de grandes bases de données, comme les CRM ;
• des systèmes ERP ;
• des plateformes d’analyse de données ;
• des charges de travail conteneurisées dans des environnements VMware.

Évolution fluide de l’infrastructure

Les clients utilisant déjà Managed VMware vSphere peuvent intégrer les serveurs Premier 2027, en configurations polyvalentes (GP-x) ou optimisées pour le stockage (STO-x), au sein de leurs environnements existants.

Cette nouvelle gamme de serveursest compatible avec la gamme Premier actuelle, ce qui permet de constituer des clusters hétérogènes et d’étendre l’infrastructure sans nécessiter de migration complète.

Cette approche offre la possibilité de faire évoluer progressivement l’infrastructure tout en assurant la continuité des opérations.

Une infrastructure prête pour l’avenir

La nouvelle génération de serveurs Premier 2027 constitue une base solide pour répondre aux besoins futurs en matière de virtualisation.

Grâce à une architecture CPU de dernière génération, au stockage NVMe et à une connectivité réseau haut débit, les organisations peuvent accompagner l’évolution de leurs charges de travail et de leurs plateformes, tout en maintenant les niveaux de performance et de fiabilité attendus dans des environnements VMware d’entreprise.

Conclusion

L’introduction de la gamme de serveurs Premier 2027 pour Managed VMware vSphere marque une évolution importante de l’offre Private Cloud d’OVHcloud.

Avec des processeurs plus puissants, une capacité de mémoire et de stockage accrue ainsi que des configurations flexibles, cette évolution permet aux organisations d’exécuter plus efficacement des charges de travail modernes, tout en conservant un contrôle total sur leurs environnements VMware.

Découvrez la gamme de serveurs Premier 2027 : https://www.ovhcloud.com/fr/hosted-private-cloud/vmware/prices/

En savoir plus sur les solutions VMware on OVHcloud : https://www.ovhcloud.com/fr/solutions/vmware/

Private Cloud enables customers to benefit from a VMware vSphere infrastructure, hosted and managed by OVH. Terraform lets you automate the creation of resources and their life cycle. In this first article, we will explore the basic notions of Terraform. After reading it, you should be able to write a Terraform configuration file to deploy and customise a virtual machine from a template. In a second article, we will build on this example, and modify it so that it is more generic and can be easily adapted to your needs.

Installation

Terraform is available on the HashiCorp website for almost all OSs as a simple binary. Just download it and copy it into a directory in your operating system PATH. To test that everything is working properly, run the terraform command.

$ terraform
Usage: terraform [-version] [-help] <command> [args]

The available commands for execution are listed below.
The most common, useful commands are shown first, followed by
less common or more advanced commands. If you're just getting
started with Terraform, stick with the common commands. For the
other commands, please read the help and docs before usage.

Common commands:
    apply              Builds or changes infrastructure
    console            Interactive console for Terraform interpolations
    destroy            Destroy Terraform-managed infrastructure

Folders and files

Like other Infrastructure-as- a-Code tools, Terraform uses simple files to define the target configuration. To begin, we will create a directory and place a file named main.tf. By default, Terraform will read all the files in the working directory with the .tf extension, but to simplify things, we will start with a single file. We will see in a future article how to organise the data into several files.

Similarly, to make it easier to understand Terraform operations, we will specify all the necessary information directly in the files. This includes usernames, passwords and names of different resources (vCenter, cluster, etc.). It is obviously not advisable to do this in order to use Terraform in production. The second article will also be an opportunity to improve this part of the code. But for now, let’s keep it simple!

Providers

The providers let you specify how Terraform will communicate with the outside world. In our example, the vSphere provider will be in charge of connecting with your Private Cloud’s vCenter. We declare a provider as follows:

provider "vsphere" {
    user = "admin"
    password = "MyAwesomePassword"
    vsphere_server = "pcc-XXX-XXX-XXX-XXX.ovh.com"
}

We see here that Terraform uses its own way of structuring data (it is also possible to write everything in JSON  to facilitate the automatic generation of files! ). Data is grouped in blocks (here a block named vsphere, which is of the provider type) and the data relating to the block are in the form of keys/values.

Data

Now that Terraform is able to connect to the vCenter, we need to retrieve information about the vSphere infrastructure. Since we want to deploy a virtual machine, we need to know the datacentre, cluster, template, etc., and where we are going to create it. To do this, we will use data-type blocks:

data "vsphere_datacenter" "dc" {
  name = "pcc-XXX-XXX-XXX-XXX_datacenter3113"
}

data "vsphere_datastore" "datastore" {
  name          = "pcc-001234"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_virtual_machine" "template" {
  name          = "UBUNTU"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

In the above example, we are trying to get information about the datacentre named pcc-XXX-XXX-XXX-XXX_datacenter3113 and get the information from the datastore named pcc-001234 and a template whose name is UBUNTU. We see here that we use the datacentre id to get information about an object associated with it.

Resources

The resources will be used to create and/or manage elements of the infrastructure. In our example, we will use a resource of type virtual_machine, which as its name suggests, will help us to create a VM.

resource "vsphere_virtual_machine" "vm" {
  name             = "vm01"
  resource_pool_id = "${data.vsphere_compute_cluster.cluster.resource_pool_id}"
  datastore_id     = "${data.vsphere_datastore.datastore.id}"
  guest_id         = "${data.vsphere_virtual_machine.template.guest_id}"
  scsi_type        = "${data.vsphere_virtual_machine.template.scsi_type}"

  network_interface {
    network_id = "${data.vsphere_network.network.id}"
  }

  disk {
    label = "disk0"
    size  = "${data.vsphere_virtual_machine.template.disks.0.size}"
  }

  clone {
    template_uuid = "${data.vsphere_virtual_machine.template.id}"

    customize {
      linux_options {
        host_name = "vm01"
        domain     = "example.com"
      }

      network_interface {
        ipv4_address = "192.168.1.2"
        ipv4_netmask = 24
      }

      ipv4_gateway    = "192.168.1.254"
      dns_suffix_list = ["example.com"]
      dns_server_list = ["192.168.1.1"]
    }
  }
}

The structure of this resource is a little more complex, because it is composed of several sub-blocks. We see that we will first define the name of the virtual machine. We then provide information about its configuration (Resource pool, datastore, etc.). The network_interface and disk blocks are used to specify the configuration of its virtual devices. The clone sub-block will let you specify which template you wish to use to create the VM, and also to specify the configuration information of the operating system installed on the VM. The customize sub-block is specific to the type of OS you want to clone. At all levels, we use information previously obtained in the data blocks.

Full example

provider "vsphere" {
    user = "admin"
    password = "MyAwesomePassword"
    vsphere_server = "pcc-XXX-XXX-XXX-XXX.ovh.com"
}

data "vsphere_datacenter" "dc" {
  name = "pcc-XXX-XXX-XXX-XXX_datacenter3113"
}

data "vsphere_datastore" "datastore" {
  name          = "pcc-001234"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_compute_cluster" "cluster" {
  name          = "Cluster1"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_network" "network" {
  name          = "vxw-dvs-57-virtualwire-2-sid-5001-Dc3113_5001"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

data "vsphere_virtual_machine" "template" {
  name          = "UBUNTU"
  datacenter_id = "${data.vsphere_datacenter.dc.id}"
}

resource "vsphere_virtual_machine" "vm" {
  name             = "vm01"
  resource_pool_id = "${data.vsphere_compute_cluster.cluster.resource_pool_id}"
  datastore_id     = "${data.vsphere_datastore.datastore.id}"
  guest_id         = "${data.vsphere_virtual_machine.template.guest_id}"
  scsi_type        = "${data.vsphere_virtual_machine.template.scsi_type}"

  network_interface {
    network_id = "${data.vsphere_network.network.id}"
  }

  disk {
    label = "disk0"
    size  = "${data.vsphere_virtual_machine.template.disks.0.size}"
  }

  clone {
    template_uuid = "${data.vsphere_virtual_machine.template.id}"

    customize {
      linux_options {
        host_name = "vm01"
        domain     = "example.com"
      }

      network_interface {
        ipv4_address = "192.168.1.2"
        ipv4_netmask = 24
      }

      ipv4_gateway    = "192.168.1.254"
      dns_suffix_list = ["example.com"]
      dns_server_list = ["192.168.1.1"]
    }
  }
}

3… 2… 1… Ignition

Let’s look at how to use our new config file with Terraform…

Initialisation

Now that our configuration file is ready, we will be able to use it to create our virtual machine. Let’s start by initialising the working environment with the terraform init command. This will take care of downloading the vSphere provider and create the different files that Terraform needs to work.

$ terraform init

Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "vsphere" (1.10.0)...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

...

* provider.vsphere: version = "~> 1.10"

Terraform has been successfully initialized!
...

Plan

The next step is to execute the terraform plan command to validate that our configuration file contains no errors and to visualise all the actions that Terraform will perform.

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.vsphere_datacenter.dc: Refreshing state...
data.vsphere_compute_cluster.cluster: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  + vsphere_virtual_machine.vm
      id:                                                   <computed>
      boot_retry_delay:                                     "10000"
      change_version:                                       <computed>
      clone.#:                                              "1"
      clone.0.customize.#:                                  "1"
      clone.0.customize.0.dns_server_list.#:                "1"
      clone.0.customize.0.dns_server_list.0:                "192.168.1.1"
      clone.0.customize.0.dns_suffix_list.#:                "1"
      clone.0.customize.0.dns_suffix_list.0:                "example.com"
      clone.0.customize.0.ipv4_gateway:                     "172.16.0.1"
      clone.0.customize.0.linux_options.#:                  "1"
      clone.0.customize.0.linux_options.0.domain:           "example.com"
      clone.0.customize.0.linux_options.0.host_name:        "vm01"
      clone.0.customize.0.linux_options.0.hw_clock_utc:     "true"
      clone.0.customize.0.network_interface.#:              "1"
      clone.0.customize.0.network_interface.0.ipv4_address: "192.168.1.2"
      clone.0.customize.0.network_interface.0.ipv4_netmask: "16"
      clone.0.customize.0.timeout:                          "10"
      clone.0.template_uuid:                                "42061bc5-fdec-03f3-67fd-b709ec06c7f2"
      clone.0.timeout:                                      "30"
      cpu_limit:                                            "-1"
      cpu_share_count:                                      <computed>
      cpu_share_level:                                      "normal"
      datastore_id:                                         "datastore-93"
      default_ip_address:                                   <computed>
      disk.#:                                               "1"
      disk.0.attach:                                        "false"
      disk.0.datastore_id:                                  "<computed>"
      disk.0.device_address:                                <computed>
      ...

Plan: 1 to add, 0 to change, 0 to destroy.

It is important to take time to check all information returned by the plan command before proceeding. It would be a mess to delete virtual machines in production due to an error in the configuration file… In the example below, we see that Terraform will create a new resource (here a VM) and not modify or delete anything, which is exactly the goal!

Apply

In the last step, the terraform apply command will actually configure the infrastructure according to the information present in the configuration file. As a first step, the plan command will be executed, and Terraform will ask you to validate by typing yes.

$ terraform apply
...

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

vsphere_virtual_machine.vm: Creating...
  boot_retry_delay:                                     "" => "10000"
  change_version:                                       "" => "<computed>"
  clone.#:                                              "" => "1"
  clone.0.customize.#:                                  "" => "1"
  clone.0.customize.0.dns_server_list.#:                "" => "1"
  clone.0.customize.0.dns_server_list.0:                "" => "192.168.1.1"
  clone.0.customize.0.dns_suffix_list.#:                "" => "1"
  clone.0.customize.0.dns_suffix_list.0:                "" => "example.com"
  clone.0.customize.0.ipv4_gateway:                     "" => "192.168.1.254"
  clone.0.customize.0.linux_options.#:                  "" => "1"
  clone.0.customize.0.linux_options.0.domain:           "" => "example.com"
  clone.0.customize.0.linux_options.0.host_name:        "" => "terraform-test"
  clone.0.customize.0.linux_options.0.hw_clock_utc:     "" => "true"
  clone.0.customize.0.network_interface.#:              "" => "1"
  clone.0.customize.0.network_interface.0.ipv4_address: "" => "192.168.1.2"
  clone.0.customize.0.network_interface.0.ipv4_netmask: "" => "16"
  clone.0.customize.0.timeout:                          "" => "10"
  clone.0.template_uuid:                                "" => "42061bc5-fdec-03f3-67fd-b709ec06c7f2"
  clone.0.timeout:                                      "" => "30"
  cpu_limit:                                            "" => "-1"
  cpu_share_count:                                      "" => "<computed>"
  cpu_share_level:                                      "" => "normal"
  datastore_id:                                         "" => "datastore-93"
  default_ip_address:                                   "" => "<computed>"
  disk.#:                                               "" => "1"
...
vsphere_virtual_machine.vm: Still creating... (10s elapsed)
vsphere_virtual_machine.vm: Still creating... (20s elapsed)
vsphere_virtual_machine.vm: Still creating... (30s elapsed)
...
vsphere_virtual_machine.vm: Still creating... (1m50s elapsed)
vsphere_virtual_machine.vm: Creation complete after 1m55s (ID: 42068313-d169-03ff-9c55-a23e66a44b48)

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

When you connect to the vCenter of your Private Cloud, you should see a new virtual machine in the inventory!

Next steps

Now that we have seen a standard Terraform workflow, you may want to test some modifications to your configuration file. For example, you can add another virtual disk to your VM by modifying the virtual_machine resource’s block like this:

disk {
  label = "disk0"
  size  = "${data.vsphere_virtual_machine.template.disks.0.size}"
}

disk {
  label = "disk1"
  size  = "${data.vsphere_virtual_machine.template.disks.0.size}"
  unit_number = 1
}

Then run terraform plan to see what Terraform is going to do to in order to reconcile the infrastructure state with your configuration file.

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.vsphere_datacenter.dc: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_compute_cluster.cluster: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...
vsphere_virtual_machine.vm: Refreshing state... (ID: 4206be6f-f462-c424-d386-7bd0a0d2cfae)

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ vsphere_virtual_machine.vm
      disk.#:                  "1" => "2"
      disk.1.attach:           "" => "false"
      disk.1.datastore_id:     "" => "<computed>"
      ...


Plan: 0 to add, 1 to change, 0 to destroy.

If you agree with terraform action’s proposal, you can rerun terraform apply, to add a new virtual disk to your virtual machine.

Clean it up

When you have finished your tests and you no longer require the utility of the infrastructure, you can simply run the terraform destroy command to delete all previously-created resources. Be careful with this command, as there is no way to get your data back after that!

$ terraform destroy

data.vsphere_datacenter.dc: Refreshing state...
data.vsphere_compute_cluster.cluster: Refreshing state...
data.vsphere_datastore.datastore: Refreshing state...
data.vsphere_network.network: Refreshing state...
data.vsphere_virtual_machine.template: Refreshing state...
vsphere_virtual_machine.vm: Refreshing state... (ID: 42068313-d169-03ff-9c55-a23e66a44b48)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  - vsphere_virtual_machine.vm


Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

vsphere_virtual_machine.vm: Destroying... (ID: 42068313-d169-03ff-9c55-a23e66a44b48)
vsphere_virtual_machine.vm: Destruction complete after 3s

Destroy complete! Resources: 1 destroyed.

In this article, we have seen how to deploy a virtual machine with a Terraform configuration file. This allowed us to learn the basic commands plan, apply and destroy, as well as the notions of provider, data and resource. In the next article, we will develop this example, by modifying it to make it more adaptable and generic.