WilliamLam.com

Automated network scripted installation of ESXi-Arm without SD Card

by // 5 Comments

A topic that I have been working on even before the release of the ESXi-Arm Fling is the ability to perform a network scripted installation (Kickstart) of ESXi-Arm for the Raspberry Pi (rPI) but doing so without the need of an SD Card plugged into the rPI itself. The latter point is critical as today, the SD Card is used to house the required UEFI files to allow the rPI to boot the ESXi-Arm installation files which can be served from a local USB device or remotely over the network using HTTP, NFS or even iSCSI boot, which Andrei had recently blogged about.

Running through the SD Card preparation is not a difficult process and if you only have a single ESXi-Arm host, this may not be all that interesting other than learning about how this works and setting up a basic Kickstart environment. However, if you have several rPI and maybe you do not have spare SD Card and you prefer to make it easy to deploy additional ESXi-Arm host, this is a pretty cool solution. The precursor to this work was actually from a blog post I had published a few weeks ago on copying the rPI UEFI files and booting ESXi-Arm off of a USB device.

Once I figured out how that worked, it was simply figuring out the automation required during the %post section of a scripted installation of ESXi-Arm to pull down a copy of the UEFI files which is then copied onto the first partition of the USB device and thus allowing you to completely boot off of the USB device after installation. This took some trial and error playing around with mcopy which is a tool I have written about to help copy files to and from a USB device using the ESXi Shell. The other trick that we are taking advantage of here is that the USB device that you intend to use are mostly the same from a UEFI point of view and by disabling all other boot option, we ensure that after the UEFI files are copied over to ESXi-Arm host, it will boot from USB device rather than over the network.

[Read more...]

Configuring dnsmasq as PXE Server for ESXi 

by // 2 Comments

One really cool thing that I came to learn while setting up the infrastructure to network boot the latest Raspberry Pi 4 was the use of dnsmasq, which I have used in the past but I did not realize it could do so much more. In addition to providing DNS services, it can also be configured to run TFTP and provide DHCP capabilities which can then be used to support PXE installations.

Another neat feature of dnsmasq is ability to proxy to an existing DHCP server which is extremely useful for anyone with an existing DHCP infrastructure. Given the simplicity of dnsmasq and having already set this up for the rPI, I figure it would also be useful to take folks through in setting up dnsmasq to also support ESXi installations over PXE, since this still comes up from new folks just getting started with ESXi kickstart automation.

For more details about PXE installation of ESXi, I highly recommend this whitepaper and although it states 6.0, the concepts and configurations are still applicable to the latest ESXi 7.0 release.

[Read more...]

How to evaluate vSphere Data Protection without DNS?

by // 15 Comments

A fellow colleague of mine was looking to deploy the latest vSphere Data Protection Advanced (VDP[A]) 5.5 in his lab this past week to check out some of the new enhancements made to VDP and interoperability between other VMware solutions. However, he was unable to move forward with his evaluation due to the mandatory DNS requirement for VDP. I can understand the need for having proper DNS in a production or even a POC environment but for a quick evaluation or home lab it is a bit much. In my opinion I think it is a nice to have but it should not be a mandatory requirement.

As part of the networking settings, VDP assumes that configured IP Address is fully resolvable both forward/reverse lookups and manually adding an entry into /etc/hosts will not work. If you try to move forward in the wizard, you will receive this nice error message.

I decided to look into this as I faced a similar challenge in my personal home lab which does not have a DNS Server due to limited resources unlike my remote home lab which has a proper DNS server running. Though we can not get rid of the DNS requirement since it is part of the VDP code, we can however leverage an application found within VDP to help us. This nifty little application is called dnsmasq which is a lightweight server that provides basic DNS, DHCP & TFTP services for a small network which works great for an evaluation or home lab.

Disclaimer: I have been able to verify basic VDP functionality including a complete VM image backup/restore using the method below. However, it is still recommended that you still have proper DNS configured in your environment for in-depth testing of VDP, especially when evaluating for a production environment.

Step 1 - Deploy the VDP OVA as you normally would and when you specify the network configurations, ensure you set the DNS entry to 127.0.0.1 (loop back address) and then you can power on the VM after deployment.

Step 2 - Once VDP is up and running, SSH into the system using root as username and changeme as the password. We will then need to update /etc/hosts to reflect the IP Address/Hostname of our VDP appliance as well as any others you may want VDP to be able to resolve. In my environment I have the following:

192.168.1.104 vdp.primp-industries.com vdp
192.168.1.103 vcenter.primp-industries.com vcenter
192.168.1.200 mini.primp-industries.com mini

Note: I would also recommend adding your "search" domain into /etc/resolv.conf (e.g. search primp-industries.com)

Step 3 - Next we need to edit the dnsmasq configuration file located in /etc/dnsmasq.conf and add the following entry (replace it with the IP Address you have assigned your VDP appliance):

server=192.168.1.104

Step 4 - Finally we just need to start the dnsmasq service as well as enable it to automatically startup on boot by running the following two commands:

/etc/init.d/dnsmasq start
chkconfig dnsmasq on

Step 5 - To confirm that everything has been configured correctly, we will perform both a forward and reverse lookup of our VDP hostname and IP Address. You can do so by using "nslookup" command or any others such as dig or host. In this example, I will be using nslookup and you will need to run the following two commands (ensure to replace it with your hostname/IP Address):

nslookup vdp.primp-industries.com
nslookup 192.168.1.104

Once you have confirmed both forward and reverse lookups are successful, you can then proceed to configuring your VDP appliance by opening a browser to https://[VDP-ADDRESS]:8543/vdp-configure and proceed with moving forward with the VDP configuration wizard.

Note: Ensure that 127.0.0.1 is shown in the VDP configuration UI for the DNS entry. For hostname, you will need to use the short hostname even though a hostname is officially defined as specifying the FQDN

One of the cool new features that I personally wanted to check out is the new emergency Direct-to-Host Emergency Restore functionality. This feature allows you to restore VM backups in the scenario that vCenter Server is not available and one such use case is when you are using VDP to backup vCenter Server itself which I have been able to successfully test in my home lab.