How to customize a VMware ESXi image and install it in a Hyper-V VM

I’ve been doing recently  VMware ESXi deployment in my lab environment and would like to share main steps required to make it work on nested Hyper-V. Needless to say, nested virtualization works great only for demo and labs, therefore, running ESXi under Hyper-V is a completely unsupported in production environments.

Anyway, carry out the following steps to install ESXi (6.0, in my case. although these steps should work for newer versions as well):

1. Download VMWare ESXi offline bundle available at product download page (e.g. ESXi6.0). You can also download a ESXi image customized by vendor. For example, here is a direct download link for Dell’s ESXi 6.0 image which includes Dell’s VIBs in addition to built-in installation bundles provided by VMware.

2. Download the driver  which allows running ESXi as a VM under Microsoft Hyper-V (net-tulip, it’s actually a network driver which should be added to ESXi image. Otherwise, ESXi installation will be blocked)

3. Copy the downloaded files to the same folder (e.g. ‘D:\Images\VMware ESXi 6\’). It’ll be used as a work folder.

4. Download and install VMware PowerCLI 6.3 or newer

5. Once PowerCLI is installed,  run it and set location to the folder containing the files, then add offline depot ZIP files to the current PowerCLI session as shown below:

cd 'D:\Images\VMware ESXi 6\'
Add-EsxSoftwareDepot .\esxi60_bundle.zip
Add-EsxSoftwareDepot .\net-tulip-1.1.15-1-offline_bundle.zip

6. Retrieve the name of the standard image profile and note it (it’ll will be used as a clone for a new profile):

Get-EsxImageProfile|ft Name

7. Create a new image profile by cloning existing profile which name you just noted, and then add the driver’s package to the profile:

#Create a new image profile
New-EsxImageProfile -CloneProfile ESXi-6.0.0-2494585  -Name rlevchenko.com -Vendor custom

#Add custom packages
Add-EsxSoftwarePackage -ImageProfile rlevchenko.com -SoftwarePackage net-tulip -Force

image

If AcceptanceLevel is set to PartnerSupported by default (as in the picture above) and custom packages which you are going to add to the image profile have Community acceptance level, you will receive an error during creating an ESXi ISO and it’s installation . To resolve this, set the acceptance level of the image profile to CommunitySupported by running the following command: Set-EsxImageProfile -AcceptanceLevel CommunitySupported –ImageProfile rlevchenko.com

image

8. Now it’s time to create an ISO from the customized ESXi image.To do this, run the following command:

Export-EsxImageProfile -ImageProfile rlevchenko.com -FilePath D:\Images\esxi60_custom.iso -ExportToIso -Force

Create a new VM with the following settings:

  • Generation 1
  • Static RAM (> 4Gb is recommended)
  • More than 1vCPU
  • Legacy network adapter connected to the switch

A sample of VM’s configuration is shown below:

image

9. Once you finished to configure a VM, enable virtualization extensions on the VM’s CPU. Optionally, you can download a script available at github to check VM’s configuration and  enable nested virtualization. Both options are allowed:

#Option 1
Set-VMProcessor -VMName "vHost-01" -ExposeVirtualizationExtensions $True

#Option2
 .\Enable-NestedVM.ps1 -vmName "vHost-01"

10. Turn on the VM, attach the created ESXi ISO and press TAB on the boot screen, then type ignoreHeadless=TRUE and press Enter. Otherwise, ESXi boot will hang while booting  (I assume it’s all because ESXi is running on non-HCL hardware. VM is a bit out of the HCL list..).

esxi on hyper-v_1

11. Complete ESXi installation process (as usual), reboot it and press SHIFT+O during the startup, and then enable ignoreHeadless option again as shown in the screenshot:

esxi on hyper-v_4

Once ESXi is successfully started, define settings for management network, enable a Shell, and then press Alt+F1 to enter to a console. We need to set a VMKernel boot-time parameter. Otherwise, you will always need to enable ignoreHeadless after every reboot.

Provide root credentials and  type esxcfg-advcfg -k TRUE ignoreHeadless

esxi on hyper-v_6

Close the console by pressing ALT+F2, reboot ESXi and verify that it starts up seamlessly.

That’s it. Now you have a ESXi host running on a Hyper-V VM.

Until then,

enjoy your day :)!

Disaster recovery for Azure IaaS VMs

Every organization needs a business continuity and disaster recovery (BCDR)  strategy to keep data safe and react to unplanned or planned outage in the best way. Azure Site Recovery (ASR) significantly simplifies these processes providing replication, failover and failback functionalities for your major IT systems.

azure site recovery for azure vms_6

ASR can be used in the following scenarios:

  • VMware VMs replication to Azure w/CSP (uses InMage Scout software)
  • Physical servers to Azure (uses InMage software as well)
  • VMware VMs/Physical servers to a secondary site (through InMage Scout)
  • On-premises Hyper-V VMs without VMM to Azure (Hyper-V Replica inside)
  • On-premises Hyper-V VMs with VMM to Azure (Hyper-V Replica inside)
  • On-premises Hyper-V VMs with VMM to a secondary site (Hyper-V Replica inside)
  • Multi-Tier applications (uses SQL AlwaysOn AG, for instance)

But yesterday Microsoft officially extended this list by adding possibility to replicate Azure IaaS VMs running on Windows/Linux to another region within the same geographic cluster.

Now, you may ask, why we need this if Azure already provides high-availability and reliability for every business critical workloads. Official statement says that it’s required by ISO 27001 and it’s compliance requirements.

Furthermore if you’d like to be able to completely meet BCDR strategy in the event of disaster and you are not happy with built-in Azure protection features – new option can also help (seamless failover and failback between different regions to keep RTO/RPO very low)

TIP: this ASR scenario is in public preview state for now.

azure site recovery for azure vms_1

Demo

As usual, you need to create ASR vault  and enable replication for workloads. You should place ASR Vault at the TARGET location/region to make it work (wizard also checks it automatically).

It’s simple..if source location is down, ASR vault and resource groups will be also offline and your BCDR strategy will be failed –> ASR vaults should be always in the target region

I‘m using ASR created in UK West region and my workloads are running in West Europe DCs. Regions are in the same geographical cluster (Europe).

TIP: new managed disks and VMs scale sets are not supported + temporary disks always excluded from replication

azure site recovery for azure vms_3

You don’t need to prepare target infrastructure. ASR does almost all “dirty”” work by itself (network mapping, target networks/groups and storage/cache accounts + availability sets if they are in use in the source region) Continue reading “Disaster recovery for Azure IaaS VMs”