Okay, in this demonstration we are going to go ahead and create our virtual machine, but there's one more detail we need to look up before we can create it.

Let's call the "azure vm" command, and if we scroll up towards the top, there's the "azure vm sizes" option. So if we call "azure vm sizes" this is going to show us the pre-configured V. M. sizes that are available for us to deploy into our subscription. So we're going to go ahead and call "azure vm sizes --location westus" and as you can see the result set here shows us all the sizes available.

First we have the standard and basic A-series virtual machines which are your typical, run-of-the-mill virtual machines. Then we have the D-series virtual machines which give us a solid state drive for our local disk, or temporary disk in Azure. Then we have the G- and GS- and DS-series V. M.s. Now, the GS- and DS-series virtual machines are special because they're explicitly designed to work with Microsoft Azure's premium storage service which allows us to deploy a virtual machine onto SSD-backed storage.

So, let's go ahead and grab the standard DS1 size, and that's what we're going to use to provision our virtual machine. So now that we've got that last piece of information, let's go ahead and take a look at the process of creating a virtual machine. We're going to run the "azure vm create" command with the "--help" parameter, and you're going to see a pretty large list of input parameters for the "azure vm create" command.

Now, as you'll see, we deploy the virtual machine into a resource group. We need to specify a name for the virtual machine. We need to specify the network interface name, which we've already created. We also need to specify the location or Azure region that we're going to deploy the Azure V. M. into. We have the operating system type parameter which accepts either Windows or Linux as input values. We also have the image U. R. N. which we already talked about in another lecture. Then we've got the admin user name and admin password that we'll assign, to log in to the virtual machine using R. D. P. after we've provisioned it. Then we have the "vm-size" parameter. And we've already created our public I. P. address, so we're not going to explicitly add that on our virtual machine. We also specify the storage account name, and that should do it for us.

There's one more key thing that we have to discuss though. We also have to specify the "disable-boot-diagnostics" parameter, and the reason we have to do this is because when we deploy an Azure virtual machine onto premium storage, at the moment, premium storage does not support the boot diagnostic extension for V. M.s. Okay, so let's go ahead and start building out our command line.

I'm going to call "azure vm create" and then specify the location which is "westus," the resource group which is "CloudAcademyVNet," then I'm going to specify the NIC name, and the NIC name is "vm01." I'm also going to specify a name for the virtual machine itself, which I'll just call "vm01." The O. S. type and image U. R. N. are next, so let's go ahead and specify "os-type Windows" and "image-urn" and I'm going to grab that value from my other terminal session here. So I'm just going to copy and paste the image U. R. N. into there. And then I need to specify the storage account name, which is "cavnet." I need to disable the boot diagnostics extension. And let's take a quick look through these parameters to see if we've missed anything else.

Well, we also have to specify the V. M. size so let's go ahead and grab that. We need the admin user name and the admin password as well. And aside from that, I think we're looking pretty good. So let's specify "admin-password" as "CloudAcademy," and the admin user name we'll call "CloudAcademy," and we'll just add a couple of special characters to the password there. And then also, let's add the OS type, which is Windows.  Okay, so let's go ahead and try to run this command and see what we get. Okay, so we've added a couple of characters to our admin password, and we have added the "vm-size" parameter as well, and we are now creating the virtual machine.

So as you can see, we've deployed a standard, DS1-size virtual machine. And we have looked up the storage account, it says, "Okay the storage account's already there, I'm just going to skip that." It says, "Okay, there's already a pre-existing network interface so I'm going to use that and ignore any public IP addresses." And now, we're actually creating the virtual machine itself. So, in a couple of minutes here, after the virtual machine is finished provisioning, we'll take a look at it and how to remotely access it.

Okay so, our command timed out when creating the virtual machine, but that's okay because we can still validate that it actually got created by using the Azure X-plat C. L. I. tool. So now I'm going to call "azure vm list" and then tack on the "resource-group" parameter so that we can look at our "CloudAcademyVNet" resource group.

So when I run "azure vm list" you'll see that the virtual machine that we created, "vm01," got created inside the Cloud Academy V-net. And the current state is that it's running in the "westus" region, and sure enough it's a standard DS1 system.

Okay, so to connect to our virtual machine, we'll go ahead and fire up the remote desktop client, and we will connect to "CloudAcademyVNet.westus.cloudapp.azure.com." Let's go ahead and close that and save it, and as you can see we get the warning to verify the certificate, so we'll just hit continue there. And at this point we can start managing this virtual machine like any other.

So that's a demonstration of how to provision a virtual machine using the Azure cross-platform C. L. I. tool. And this is an imperative provisioning model, rather than a declarative provisioning model, which uses ARM JSON templates.

So now, let's go ahead and just clean up all the work that we've done. So we're going to call "azure group delete" and then we're going to specify the name of the group which is "CloudAcademyNVet." And we'll add the "--quiet" parameter on there so that it doesn't prompt us to delete the resource group. And, after the resource group has been deleted, you'll no longer be billed for the resources that have been provisioned inside of that resource group.