Automated, Self-Service Provisioning Of Virtual Machines On Hyper-V Using HyperForm

Amjad AfanahAugust 31st, 2016Last Updated: August 31st, 2016

0 85 9 minutes read

HyperForm now provides superior automation of VM provisioning on Hyper-V through a self-service model that empowers users to provision infrastructure on-demand. With HyperForm, organizations can automate not just the VM provisioning, but the approval workflows and granular entitlements needed to provide personalized infrastructure services to meet unique IT and business needs.

HyperForm allows organizations to:

Connect multiple Hyper-V Nodes or Failover Clusters through a single proxy and customize the entitlements and quotas per registered Node or Failover Cluster
Empower users to provision virtual machines via a UI-based workflow or standardized YAML machine blueprints (i.e. blueprint as code) in the self-service library on Hyper-V nodes entitled to them
- Select an image based on the available .VHDX templates available on Hyper-V
- Customize CPU, Memory, Disk and select a Network

Register already running Linux or Windows virtual machines
Manage the day-2 operations of the provisioned VM’s (e.g. start, stop and restart) and access an in-browser terminal to access the VM via a secure message queue
Monitor the provisioned VM’s (CPU, Memory, Disk Utilization) and get notifications/alerts whenever a VM is down or performance metrics exceed a pre-defined threshold.
Manage multiple tenants across the enterprise
Register multiple LDAP Servers (e.g. Microsoft Active Directory) per tenant and allow users to authenticate seamlessly. Here’s a detailed blog on this topic.
Manage user level permissions and roles
Manage approval policies and quotas, and track the cost of both infrastructure & applications via cost profiles

The advantages of HyperForm over Hyper-V management solutions is that it’s drastically simpler to install, supports 18 clouds (in addition to Hyper-V), provides self-service consumption of both machine and applications blueprints, provides historical monitoring & alerts and of course, provides superior Docker application modeling and life-cycle management.

Register Hyper-V Nodes or Failover Clusters via a Proxy

Once logged into HyperForm, a user can navigate to Cloud Providers and then click on the +New button to select Hyper-V. A user can then complete the requested information.

Name — A name for the Hyper-V Node or Failover Cluster
Endpoint URL — This is the URL of the server on which the proxy is running. The proxy is secured through SSL and so this URL should start with HTTPS.
- To install a proxy from scratch, click on the “Is Proxy Installed” link. An auto-generated script is available allowing users to install the proxy on the Hyper-V server. You can change the password in the script by overriding “some-password” to your own custom password.
Password — This is the password used for the proxy.
Hyper-V Cluster/Node — This is the name of either the Hyper-V Node or Hyper-V Cluster
Template Location — The shared location on which the .VHDX templates reside (e.g. \\VFCN10-AD\HyperForm\Template\)
VM Destination — The destination that will be used for the VM metadata and hard disk (e.g. \\VFCN10-AD\HyperForm\VHDx\)

Advanced Configurations are also available. These can be defined by clicking on the Advanced Configurations button.

The optional fields allow you to enforce granular access controls and associate this provider with a quota policy.

Entitled Users — these are the users who are allowed to use this Cloud Provider for infrastructure provisioning. The entitled users do not have permission to manage or delete this cloud provider and will not be able to view any of the credentials.
Entitled Blueprints — these are the Machine Compose templates that can be used with this cloud provider. For example, if a Tenant Admin wishes to restrict users to provisioning 4GB machines on certified operating systems, then users will not be able to use this cloud provider to provision any other machine.
Free-Form Provision — if enabled, allows entitled users to provision VM’s uing the UI-based workflow.
Approval Enforced — if enabled, allows the Cloud Provider owner to approve new VM provisioning requests by entitled users
VM Limit — this is the maximum number of virtual machines that can be used with this cloud provider
Quota Policies — these are pre-defined policies for setting quotas on the number of VM’s or the cost of VM’s. Multiple quota policies can be selected to customize controls per user or per group of users.

Creating a Cluster (Pool of VM’s)

Servers across hybrid clouds or local development machines can be associated with a cluster, which is a logical mapping of infrastructure. A user can create a cluster by navigating to Clusters page and then clicking on the +New button.

A cluster has advanced options, like:

Networking — a user can select out of multiple types of networks. Once machines are provisioned into a cluster, a user cannot change the network settings. Here are the available networks:
- Docker — allowing containers to connect to each other on the same host
- Weave — allowing containers to connect to each other from multiple hosts
- Docker Swarm — allowing containers to connect to each other from multiple hosts
- Skip Docker Install — recommended for VM provisioning with non-container workloads (e.g. software pre-installed in a VM template)
Lease – a user can specify when the servers in this cluster expire so that HyperForm can automatically destroy those servers.
Placement Policy – a user can select from a number of placement policies like a proximity-based policy, round robin, or the default policy, which is a capacity-based placement policy that will place the Docker workload on the host that has sufficient compute resources.
Approval Enforced — if enabled, allows the Cloud Provider owner to approve new VM provisioning requests by entitled users
Granular Access Controls – a tenant admin can define access controls to a cluster to dictate who is able to deploy Docker applications to it through Entitled Users. For example, a developer may register his/her local machine and mark it as private. A tenant admin, on the other hand, may share a cluster with a specific group of users or with all tenant users. Additionally, the cluster owner can specify what application templates can be deployed to this cluster through Entitled Blueprints. If the cluster will be used in upstream environments, then only specific application templates (or “blueprints”) can be deployed on it.

Registering Already Running VM’s on Hyper-V

A user can register an already running AWS instance. This can be done by navigating to Machines and then clicking on the +New button. A user can then select the “Linux Host/VM” workflow and complete the required fields.

Name — the name of the server you would like to register. This does not necessarily need to be the actual hostname.
IP Address — this is the IP address of the server you’re registering.
Cluster — this the cluster that the new server will be part of. Make sure that you create the cluster first — before registering servers or provisioning new ones.

Once a user clicks Save, then an automatically generated script appears. You can run this script on the host you’re trying to register as a root user. The script checks if Docker is already installed. If not, then Docker, the DCHQ agent and Weave (optional) will be installed.

Here’s what the script looks like with Docker networking:

curl -Ls <dchq.agent.script.url> | bash -s <DCHQ Server Key> <dchq.agent.connect.ip><dchq.agent.connect.port> docker.local <New Server IP>

If you’re using HyperForm On-Premise, then you will be able to change the default arguments by navigating to System Settings.

Note that if Weave had been enabled on this cluster, then the script would follow this format.

curl -Ls <dchq.agent.script.url> | bash -s <DCHQ Server Key> <dchq.agent.connect.ip> <dchq.agent.connect.port> weave.local <weave-password> <weave.ip>

where <weave.ip> is the IP address of the 1st server in the Weave cluster

This task can be automated programmatically using our REST API’s for creating “Docker Servers” (https://dchq.readme.io/docs/dockerservers)

Provisioning Virtual Machines on Hyper-V

A user can provision Hyper-V virtual machines on the newly created cluster either through a UI-based workflow or by defining a simple YAML-based Machine Compose template that can be requested from the Self-Service Library. The recommended approach is the Machine Compose template as it provides more security & standardization.

UI-based Workflow – A user can request a Hyper-V virtual machine by navigating to Machines and then clicking on the +New button to select Hyper-V. Once the Cloud Provider is selected, a user can select the following options:

Node — the Hyper-V Node on which the new VM’s will be provisioned
Instance Type — pre-defined templates are available that specify the CPU, Memory, Disk and Generation for the VM (e.g. cpu=1,memory=2GB,disk=100GB,generation=1). A user can customize these value to his/her needs.
Image — this is the .VHDX template that will be used for provisioning
Network — this is the virtual network that will be used for the new VM
Skip Agent Install — this option can be selected if the VM template has the HyperForm agent already pre-installed
Username — this is the username needed to log into the VM
Password — this is the password needed to log into the VM
Cluster — this is the HyperForm cluster that is created by the user
VM Count — this is the number of VM’s that can be provisioned simultaneously

A user can then click on the Machine Compose
button to generate a YAML-based Machine Compose template. This can be used to create your own standard Machine Compose template that can be shared with other users with granular access controls.

A user can create a Machine Compose template for Hyper-V by navigating to Blueprints > App/Machine and then clicking on the +New button to select Machine Blueprint.
Here’s an example template for requesting a 4GB virtual machine on Hyper-V.

Ubuntu4G:
  region: IM-DEVBOX
  image: \\VFCN10-AD\HyperForm\Template\HyperForm_Ubuntu-14.04_64_10.0.254.100.vhdx
  instanceType: cpu=1,memory=4GB,disk=100GB,generation=1
  network: Virtual Switch1
  skipAgentInstall: true
  count: 1

The supported parameters for the Machine Compose template are summarized below:

description: Description of the blueprint/template
instanceType: Mandatory — cloud provider specific value (e.g. cpu=1,memory=4GB,disk=100GB,generation=1)
region: Mandatory — the name of the Hyper-V Node
image: Mandatory – fully qualified path of the .VHDX template (e.g. \\VFCN10-AD\HyperForm\Template\HyperForm_Ubuntu-14.04_64_10.0.254.100.vhdx)
username: This the username used to connect to the VM
password: This can reference a private key stored in the Credentials store. The ID of the credential item stored in the Cloud Providers > Credentials page will be needed. Here’s the acceptable format: “{{credentials | 2c91802a520736224015209a6393098322}}”
network: Cloud provider specific value (e.g. Virtual Switch1)
count: Total no of VM’s, defaults to 1.

In addition to these supported parameters, you will also notice that this template is referencing a “plugin”. A plugin can be invoked as follows:

plugins:
- !plugin
id: <plugin-id>

The plug-in can be created by Navigating to Blueprints > Plugins and then clicking on the + button. A plug-in is a simple script that can run on either the server being provisioned or on the Docker container. The server plugins can be used for any number of configuration requirements:

Installing Puppet Modules, Chef Recipes, Ansible Playbook, etc.
Retrieving the CA certificate needed for the private Docker registry from a secure S3 bucket and then saving it in the right directory (e.g. /etc/docker/certs.d/<domain-name>:5000/ca.crt)

The Machine Compose template has additional advanced options.

Cost Profiles — these are the cost profiles that you can create under Policies > Cost Profiles. You can define cost per resource on an hourly/weekly/monthly basis. You can attach multiple cost profiles to a single template — e.g. different cost profiles for the instance type, EBS storage used, etc.
Entitled Users — these are the users who are allowed to use this template to provision AWS instances. The entitled users do not have permission to manage or delete this template and will only be able to consume it.

Once the Machine Blueprint is saved, a user can request this machine from the Self-Service Library. A user can click Customize and then select the Cloud Provider and Cluster
to use for provisioning the Hyper-V Virtual Machines.

Once the Hyper-V VM is provisioned, a user can monitor key statistics like CPU, Memory, Disk Utilization and Containers Running. This can be done by navigating to Machines and then selecting Monitoring or Stats from the Manage
drop-down menu.

An in-browser terminal to the provisioned machine is also accessible. This can be accessed by navigating to Machines and then selecting Terminal from the Manage
drop-down menu.

A list of the deployed applications on a virtual machine is also accessible. This can be accessed by navigating to Machines and then selecting Apps from the Manage
drop-down menu.

Now that your cluster is set up, you can now run any Docker application on the newly created server(s). This can be done by navigating to the Library and then clicking on Customize on any of the published application templates. You can then select a Cluster and click Run.

Check out our published Docker application templates — including multi-tier .NET, ASP.NET, Java stacks, LAMP, LAOP & LAPP stacks, Mongo Replica Set, Couchbase Cluster, MEAN.JS, WordPress, Drupal, and many others.