We stamp windows: automated deployment of Windows virtual machines to Hyper-V using Vagrant (part 3)

In previous ( one , two ) publications I told how to prepare a hypervisor and box for subsequent automated deployment. In the last part of this trilogy, I would like to reveal the theme, in fact, of deployment and provisioning of the prepared boxes. Also here I will summarize the work done and at the end you can find all the links on the topic.

After the box has been added to Vagrant, we can quickly “revive” it by lifting a car (or several) from it. All metadata about it will be stored in the same directory, next to the images of hard drives. Let's go through this simple procedure.

On the desired drive creates a folder with an arbitrary name. I prefer to call them by car name to heighten order.
Through Powershell or the command line we go inside this directory.

To initialize the folder, you need to run the vagrant init command:

vagrant init Win2012R2x64

The parameter specifies the name of the box that we want to expand here. In principle, it can always be corrected later. As a result of the command execution, a file is created in the directory with the straightforward name Vagrantfile, in which the minimum parameters of the lifted machine are specified in the Ruby language: provider (hypervisor), OS type, and box name. Basically, I prefer to just copy the finished file, rather than edit the template. A description of all the parameters can be found in the documentation, I will only give my example with working provisioning (the listing is available on Gist ):

Vagrantfile

#    -  ,    .   . # -*- mode: ruby -*- # vi: set ft=ruby : # Vagrantfile API/syntax version. Don't touch unless you know what you're doing! VAGRANTFILE_API_VERSION = "2" Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| #      config.vm,     . #      config.vm.box = "Win2012R2x64" #   ,     windows config.vm.guest = :windows # ,    Vagrant      .       ,   ,      Hyper-V.   -    “default”. config.vm.define :godnota #      .   SSH,        - WinRM config.vm.communicator = "winrm" #    .     Chef,           . ,       ,    Vagrantfile.     ,   -,      -      (, \\\\server\\DevOps\\Vagrant\\provision.ps1),     . config.vm.provision "shell", path: "provision.ps1" # , ,   Vagrant     .     ,       5,      sysprep,         config.vm.boot_timeout = 300 #   ,    ,    config.vm.graceful_halt_timeout = 180 # Vagrant   (     SMB)      .      ,        Windows     ( Ubuntu hashicorp/precise64   ),        config.vm.synced_folder ".", "/vagrant", disabled: true #    Hyper-V.    ,        , ,    . config.vm.provider "hyperv" do |hv| hv.ip_address_timeout = 300 end #   -   ,     .    ,      (     ). config.winrm.username = "Administrator" config.winrm.password = "P@$$word" end

What happens at the shell provisioning stage? If, after booting, the system has fully risen (and not stuck on some question that was forgotten to be answered in the unattend.xml file), the Vagrant connects to the VM, creates a temporary folder on the system disk (usually C: \ Tmp), throws There the script and locally runs under the user specified by us. You can do a lot of useful things in the script file, I just want to show what I wrote there (the listing is available on Gist ):

provision.ps1

 #  Chocolatey  .       ,      ,        .  ,         ,         iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1')) #  Boxstarter    cinst boxstarter $env:Path+=";"+$env:AppData+"\Boxstarter" $env:PSModulePath+=";"+$env:APPDATA+"\Boxstarter" Import-Module Boxstarter.Chocolatey $Boxstarter.AutoLogin=$true #     Set-WindowsExplorerOptions -EnableShowHiddenFilesFoldersDrives -EnableShowFileExtensions #    RDP Enable-RemoteDesktop #   Far  7-zip choco install far,7zip -y #    Classic Shell,      Start choco install classic-shell -installArgs ADDLOCAL=ClassicStartMenu -y #     del C:\Users\Administrator\Desktop\*.lnk #     Install-WindowsUpdate -AcceptEula -SuppressReboots Restart-Computer

In principle, nothing special, except that some commands, including Install-WindowsUpdate, are Boxstarter modules (for which we love it).

Ideally, after that you can shove our script into the folder to execute the coveted vagrant up command. However, after that there may be some difficulties. I would like to immediately warn about them:

It happens that when you try to raise virtuals you get an error from Powershell indicating that it cannot have an IDE drive. This is a well-known bug, which is related to the fact that if the box is prepared in the second version of the Hyper-V virtual machines, then there really are no virtual IDE controllers as a class , which our Vagrant has no idea at all. The misunderstanding is treated very simply, editing the VM import script: C: \ HashiCorp \ Vagrant \ embedded \ gems \ gems \ vagrant-1.7.2 \ plugins \ providers \ hyperv \ scripts \ import_vm.ps1 - in the appropriate lines you need
replace “IDE” with “VHD”
```
  # Determine boot device Switch ((Select-Xml -xml $vmconfig -XPath "//boot").node.device0."#text") { "Floppy" { $bootdevice = "floppy" } "HardDrive" { $bootdevice = "VHD" } "Optical" { $bootdevice = "CD" } "Network" { $bootdevice = "LegacyNetworkAdapter" } "Default" { $bootdevice = "VHD" } } #switch 
```
Remember this way, it may still come in handy: for example, if you stumble upon unknown hitherto errors or want to screw something there.
Another nuance associated with the order of loading. The fact is that even if the original machine had priority on booting from a hard disk, when launching the above file it somehow decreases and as a result, when it first starts, the system tries to boot from the network via PXE for a long time and as a result Vagrant may not wait for the download and cannot determine the IP address. Observed in the machines of the second generation. Usually this is not what is required, so you need to either track when the virtual machine is turned on and quickly reload it, having previously set the correct priority in the settings, or build a crutch above the above-mentioned import file: before the line “$ vm_id = (Get-VM $ vm_name). id.guid ”you need to add a couple of lines:
```
 if ($generation -eq 2) { $hddd = Get-VMHardDiskDrive $vm_name Set-VMFirmware $vm_name -BootOrder $hddd } 
```
The condition is necessary because VMFirmware is not supported on first generation machines. As a result, the VM will have only one option for downloading - the VHD file.
The import_vm.ps1 script in version 1.7.2 cannot correctly add several disks to the lifted machine. This is due to the fact that it does not copy the name of the VHD file (and the file itself is not copied), but sets the default “disk.vhd” transmitted from import.rb, and an error occurs when the second disk is connected:
Cannot add 'disk.vhdx'. The disk is already connected to the virtual machine 'Windows2012R2x64' '. (Virtual machine ID 35449990-E3D2-4BE1-99E5-2CAACC537097).
This is a known issue . So far I have not been able to defeat her in a hurry, so I will be glad if someone tells you how to overcome it. Otherwise, it remains to wait until the developers correct it.

That's all! Now you can stamp virtual machines in any quantity (well, how much hypervisor resources are enough, of course). If you do not rename the instance name (and it is taken from the box), then the name simply adds “_1”, respectively, another one will have “_1_1” at the end (and not “_2”): the import_vm.ps1 file is written.

If something did not work out and everything did not go smoothly, you can always try working with someone else's box. Unfortunately, I can’t give my own (I have already got license keys and certificates), but you can use the box of Mat Rock, which was already mentioned in the article; since this box is available publicly from the Internet, you can add it with one command (by default, Vagrant searches for boxes in its cloud):

vagrant up mwrock / Windows2012R2 --provider hyperv

Raising about several cars

Well, in the end, we got a raise of the VM by pressing a few buttons. What to do when you want to install the whole environment at once? Of course, to do this, you need to script a little, but you don’t have to take up Powershell right away. Fortunately, the configuration files are written in Ruby, which allows you to pick up several machines at once from one Vagrantfile, with one command, and you can even specify several different boxes in one file. The procedure is described in detail in the documentation . With proper knowledge of the language, you can perform real miracles: for example, automatically, taking from the JSON file, assign network settings and host names to all machines, as well as roll Chef recipes on them depending on the role in the same file (for example, so ). However, this is far beyond the scope of this already-spread article.
')

Results

Well, what did we get as a result? The system of rapid deployment of Windows machines in their native environment, raising a ready virtual machine and customizing it according to our requirements.
How did this help our company? This significantly saves time on raising the new infrastructure: earlier installation of the system from an ISO file, setting up and updating all the software could take half a day, now it is a matter of minutes. Even cloning machines from System Center templates usually takes longer, not to mention the listed drawbacks such as inheriting virtual hard disk files. It is also a great tool for our developers and testers, who were able to quickly pick up on a local system (even on workstations with Windows 8.1) some kind of test environment. For this, I wrote a simple short instruction, so they do not need to delve into the details and distract from the workflow.
What's next? Now we are actively working on the analysis and documentation of existing environments, then to describe them in the form of recipes Chef. Our services are planned to be installed and rolled out as packages. This will automate many processes, get rid of a lot of routine and errors associated with the human factor. In general, what the doctor DevOps prescribed. Also plans to master Packer, if you need to quickly prepare a lot of different images. Support for Hyper-V and Azure appeared in it quite recently, but it looks very promising. Also in the plans is work on the quick synchronization of folders between the VM and the host - unfortunately, the usual sharing works rather slowly for a large number of files and active operations (for example, build).
If this article was useful and the topic as a whole is interesting, I will gladly make a separate publication about our subsequent victories and failures in this field.

We stamp windows: automated deployment of Windows virtual machines to Hyper-V using Vagrant (part 3)

Raising about several cars

Results

Links

More articles: