Deploy VMs on your Virtualized Cluster

This tutorial describes steps to create a new virtual machine on a virtualized cluster in Private Cloud Director.

Provision VMs from Images

If you are provisioning VMs from existing images, you'll first need to ensure your images are available in the cluster via the Image Library.

Import Images into Image Library

To import images into the Image Library, navigate to 'Images' in the Navigation Pane and choose your import method - CLI or via UI.

Info

As of this release, we recommend using the CLI for images >1GB.

Importing Images via the CLI

To import images via the CLI, use a machine that has access to the images to upload it into the OpenStack Glance service. Setup the OpenStack python client on your machine, and perform the steps outlined in your UI:

Verify Flavors

Once you have the images you would like to use, it's time to look at the resource configuration for the VMs to be deployed. Private Cloud Director uses T-Shirt sized configurations of resource allocations, called Flavors, to allow you to specify the resource allocation for VMs. Navigate to the Flavors section of the UI and create or edit flavors to suit your desired CPU memory configuration.

Info

Flavors can also be used to specify VM placement rules, by specifying additional attributes (called Host Aggregates) that would direct VMs to be placed on Cluster hosts that match those attributes. You can review those later, as you get more familiar with the platform.

Deploy Your VM

By now, you have your desired VM image, your preferred Flavor, and you have previously setup at least one Network that you can use to deploy your VM. So navigate to Virtual Machines in the Navigation pane and start 'Deploy Virtual Machine'.

Beyond the obvious selection of source image, flavor and network, we'll introduce some of the other VM creation options here.

VM source

Boot VM from Image

Use this option if you would like to provision a temporary VM that doesn't need to persist upon host failure, or after the VM is terminated. The VM disk will be created using local storage on the Hypervisor it is provisioned on, and populated using the contents of the source image. If the Hypervisor were to go down or the VM were to be terminated, this VM will not be recoverable.

Boot VM from New Volume

Use this option if you would like a VM whose data should be persistent, or if it should be resident on your desired Cinder storage backend. Here, a new, persistent volume is created on the block storage configured in your cluster, and its contents populated with the contents from the source image. A VM created in this manner will persist across host failures and VM termination, unless you choose to have the volume be deleted upon VM termination.

Boot VM from Existing Volume

This option is like the previous one, except you are choosing to boot from an existing volume as opposed to provisioning a new volume from a base image.

SSH Key

Using SSH Keys to access your VM is the recommended method in lieu of insecure passwords. To setup your SSH Key, navigate to 'Access and Security' in the Navigation Pane, and import your SSH Keys.

Once you have the key imported, you can select that key so you can access the newly provisioned VM via that key.

Server Group Assignment

Server Groups are logical groups of Virtual Machines so you can specify "Affinity" or "Anti-Affinity" rules. We will cover these in greater detail later.

Using cloud-init

Using cloud-init allows you to customize the Virtual Machine as it boots up, such as to provision certain additional software or customization scripts.

Assigning Security Groups

Security groups allow you to limit port access to Virtual Machines. If you don't already have a Security Group configured, you can cover this later.

Specifying Metadata

Metadata attributes allow you to specify additional key-value pairs of metadata, which can be used for querying and organizing your Virtual Machine environments.

Last updated

Was this helpful?