vCD Log Files

Here is a list of inportant log files in vCD and a brief description. The can be found at /opt/vmware/cloud-director/logs

• yyyy-mm-dd.request.log - This shows all the HTTP requests that have come from the user interface or the API. Very useful to run tail -f on this file to see where connections for users are going to.
• cell.log - shows information for when the vCD cell is starting up. You can use tail -f on this file to watch the vCD cell start up, you will see the % progress. The cell can be started using command service vmware-vcd start, and stopped using command service vmware-vcd stop.
• vcloud-container-debug.log - Debug level messages
• vcloud-container-info.log - Information, warning and error messages for this vCD cell
• vmware-vcd-watchdog.log - Brief message showing the last time the cell was started
• diagnostics.log - Empty unless diagnostics logging is enabled in the local logging configuration

Unable to create routed organisation network

I've just had an issue at a customer when they were unable to create any Routed Organization Networks.

Direct and Internal only networks were created fine.

The error that was shown in vCD referred to vShield Manager, and error 401, unauthorized.

I'm unsure what caused the issue, although there were issues with the environment as the ESX boot LUNs had been disconnected.

It appeared that the credentials for vCD to authenticate to the vShield Manager have in someway been corrupted.

So, I connected to vCD, selected the properties of the the vCenter server from the Manage & monitor tab, and re-entered the administrator credentails for vShield Manager.

Importing Virtual Machines into vCloud Director

So now that we have a nice new vCloud Director implementation, we need to think about how we are going to get our customers Virtual Machines imported, and placed in the appropriate vApp.

I'm going to assume you already have a process to import Virtual Machine(s) into vCenter. If your doing P2V, probably VMware Converter or something similar, if you are importing a Virtual Machine, then something more straight forward.

For a successful import into vCloud Director, the vCenter that you are importing your Virtual Machine(s) into will need to be attached to vCloud Director.




When you have got your VMs into vCenter, you will need to import them as vApps into vCD. Bear in mind that each VM will be imported into its own vApp, so you will have lots of single Virtual Machine vApps.

In vCloud Director, open up the Organisation that the VMs will be imported into, and select My Cloud -> vApps. Click the Import from vSphere... button

You will then be shown the Virtual Machines in the selected vCenter Server that can be imported. You need to select the required Virtual Machine, name the vApp, and select the Organisation vDC that you want to place it in.

Finally, before hitting OK, you will need to select Move VM or Copy VM... depending on whether you want the VM to remain in vCenter or not.

When all the VMs have been imported, you can group them into a single vApp if you want. Simply open the vApp in question, right click the VM (when its not running), and select Move ... You can then specify the destination vApp for this Virtual Machine. The source vApp will now be empty, and can be deleted. Repeat this for as many VMs that you want within the destination vApp.

The final thing you need to do is configure the networking for the newly added VMs in the vApp. I'm going to assume that the vApp has the appropriate networks added to it, so it is just a case of opening the vApp up, editing the Virtual Machines that have been imported, and allocating the correct vApp network to its NICs.

ESXi Rollback

So if you patch an ESXi host, and then realise that actually you want to roll back to the pre patch version, this is possible.

As ESXi is basically just firmware, each time you patch it, the whole thing is replaced. Fortunately, before patching, a backup of the current version is taken and stored. So to roll back to the previous version, just press ctrl r when you see the loading hypervisor screen.

Changing Virtual Machine Folder Name

If you need to rename a VM, this is simple as you can simply right click it in the vSphere client and select rename.

The only problem with this is that it doesn't change the folder name on the datastore, so you may end up with a virtual machine called test VM - old, but the folder its files are in is called test VM.

So how to solve this?

Simply Migrate the storage of the Virtual Machine to a different datastore, and the Virtual Machine folder on the new datastore will be created with the new Virtual Machines name.

Job done!

Lab Manager 4 Networking

I thought I'd state the bleedin obvious that I didn't get until I had to install Lab Manager 4 and then scratch my head for a day.

When you use Cross Host Fencing, you need to think about the external networking. The network packets between VMs that are residing on different networks don't jump magically get transported without using the physical network - told you it was obvious!!

The way that Cross Host Fencing works is that a Host Spanning Transport Network needs to exist where the traffic will flow across. Each ESX host in the cluster will have a single VM created (don't touch it) named something like

nnnnnn-VMware-ServiceVM-Ixx-YY

where nnnnnn is a number (e.g. 000001), xx is the Lab Manager Installation ID and YY is some letter number combination that is the same for each VM.

As I said, never ever touch these machines. If you are having problems with Cross Host Fencing, you can recreate these machines by disabling the individual hosts from Host Spanning, and then re-enabling it. this removes these VMs and creates new ones, but will obviously break any configurations that are using Cross Host Fencing.

These machines are connected to the VLAN that you have configured as your Host Spanning Transport Network on a Port Group that is created on the dvSwitch that you specified when configuring the Host Spanning Transport Network. The Port Group is named:

dvSwitchx-LMService-yLMxx

where y is a number and xx is the Lab manager Installation ID.

HP Flex-10, Virtual Connect & vSphere

So there are restrictions to how you can implement this configuration. There are some really good blogs that describe it, such as

http://kennethvanditmarsch.wordpress.com/2009/11/04/understanding-hp-flex-10-mappings-with-vmware/

http://frankdenneman.wordpress.com/2009/04/26/flex-10-lessons-learned/

so I won't repeat what has been said before.

However, the restriction where you are unable to present the same VLAN to more than one FlexNIC on the LOM can be got around if you present the VLAN as a native VLAN (i.e. 0) to one FlexNIC, and apply the VLAN tag to the other FlexNIC.

This is really helpful when you have a virtual vCenter as if this wasn't possible, you would have to put it on a different VLAN to the ESX(i) hosts. However, I have configured it so that vSwitch0 on the hosts is presented with the native VLAN, and the vSwitch (or dvSwitch) that vCenter is attached to is presented with the tagged VLAN.

UPDATE: Whilst this configuration works during normal operation. In the event of loss of Virtual Connect module, or uplinks, all management networking will be lost. This is because the LOM to uplink mapping is hard coded, and whilst you can configure the mapping differently, it will break. Therefore always remember the 1 LOM to on uplink rule.