The trick here is a one line Python command that simply creates a HTTP server listing the files in your current directory over a given port. On my MacBook, I opened Terminal and ran the following command:

If I then open my browser, and point it to the IP address of my MacBook, I get a directory listing showing the contents of the current directory.

As you can see, the directory contains a few files, namely a Damn Small Linux appliance packaged as an OVA, as well as the Linux installation files for ovftool.

In this particular case, I wanted to install ovftool inside a running vMA instance I had in my infrastructure. So, by running the following commands I got ovftool downloaded via HTTP, from my MacBook, inside a running vMA instance by only downloading the files in to a given directory and serving it via HTTP from there to vMA.

By running the following command (output edited for verbosity)

I was able to download and install ovftool, in one command.

The same deployment method could also easily be used to install host patches, deploy OVF based appliances and even install VIB files from a central repository. In fact, that`s the next thing to do here, deploy the Damn Small Linux appliance, by using the newly installed ovftool package.
The flexibility of having a small HTTP server available by running a single command is great, and I`m sure there are many other use cases that I have yet to consider.

Christian Mohn

Anyway, the following procedure upgraded the host from 5.1b to 5.1U1, by downloading the upgrade directly from VMware and installing it. Make sure the host is in maintenance mode before attempting this procedure.

Check Correlating vCenter Server and ESXi/ESX host build numbers to update levels (1014508) to determine which of the update files in the repository to download.

SSH into your host, and issue the following command:

This will initiate a download of the new ESXi version and install the update automatically, beware that it will not show any progress bar or indication while the file is being downloaded from the VMware repository.

The command above will only work, as Erik pointed out in the comments, if you have allowed the httpClient outgoing access on the ESXi server. If not, you can enable it by running the following command on the host (or by using the vSphere Client):

You can of course monitor your download with the vSphere Client (web or otherwise), to make sure nothing has stopped

Once it´s done, it will look like this:

Reboot your host, and behold the glory of the new ESXi 5.1 Update 1 version!

If you want to know how to figure out how to find the correct URL and file, check out William Lam´s excellent A Pretty Cool Method of Upgrading to ESXi 5.1 post, which provides more details.

I told you it was quick and dirty, didn`t I?

Christian Mohn

This is a trivial task on it`s own, just create a vSwitch with no physical NICs attached to it, and then connect the VMs to it. The VMs will then have interconnectivity, but no outside network access at all.

In this particular case, I was setting up a couple of nested ESXi servers that I wanted to connect to the “outside” vCenter Appliance (VCSA). This VCSA instance was not connected to the internal-only vSwitch, but rather to the existing vSwitch that as local network access.

Naturally, the solution would be to add a secondary NIC to the VCSA, and connect that to the internal-only vSwitch.

It turns out that adding a secondary NIC to a VCSA instance, isn`t as straight-forward as you might think. Sure, adding a new NIC is no problem through either the vSphere Client, or the vSphere Web Client, but getting the NIC configured inside of VCSA is another matter.

If you add a secondary NIC, it will turn up in the VCSA management web page, but you will not be able to save the configuration since the required configuration files for eth1 is missing.

In order to rectify this, I performed the following steps:

1. Connect to the VCSA via SSH (default username and password is root/vmware)
2. Copy /etc/sysconfig/networking/devices/ifcfg-eth0 to /etc/sysconfig/networking/devices/ifcfg-eth1
3. Edit ifcfg-eth1 and replace the networking information with your values, here is how mine looks:
   DEVICE=eth1
   BOOTPROTO='static'
   STARTMODE='auto'
   TYPE=Ethernet
   USERCONTROL='no'
   IPADDR='172.16.1.52'
   NETMASK='255.255.255.0'
   BROADCAST='172.16.1.255'
4. Create a symlink for this file in /etc/sysconfig/network
   ln -s /etc/sysconfig/networking/devices/ifcfg-eth1 /etc/sysconfig/network/ifcfg-eth1
5. Restart the networking service to activate the new setup:
   service network restart

   Check the VCSA web management interface to verify that the new settings are active

By adding a secondary NIC, configuring it and connecting it to the isolated vSwitch I was now able to add my sequestered nested ESXi hosts to my existing VCSA installation.

There may be several reasons for a setup like this, perhaps you want your VCSA to be available on a management VLAN but reach ESXi hosts on another VLAN without having routing in place between the segmented networks, or you just want to play around with it like I am in this lab environment.

Disclaimer:

Is this supported by VMware? Probably not, but I simply don`t know. Caveat emptor, and all that jazz.

Christian Mohn

First of all, you need to download the MEM installation package. At the time of writing, the latest version is v1.1.2.292203, available from equallogic.com. One the archive file is aquired, unzip it and upload the dell-eql-mem-esx5-1.1.2.292203.zip file to a shared location available in your environment. For the example below, I have used a VMFS datastore that is available to all the hosts in this particular cluster.

Note: The host in question has already been put in maintenance mode, to make sure no VMs are actively using the storage paths while installing the module.

The VIB file, which resides inside the dell-eql-mem-esx5-1.1.2.292203.zip, file can be installed using several techniques; By using the vMA, vSphere Command-Line Interface (vSphere CLI), vSphere Update Manager or even by logging in to the hosts via a SSH connection, and in this case I opted for doing it through SSH.

The command required to install the MEM is as follows:

A completed installation looks like this:

I then restart the hosts process, to make sure that the multipath module is activated.

Finally, a quick check to see if the new Equallogic namespace is available, and that it is gathering statistics, i.e. being used:

Screenshots displaying the ESXi host path policy before:

and after installing the Dell Equallogic MEM:

Christian Mohn

As we all (should) know, that is very much a trick question.

Now, consider this little non-trick question:

I wonder what the avg disk size is for your virtual machine these days. I do most math with 60GB on avg, but wonder if that has changed

@DuncanYB / March 28th 2013

And now, guess what? Just 16 days later, a brand new data mining tool has emerged based on that initial question.

vOpenData is now live, in an attempt to answer these kinds of questions.

Simplistically put, this site gathers anonymous data from your virtual infrastructure and puts it into a global dataset ready for analysis and presentation.

As data is contributed from various sources, the public dashboard is updated.

Another great community driven resource is born, this time by Ben Thomas and William Lam.

Announcement posts:

• vOpenData – Crunching Everyone’s Data For Fun And Knowledge
• vOpenData: An Open Virtualization Community Database

Check it out and help out by contributing your data if you can.

Christian Mohn

Due to the very NDA nature of the beta programs, I can´t really go into details on what is currently offered, but what I can say is this: Well done VMware!

The VMware Hosted Beta runs on the same engine that runs the VMware Hands on Labs Online – Beta, but with a little added twist. You connect to the hosted beta through a web interface, before the actual connection is handed over to a locally installed VMware Horizon View client. This works very well, and I got to play around a bit with it a bit yesterday.

The idea of a hosted beta like this really resonates with me, as one of the major time sinks when it comes to actively participating in betas is the physical setup of a lab environment. As I am currently without a properly powerful lab, something that will change very soon I hope, getting hosted beta access could not be more welcome.

This way I get to dip my toes in the beta offerings, without having to procure the required hardware. While I don´t think the hosted beta replaces the need for a dedicated physical lab, it sure does work as an excellent stop-gap in the mean time. It also means that you can jump in and out of various pieces of the beta, without having to spend a lot of time configuring an environment from scratch. In addition, this also means that you can get a working environment set up in a matter of minutes, and all you need is love an internet connection.

Of course, VMware does not want everyone to run all their beta testing in this environment, they need feedback on installation and configuration issues in “real world” scenarios as well as plain old feature testing in a controlled environment, but this is a very welcome addition in my mind.

Kudos to the HoL and Beta teams at VMware, this makes my day so much easier and I am sure it will also help them in getting better feedback from us beta testers.

Christian Mohn

If you experience this problem, you will see entries like this in your Veeam B&R backup logs:

Veeam vCenterDB Backup Error

The workaround provided by Veeam is to create host VM-Host Affinity Rules, effectively pinning a VM to a given host, and then perform the VM backup through the host rather than through the vCenter.

While this might be a way to work around the failed backup scenario, it effectively limits some of the flexibility you have in a virtualized environment. I want to have my VMs roaming around my datacenter utilizing DRS, and by pinning the VM to a given host that flexibility is reduced for the VMs in question.

I can appreciate why this issue appears, and why the workaround works, but frankly there has to be a better way of doing this. Hopefully this issue will be sorted in the next v7 version of Veeam B&R, as there certainly are ways for Veeam to work around the issue and make this a more seamless experience for the backup administrator.

Proposal

Why not create a new option in the backup job, where you define that this particular job should run through a host, instead of the vCenter?

If selected, Veeam B&R would query the vCenter for which host the given VM resides on, then connect to the host itself and perform the backup through that?

That way we could work without having to set VM-host Affinity Rules, yet still keep vCenter out of the loop when the actual backup is performed.

Doing such a query is pretty easy,  below is an example using PowerCLI:

This simple query returns the host that the given VM resides on at the given time, why not do something like this inside of Veeam B&R to make sure that vCenter DB backups work, without having to resort to VM-Host Affinity Rules?

Christian Mohn

To complicate things in this particular environment, I also had to migrate the vCenter SQL DB from a local MS SQL Server 2005 Express instance to a full-fledged MS SQL Server 2008 R2 instance.

Of course, it was also decided to move the vCenter installation from a physical server, to a VM in the same operation.

To be able to have an exit path, until the vSphere 4.1 hosts management agents, were reconfigured, a new vCenter VM was created with a new IP-adress and server name.

After the migration from vCenter 4.1 to 5.1, and from physical to virtual was completed, the existing Veeam B&R server was upgraded to the latest 6.5 release.

Now, this is where things started to get a bit interesting with regards to the existing Veeam B&R backup jobs.  As far as it was concerned, the new vCenter was unknown and the old one was no longer anywhere to be found on the network.

If you add the new vCenter to the Veeam B&R server, you will need to either redefine all the existing backup jobs by adding the same VM from the new vCenter to the existing job, and keep the old one around until your retention period has passed (and have it fail on the existing VM object until it´s removed) or you will have to recreate all the jobs pointing to the new vCenter instance and start new “first time backups” for all the VMs.

For some reason you simply can not rename/redefine your vCenter connection inside of the Veeam B&R GUI.

Thankfully there is an easy way to work around this issue, without having to mess about with the Veeam B&R database: Create a DNS alias!

That´s right, the solution was that simple. I created a DNS CNAME  alias pointing the old vCenter network name to the new vCenter network name. After doing that, I had to re-enter the credentials for the vCenter connection in Veeam B&R to force a reconnect, and all of a sudden all existing backups jobs where present again and working as intended.

The reason this works, is that when you change the vCenter name and/or IP address (or even move it to a new server) it does not change the VM identification number (vmid) or Managed Object Reference (MoRef), in essence the VMs stay the same and Veeam B&R can continue managing them as before.

Now, can we please get an option to update the registered vCenter name in Veeam Backup & Replication v7.0?

Christian Mohn

Now, how sweet would it be to deploy Autolab without having to invest time, money and effort into acquiring your own hardware?

Well, thanks to baremetalcloud.com, you might now actually be able to do just that (and more, if you wish). Of course, this is a paid service but Mike Laverick has secured a deal where the 100 first sign-ups using his promo code gets free credits to play around with!

For more details, including promo code and setup information, check “Bare Metal Cloud for your Auto-Lab“

Christian Mohn

If you have some ideas, I´ll gladly create more, just leave a comment! I would also love photos if you printed out any of these and put them on a wall or in a frame somewhere. Or even better, on a T-Shirt!

Seen in the wild:

Christian Mohn