I'm James Burd and you've just been made virtually wiser

I've been working on setting up a POC for XenDesktop 5.6 and provisioning machines with MCS (machine creation service). I ran into a problem where the machines I provisioned were trying to PXE boot, as if they were configured to reach my Citrix PVS server. Here is the setup: I have a Win7x64 template in VMware, I have multiple DDC's going through an F5 load balancer. I have both PVS and MCS in the same environment. There is a rule in MCS that the C drive for the template must be on "hard disk 1" within VMware in order for MCS to provision machines correctly. I did have this setup correctly.

Here is the problem I found. My template was using the new "EFI" bios instead of the traditional BIOS. EFI is the next generation BIOS in vSphere 5 for version 8 virtual machines. Since the hard drive device ID is handled differently in EFI vs BIOS, MCS in citrix did not know what device was the C drive upon boot, causing the next device in line (the NIC) to PXE boot. After I built another template with the traditional BIOS (still on version 8 hardware), MCS was able to correctly provision machines.

For an overview of the vSphere 5 EFI (extendable firmware interface) bios, check out this YouTube video.

Recently I ran into an issue creating some new storage clusters on two different vCenter servers. I had a problem where I was selecting the host cluster to create a storage cluster within, but the next button was greyed out.

I went through my own troubleshooting steps. 1. Did there have to be more than one datastore in order to create a cluster? No, because you can create a cluster with even local storage (on the same host) with one disk. 2. Are both the datastores the same? Yes, both on fiber (you cannot create a cluster with mixed datastore types (NFS / VMFS). 3. Are datastores stored between different sites? – No, both are in the same datacenter. 4. Do I have any replicated datastores? – No, not for this cluster. 5. Are all the hosts in the cluster esxi 5? Yes, all hosts are supported.

I also started to wonder… Do they need to be unformatted in order to do the initial setup for a storage cluster? No. Do they need to be at a certain VMFS level to join the cluster? Yes, Version 5.x or above. Are the datastores currently part of any other storage cluster? No. 

After beating my head against it for a while it turns out you have to select the top level datacenter and then unselect all of the unwanted clusters to join the storage group. I had this happen on two different vCenters with build 455964. I then went to another environment with the same build and did not have this issue.

For more info on the general practice of creating a datastore cluster, visit myvirtualcloud.net.

Ever get this error when you try to migrate a standard switch vmkernel port to a DvS?

"Call "HostNetworkSystem.UpdateNetworkConfig" for object "networkSystem-64" on vCenter Server "vCenter.company.com" failed."

It is most likly because the SvS is being used by something. In my case, it was the "Core Dump" feature utilizing the SvS. From the command line, run this to check the configuration: "esxcli system coredump network get". If you get a configuration that is "true", you will need to disable this for now. To issue the disable command: "esxcli system coredump network set –enable false". Check the config again by typing: "esxcli system coredump network get". you should now see the status as "false". Now migrate your interface to the DvS. Once it has been moved, re-enable Core Dump by typing "esxcli system coredump network set –interface-name vmk0 –server-ipv4 10.x.x.x –server-port 6500". Of course the 10.x.x.x should be the vcenter ip and check to make sure what port you are using from your original get command. After this, issue the "esxcli system coredump network get" command one more time to make sure the configuration matches from the previous configuration on the SvS.

There are many topics on boot from SAN and auto deploy. For us, boot from SAN made more since because we have an exisiting fiber network in place. We do not however have all of the components needed for auto deploy (DHCP, TFPT, ect). In this boot from SAN environment, I am working with a few Dell M1000e chassis, M710HD / M610 blades,  dual QLogic QME 2572 cards, dual intel 10GB cards,  Cisco 3130XS, Broacde fiber switches and an EMC SAN.

I am not going to cover provisioning a LUN or zoning because they can be different on whatever vendor you use.

The first thing you want to do is decide on is a flex address. Will you want the boot LUN to follow the blade or stay assigned to the WWN of the chassis slot? We liked the idea of being able to plug in a spare or replacement blade into the slot in order to bring systems back online quickly.

Reboot the server and hit "ctrl-q" to enter the qlogic Fast!Util.

This will give you a selection of the adpater addresses.

In the menu for the adapter, be sure to enable "host adapter BIOS". This is disabled by default.

If you have provisioned and zoned your luns already, you will see the selecable boot luns. Be sure to set the correct order for these. Typically you would have these go across storage processor A or B. Be sure to create an even load in your environment in case all the hosts reboot.

The next task is to configure the BIOS.

In the "hard disk drive sequence", set the daughter card as the first boot device.

Make sure to set the correct boot order.

When the system reboots, you should see the LUN you are booting to.

When you go to install the host, you will see the option to install on LUN you have provisioned. If you see an incorrect volume size here, go back to your QLogic configuration and make sure you have selected the correct LUN to boot from.

I recommend to only provision the LUN needed for the install when going through the initial setup.

Why are companies still using boot from SAN? What's the difference from Auto Deply?

1. You can replace the SAN to a DR sit and have hosts on standby. This can be achieved also with auto deploy, if you replicate all components to the DR site.

2. The SAN can take snapshots of the LUN, which enables a roll back in case something happens to the host install. Auto Deploy is a stateless boot option, you have to use image builder and rely on host profiles to keep everything synced. You would still want to use host profiles even with boot from SAN.

3. Servers can be diskless with boot from SAN. This is the same for Auto Deploy, the hypervisor is actually loaded into RAM.

4. A master image can be used with boot from SAN by cloning the lun for other hosts. There are still steps involved to zone the LUN properly. Auto Deploy is similar, you still need to assign the MAC to the image you want to boot from.

This is not really a comparison between boot from SAN and auto deploy, I just wanted to show the steps for setting up boot from SAN from Dell.

So I'm messing around in my lab and testing all of my plug-ins in advance of my vSphere 5 production upgrade. One of the components I need to test is my XenDesktop environment against vSphere 5. In the past you had three options, disable security by removing the https redirects, enable security by using a corporate CA or a commercial signed certificate. Disabling security has always been a no-no, but was accomplished by modifying the "proxy.xml" file in vCenter. In VMware vSphere 5 the "proxy.xml" is still under the C:\ProgramData\VMware folder. No one should break security just to make life easier. According to CTX119849, you must use HTTPS in order for the DDC to communicate with vCenter. The default certificate from vCenter will not work either!