Getting started with virtual machines

Cloud computing has swept the world, but it wouldn't be possible without virtualisation and virtual machines (VMs). They've revolutionised both server computing and some desktop computing, too. In this tutorial, we'll learn how to create a virtual machine in the cloud.

VMs evolved because of a problem that sysadmins faced in server environments: They didn't want to run too many apps alongside each other on a single server because these can interfere with each other, causing security issues or performance problems. In the worst case, an app that crashes a server could bring down the other apps sharing the box.

So admins would run one or two apps on a single physical box. That involved them paying for resources they didn't need, including the space and power taken up by each server. A single app rarely used all that server's memory or CPU power, so they sat idle a lot. Managing lots of physical boxes is also cumbersome.

VMs solved many of those problems. They recreate regular hardware machines in software, presenting CPU power, RAM, and other hardware assets as an operating system (OS) would normally see them, but filtered through another piece of software called a hypervisor. 

When you install an OS in a VM, you're actually installing it on the hypervisor, which also supports many other VMs running separate OSs. When an OS accesses computing power, disk, or memory, it accesses the real, physical hardware assets but via the hypervisor. The hypervisor coordinates everything so that every OS running in a VM gets its own bit of that resource. The VMs also don't clash with each other when running on the same physical box.

There are two different kinds of hypervisors. A type one hypervisor runs directly on the underlying physical box, replacing the operating system. This is commonly used in server configurations. There are also type two hypervisors, which you install on top of an existing OS. These are common on desktop machines. Examples include Parallels and VMware Workstation, which let you install extra operating systems on top of macOS, Windows, and Linux.

You can run a VM on your own server, but admins are increasingly running them on cloud services like Amazon Web Services and Microsoft Azure instead. That way you don't even need your own server hardware. Let's set one up on Azure.

You can set up a VM via the web interface, but doing it via the command line gives you more flexibility. You can access the command line via the cloud shell, which is a browser-based command line interface in your Azure account. Access the cursor icon just to the right of the search bar on your Azure dashboard. That will serve most use cases, but you can also access it from PowerShell, which is what we'll do here because this allows us to access the VM using Remote Desktop Services later.

You'll need a copy of PowerShell installed, along with an Azure account that includes a storage account - this is a sub-account needed to store your data in Azure.

To control Azure from PowerShell, you'll need to install the Azure module for the current user. Run PowerShell as administrator, and type:

Then, we'll log into Azure from PowerShell:

When run in PowerShell on Windows, this will open a login box for you to sign in using your Azure account. After that, you'll see PowerShell list your account in PowerShell, including your Tenant ID.

In Azure, virtual machines exist in a resource group. This is a group of assets that you can grant access to. You might set these up on a per-project or a per-department basis.

We'll begin by creating one:

It'll tell you that it's succeeded (type get-AZResource to find out more about it), but the resource group doesn't have anything in it yet. Let's change that by creating a VM.

We'll start by creating administrative login credentials for the VM. We'll assign these to a variable called $tempcredentials:

Enter that to get a credentials prompt and enter the login details you'll use for that machine.

Now, here's the code to copy and paste:

We're assigning the configuration parameters for the VM to the $vmDetails variable. The first few properties, ResourceGroupName, Name, and Location are self-explanatory.

The virtual network (VNet) is a software-defined network that the VM will use to communicate with other VMs and services in that Azure subscription. VNets have subnets to help separate resource traffic, so that your sales department's VMs can't snoop on your technical development team's traffic, for example. Network security groups provide an extra layer of security by letting you block or allow inbound or outbound traffic from a resource.

Credential gives the VM the temporary credentials that we created, while the PublicIPAddress name maps the VM to an IP address in Azure. OpenPorts lets you expose network ports to other resources on that subnet so that they can access services running on your VM.

Now you've created its parameters, you can create a VM and assign it to a variable called $testVM using this code:

Once this has finished, you can wave hello at your VM by typing get-azvm to list your virtual machines. Pipe this into the format list command (fl) to get more information about those machines using get-azvm | fl.

Because you put this into a variable when you created it, you can easily list the VM's properties by just typing the variable:

This doesn't tell you what the virtual machine's IP address is, though. Get that by typing:

Copy the IP address this returns, and we'll use it to access the machine. This is something that you can do from your local PowerShell instance but not from the Cloud Shell, because it invokes Remote Desktop Services on your local machine. Type this into PowerShell, replacing <IP> with the IP address you copied:

The VM takes a minute or two to go through its setup process, and then you're logged in.

We can manipulate the VM by stopping it:

After a few seconds (the cloud is scalable and flexible but it isn't instant), the VM will stop. Once it's reported success, try starting it again:

Now let's tidy up after ourselves. Removing virtual machines themselves is easy enough but it's more difficult to remove all the other assets that are created along with them. For our purposes, the easiest way is to just delete the whole resource group. Type:

This can take a while to delete, but you can check on its status by typing:

There are many things you can do with VMs, such as moving them between resource groups, resizing them to fit your operating requirements, and querying their runtime conditions, all of which you can do via PowerShell. They're a great resource for everyone from enterprises to enthusiasts who want to set up simple projects without investing in a server.