Using Auto Deploy to Image ESXi 6.7 hosts - vSphere Tutorial

- [Rick] In this video, we'll learn about how Auto Deploy can be used to automatically deploy new ESXi hosts. So the purpose of Auto Deploy is to allow you to plug in a bare metal ESXi host, and have an ESXi image, and a configuration automatically installed on that EXSi host. So let's take a look at how it works. The first component that you need to set up if you're going to be configuring Auto Deploy, is a DHCP server. And so as the bare metal ESXi host boots up, it'll send out a DHCP request, and it'll get an IP address, and the address of a TFTP server from the DHCP server. So really the only configuration that we need with this bare metal host, is to configure it to do a DHCP request upon boot, and now gets an address, and the address of a TFTP server from the DHCP server. And so now the ESXi host will reach out to the TFTP server, and it'll get a PXE boot file. And the PXE boot file is basically just enough information for this ESXi host to boot up, and to issue an HTTP request to the Auto Deploy server. And so now the ESXi host will issue that HTTP request to the Auto Deploy server, which is actually just your vCenter server, and it'll request an image, and depending on the rules engine of Auto Deploy, a certain image will be deployed to this ESXi host. So rules can be assigned to send different images to different hosts based on their MAC address, based on the vendor of the host, based on a fixed DHCP IP address, so we can set up rules to send certain images to certain hosts. And the rules engine is the part of the Auto Deploy server that makes those decisions. So when this image request hits the Auto Deploy server, it'll analyze it's rules engine to figure out which image profile it should give to this bare metal ESXi host. And then it'll go ahead and deploy the image to the host, and now the image can successfully boot up as an ESXI host, so now we've taken a bare metal host. It booted up, it did a DHCP request, it got the address of the TFTP server as part of that DHCP string, it got a PXE boot image from TFTP, reached out to Auto Deploy and it got a full ESXi image, and now we've completely imaged this ESXi host. And so the next step in this process is going to be to actually apply a configuration to the ESXi host, so as part of Auto Deploy, this ESXi host is getting added to a vCenter inventory. So when the Auto Deploy process finishes, this host is already going to be manageable by our vCenter server. And so now, a host profile can be used to apply a standardized configuration to this ESXi host. And so now the host profile is used to apply that config, and to get that ESXi host all ready to go, and now not only have we imaged it, we've given a complete configuration according to our standard config with host profiles. So, what is this image made up of? Auto deploy is going to install images on these ESXi hosts as they boot. What is the image made up of? It's made up of a set of VIBs, our VMware infrastructure bundles. And every image profile includes a base VIB. That's ESXi itself, so we always have that base VIB, but then we can have other VIBs add in, like partner solutions and drivers, on top of that base VIB. So you can actually create your own image profiles if you'd like to using image builder, but many vendors provide their own prepackaged images with all the correct drivers and add on software that you may need for a particular model of ESXi host. So most of the time, you can utilize a pre-packaged image from your vendor, without having to actually build an image yourself. But if you do choose to build your own image, there's a tool built into Auto Deploy for that called image builder. So here I am at Docs.VMware.com again, and I'm look at the vSphere 6.5 documentation on image builder, and I just want to take you on a quick tour of the documentation here, and give you a rough idea of what to expect with image builder. Now image builder is a command line tool, you can see here you're going to have to install PowerCLI and all prerequisite software. And so that's really step one, is to install ESXi Image Builder and all the prerequisite software, including everything you need for PowerCLI. And once you've got those pieces in place, then you can go ahead and configure the ESXi Image Builder service startup type. So by default, the ESXi Image Builder service is disabled on the Windows version of vCenter. In the vCenter server appliance, the service is set to manual, so we just have to turn on this service before we can start creating images. And then we start utilizing PowerCLI. So the documentation is a great reference to show you, how do you add software to an image profile, how do I add all of the different VIBs to an image profile? And then once I'm done creating that image, I can save it to a software repository. And that software repository can be accessed by Auto Deploy to distribute those images to my ESXi hosts. So if you're just getting started with PowerCLI, here's a website called notesfrommwhite.net, and I found this one, and it has an excellent little reference as to how to get started with PowerCLI. And so it walks you through all the basics, like how to actually install PowerCLI, how to show the available modules, and how to set the execution policy. Those are a couple of the key tasks that you need to perform prior to really getting going with PowerCLI, so if PowerCLI is new to you check out this article, because it'll give you a great idea of how to get started. So while we're looking at documentation, I want to show you one other article here on a website called enterprisedaddy.com. And this is the best reference I found for how to set up Auto Deploy from beginning to end. It's a very simple, nice walkthrough, so let's take a moment to look at some of the steps involved, and some of the great screenshots that they have included here. And again, this is at enterprisedaddy.com. The vSphere 6.5 Auto Deploy on vCenter 6.5, so you can see here, what you're doing first is just simply launching the vSphere web client, and enabling the Auto Deploy service. We just talked about that a moment ago. So now the Auto Deploy service has been enabled, and what they're doing in the next step, is under auto deploy, you can see here there's a download TFTP boot zip. So this is the little TFTP file that we're going to distribute with our TFTP server. So remember, our ESXi hosts are going to boot, they're going to get an IP address from DHCP, and then they're going to reach out to this TFTP server that we are configuring here. And we can use any TFTP server we want, SolarWinds has a nice free one, they mention that here. So once we've got the TFTP started, we'll go ahead and place the TFTP files that we just downloaded in there, and we'll set up our DHCP server as well. So here you can see, they're setting up some reservations in DHCP, and here we can see the scope options, this is the part I really want to take a look at. So in your DHCP server, what it's doing is it's distributing a bootfile name. And so this is one of our DHCP options pointed to a boot server host name, which is 192.168.1.2, and a bootfile name. This is that basic little PXE boot file that your ESXi host is going to reach out to the TFTP server to download, and so it'll actually boot from these files that we've hosted on the TFTP server. So those are our prerequisites. And Auto Deploy used to be a lot harder to configure than it is now, Auto Deploy is much easier than it used to be, it used to be purely command line. But now you can go into Auto Deploy in the vSphere web client, and you can specify a software depot. This is where all of my images are going to be stored. So we'll go ahead and browse to a software depot, where our images are stored, and here you can see the images that are in this software depot. So all of my image profiles, these are the images that I've created, or maybe these are just images that we've gotten from our software vendor. Or maybe they're just basic ESXi images from VMware. So from there we have to start setting up our deploy rules. And so let's take a look at some of the rules in the rules engine here, they're creating a new rule that is going to deploy an image based on the MAC address. So those are one of their criteria choices that we can use for auto deploy to set up this rules engine, or we can just simply send the same image to all hosts. So if all our hosts are getting the same image, we can do that here. And then we'll go ahead and choose the image profile that's going to be associated with this Auto Deploy rule. So all of the hosts with the MAC address that they just specified, are going to get this ESXi 6.5 standard image. And then, the host is going to boot from that image, and we also need to apply a configuration to that host. So here we're specifying the host profile that's going to be applied to these hosts as they boot up. This is going to handle all the configuration of that host after it boots with an image. And I'll choose the location where these hosts are going to be created, so I can choose either a virtual data center or a folder, or even a host cluster that it should be added to, here they're choosing a host cluster that the host should become a member of, and when you're all done creating your rules you'll go ahead and hit finish, and then you'll simply activate the new rule that you've created. And now, as you can see in their screenshots here, they start booting up an ESXi host, the host comes up, successfully boots with that image, and then there are a bunch of host profile settings that are actually non-compliant, so the host profile can't do absolutely everything. There are certain things about hosts that you may need to manually configure, like for example, every host can't have the same IP address. There might be also storage settings, and things like that, that you need to manually override, so you can check compliance with your storage policy, and then you can just go ahead and fill in the blanks, whatever that storage policy needed, whatever it was missing, whatever's non-compliant, you can fill in those blanks for that host and bring that host into compliance with the storage policy. And then the final step I'm showing you here is doing a storage rescan, and we've got a host that is now compliant with our host profile, and that's really the entire process. So this is a great document, because it not only gives you all of the steps for Auto Deploy itself, but it also walks you through a lot of these prerequisite steps and what they mean as well. So it's a really high quality walkthrough of the Auto Deploy installation set up process, and how the hosts actually boot and get those images. Okay, so there are a few other options that you need to be aware of when it comes to Auto Deploy. We can do either stateless, stateless caching, or stateful installs with Auto Deploy. And these are going to impact how you do things like upgrades, so auto deploy is a great way to easily upgrade your ESXi hosts. So, let's think about first a stateless. So here's a bare metal ESXi host, it has no local physical storage at all. It's got memory, but it doesn't have any physical storage. And so as this ESXi host boots, it does it's DHCP request, it gets it's PXE boot image from TFTP, it reaches out to Auto Deploy, and the Auto Deploy rules engine determines the appropriate image for this ESXi host, and deploys that image to the host. And the image goes into memory. There is no persistent storage of that image anywhere, so what I mean by that, is if I now reboot this ESXi host, that image is gone, and it's going to reach out to Auto Deploy again upon reboot, ask what image, the rules engine will be used to determine the correct image, and that image will be deployed to the host. So, if my hosts are on 6.0, let's say they're on ESXi 6.0, and I want to bring 'em up to 6.5, I can just change my rules engine, reboot those ESXi hosts, and they'll all get a new image from the Auto Deploy server. So that's the stateless mode of Auto Deploy. Let's take a look at another mode called stateless caching. So in this case, the ESXi host does have some sort of local storage, it's got a little bit of local capacity, so when this ESXi host boots, it's going to get a DHCP IP address, it's going to get a PXE boot image, it's going to reach out to Auto Deploy, and based on the rules engine, it's going to get a particular image. And that image is going to be persistently stored locally on that ESXi host. So that's stateless caching, now what difference does that really make? Well, let's say that for some reason the auto deploy server is unavailable. So if the auto deploy server itself goes down, and I try to reboot this ESXi host, it's got a local copy of that image it can use as a backup. So that means that this ESXi host can boot up even without the Auto Deploy server. And if we think about our stateless example, where it just put the image in memory, if I reboot that host and Auto Deploy isn't around, that host is not going to successfully boot. So stateless caching keeps a copy of the image on local storage, but with stateless caching, the primary option, when the host boots it's always going to try to pull an image from the Auto Deploy server. Right, so plan A is to try and pull an image from the Auto Deploy server, if it's down, then and only then will it boot from the local image. So the local image is strictly a backup when it comes to stateless caching. When it comes to stateful install, again, the host has local storage, it boots, gets an image from Auto Deploy, and that's the image that it uses from that moment forward. And so a stateful install is a little bit different, because it's going to get an image once from Auto Deploy, and that's it, if I reboot this host, it doesn't reach out to Auto Deploy again. So this is a great way to get a new host imaged and to locally install the image on that host, but it doesn't really help so much with things like upgrades, and if I want to upgrade from ESXi six to 6.5, or from 6.5 to 6.7, this stateful install option isn't going to really help me do that, because the ESXi host is always just going to use that image that's on local storage.