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.

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.

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
Warning
This is an important selection that affects where your VM is stored, and whether it should be 'Ephemeral' vs 'Persistent'.
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.
Success
With this information specified, Private Cloud Director has all it needs to spin up your VM, and you should see the VM provision within a few minutes. You can then access the VM over the network or via its console.
Last updated
Was this helpful?
