CrashLoopBackoff

Storage Design and VDI

Recently I have spent time re-thinking certain configuration scenarios and asking myself, “Why?” If there is something I do day to day during installs is this still true when it comes to vSphere? or will it still be true when it comes to future versions.
Lately I have questioned how I deploy LUNs/volumes/datastores. I usually deploy multiple moderate size datastores. In my opinion this was always the best way to fit in MOST situations. I also will create datastores based on need afterward. So will create some general use datastores then add a bigger or smaller store based on performance/storage needs. After all the research I have done and asking questions on twitter* I still think this is a good plan in most situations.
I went over a VMworld.com session TA3220 – VMware vStorage VMFS-3 Architectural Advances since ESX 3.0 and read this paper:
http://www.vmware.com/resources/techresources/1059
I also went over some blog posts at Yellow-Bricks.com and Virtualgeek.

An idea occurred to me when it comes to using extents in VMFS, SCSI Reservations/Locks, and VDI “Boot Storms”. First some things a picked up.
1. Extents are not “spill and fill” VMFS places VM files across all the LUNs. Not quite what I would call load balancing, since it does not take IO load into account when placing files. So in situations where all the VM’s have similar loads this won’t be a problem.
2. Only the first LUN in a VMFS span gets locked by “storage and VMFS Administrative tasks” (Scalable Storage Performance pg 9). Not sure if this implies all locks.

Booting 100’s of VM’s for VMware View will cause locking and even though vSphere is much better when it comes to how quickly this process takes. There is still an impact. So I am beginning to think of a disk layout to ease administration for VDI, and possibly lay the groundwork for improved performance. Here is my theory:

Create four LUNs with 200GB each. Use VMFS to extents to group them together. Resulting in an 800 GB datastore with 4 disk queues and only 1 LUN that locks during administrative tasks.

Give this datastore to VMware View and let it have at it. Since the IO load for each VM is mostly the same, and really at the highest during boot other tasks performed on the LUN after the initial boot storm will have even less impact. So we can let desktops get destroyed and rebuilt/cloned all day with only locking that first LUN. This part I still need to confirm in the LAB.

What I have seen in the lab is with same sized clones the data on disk was spread pretty evenly across the LUNs.

Any other ideas? Please leave a comment. Maybe I am way off base.

*(thanks to @lamw @jasonboche and @sakacc for discussing or answering my tweets)

ESX Commands – Summary

It took just about a year. Which shows I need more consistency with my blog (should have been about 1 month). I finally finished a brief explanation of each esxcfg command. My little self study for the VCDX, this is in no way exhaustive.

Make sure to check out other great resources out there:
Simon Long
Harley Stagner
Both good places to start.

Hopefully my VCDX compilation page can help.

ESX Commands: esxcfg-vswif

The esxcfg-vswif command allows you to create and modify Service Console ports and their IP information. Many times I have to change stuff after the install process is complete and the only place is via the direct service console because network communication is not possible. This usually happens when the network team changes a vlan in the middle of the install or they change a subnet. Not to disparage network teams many times I am the network team and the virtualization team.
Create a new vswif:
#first add a port group with esxcfg-vswitch esxcfg-vswitch -A "Service Console Test" vSwitch-Test #then use esxcfg-vswif to create a new vswif esxcfg-vswif -a -i 172.16.50.40 -n 255.255.255.0 -p "Service Console Test" vswif1 #List your vswifs esxcfg-vswif - l #Example: [root@esx3 root]# esxcfg-vswif -l Name Port Group IP Address Netmask Broadcast Enabled DHCP vswif0 Service Console 172.16.50.50 255.255.255.0 172.16.50.255 true false vswif1 Service Console Test172.16.50.40 255.255.255.0 172.16.50.255 true false

Modify your Service Console network information:
esxcfg-vswif -i 172.16.50.41 -n 255.255.255.0 vswif1 #example [root@esx3 root]# esxcfg-vswif -i 172.16.50.41 -n 255.255.255.0 vswif1 Setting IP config Nothing to flush. [root@esx3 root]# esxcfg-vswif -l Name Port Group IP Address Netmask Broadcast Enabled DHCP vswif0 Service Console 172.16.50.50 255.255.255.0 172.16.50.255 true false vswif1 Service Console Test172.16.50.41 255.255.255.0 172.16.50.255 true false

ESX Commands: esxcfg-vmknic

You need to have VMkernel ports to do VMotion, Software iSCSI and Fault Tolerance. These ports can be easy to create and manage from the command line. I generally can be found adding them for vSphere iSCSI. I especially use the cli for tasks that are repeated over and over. Creating multiple ports per ESX host is time consuming and tends to introduce typing errors. So it is always a good idea to get them all done in a script file to reduce the chance for error.

List out all the VMkernel Nics:
esxcfg-vmknic -l

Create a new portgroup first with esxcfg-vswitch then create a vmk port with esxcfg-vmknic, example:
esxcfg-vswitch -a VMkport vSwitch1 esxcfg-vmknic -a -i -n VMkport

In VI3 you can only have one Vmkernel port per vswitch, in vSphere this is changed. It is especially usefully setting up iSCSI multipathing. As the software iSCSI initiator will initiate IO from each iSCSI enabled vmkernel port when using Round Robin as your path selection policy.

VMware View – Repurpose your Existing PC’s as Thin Clients

I was looking for last couple weeks for a good way to re-purpose PC’s as thin clients to ease the investment in VDI. I stumbled across this PDF from VMware and I thought it was great. I would tend towards using group policy to deploy the new shell described on pages 3 and 4. It can always be undone if the PC is needed as a PC again.

Check it out.

You pretty much replace the default shell (explorer.exe) with the VMware View Client. I would suggest using some group policy to keep people from using the task manager to start new processes. This should be a temporary solution until you have budget to buy some real thin clients or net books even.

There are of course lots of options out there for thin clients, and software to provision a “thin OS” to machines. This is free and easy though. I thought it was cool so I decided to share.

Get iSCSI iqn from the ESX Command Line

I was in my personal ESX about to upgrade to update 1. I was distracted by trying to setup iSCSI from the command line. Right before I looked to the vSphere Client to get the iqn I said, “There is surely a way for me to find this from the command line.”

Searching around I found the command vmkiscsi-tool. Really good stuff, I can complete the rest of my setup without the GUI. One thing though to list out the iqn for iscsi after you enable it you must know the device name (ie vmhba??).

Using this command:
vmkiscsi-tool -I -l

I usually guess the iscsi hba is vmhba33 or 32 but how do I know for sure?
Try:
esxcfg-scsidevs -a

Ok great, now we know it is vmhba33
[root@esxhost01 sbin]# vmkiscsi-tool -I -l vmhba33 iSCSI Node Name: iqn.1998-01.com.vmware:esxhost01-35151883 [root@esxhost01 sbin]#

Now with a few more vmkiscsi-tool commands I can finish configuring my iSCSI.
Add the Ip of the SAN:
[root@esxhost01 sbin]# vmkiscsi-tool -D -a 172.16.23.251 vmhba33
Now rescan:
[root@esxhost01 sbin]# esxcfg-rescan -a vmhba33

ESX Commands: esxcfg-vswitch

This is a command I use the most often. It is big when I configure Equalogic and MPIO in vSphere. Additionally, many times I show up on site and the network is not configured prior to my arrival. Even if I sent all the configs ahead of time. People like to wait until the last minute. When building the ESX environment then I may build it with the Service Console in the default vlan or in which ever one it is plugged into in the physical network. So oftern the network guy catches up and sets the dot1q trunk and I lose connectivity and I have to go to the console and set the vlans correctly. Like this:
esxcfg-vswitch -v 8 -p "Service Console" vSwitch0
Speaking of iSCSI you will also set your jumbo frames on the vSwitch from this command
esxcfg-vswitch -m 9000 vSwitch1

Of course there is a ton more you can do from this command. Here is some man page action for you:
esxcfg-vswitch(8) VMware ESX Manual esxcfg-vswitch(8)


NAME

     esxcfg-vswitch - VMware ESX Virtual Switch Configuration tool
SYNOPSIS

     esxcfg-vswitch OPTIONS [VSWITCH]
DESCRIPTION

     esxcfg-vswitch provides an interface for adding, removing, and modifying virtual switches and their settings.  By default,

     there is a single virtual switch called vSwitch0.
OPTIONS

     -a --add

             Add a new virtual switch to the system.  It requires a virtual switch name to be provided.
     -d --delete

             Delete a virtual switch.  This will fail if any ports on the virtual switch are still in use by VMkernel networks,

             vswifs, or VMs.
     -l --list

             List all virtual switches and their portgroups.
     -L --link

             Add an uplink to a virtual switch.  This will attach a new unused physical NIC to a virtual switch.
     -U --unlink

             Remove an uplink from a virtual switch.  This will remove a NIC from the uplink list of a virtual switch. If it is

             the last uplink, physical network connectivity for that switch will be lost.
     -R --restore-uplinks

             Restore uplinks for all virtual switches from config file. This will restore all uplinks for each virtual switch from

             configurtion file. INTERNAL USE ONLY.
     -M --add-pg-uplink

             Add an uplink to the list of uplinks for a portgroup
     -N --del-pg-uplink

             Delete an uplink from the list of uplinks for a portgroup
     -P --add-dvp-uplink

             Add an uplink to a DVPort on a DVSwitch. Must specify --dvp in the same commnad.
     -Q --del-dvp-uplink

             Delete an uplink from a  DVPort on a DVSwitch. Must specify --dvp in the same commnad.
     -p --pg

             Provide the name of the portgroup. For the â--vlanâ option,  "ALL" can be specified to operate on all portgroups of a

             virtual switch.
     -V --dvp

             Provide the DVPort ID of a DVSwitch.

 -v --vlan

             Set the VLAN ID for a specific portgroup of a virtuals switch Using the option "0" will disable VLAN for this port-

             group.  Requires that the --pg option is also specified.
     -c --check

             Check to see if a virtual switch exists. The program prints a "1" if it exists; otherwise it prints "0".
     -A --add-pg

             Add a new portgroup to a virtual switch with the given name.
     -D --del-pg

             Delete a portgroup.  This operation will fail if the portgroup is in use.
     -C --check-pg

             Check whether the specified name is in use for a portgroup.  Prints "1" if the name is in use, prints "0" otherwise.
     -B --set-cdp

             Set the CDP status for a given virtual switch.  To set pass one of "down", "listen", "advertise", "both".
     -b --get-cdp

             Print the current CDP setting for this switch.
     -X --set-maxactive

             Set the max active uplinks for the virtual switch.
     -x --get-maxactive

             Get the max active uplinks for the virtual switch.
     -m --mtu

             Set the MTU for the vswitch.  This affects all the NICs attached to the vswitch.
     -r --restore

             Used at system startup to restore configuration.  INTERNAL USE ONLY.
     -h --help

             Print a simple help message.
EXAMPLES

     Add a Virtual Switch:
     esxcfg-vswitch --add vSwitch1
     Add a Portgroup to vSwitch0:
     esxcfg-vswitch --add-pg="New Portgroup" vSwitch0
COPYRIGHT

     VMware ESX is Copyright 1998-2009 VMware, Inc.  All rights reserved.

VMware ESX 4.0 November 22, 2009 VMware ESX 4.0

ESX Commands: esxcfg-pciid,rescan,resgrp,swiscsi,upgrade, vmhbadevs

I have been writing on ESX command line stuff for far too long now. I just need to finish it before ESX 5 comes out with no command line support and my year long series is rendered obsolete before it is finished.

Here is a few more commands from ESX 3.5u4. They are pretty short and sweet. So enjoy.
esxcfg-pciid
Used to read the xml files under /etc/vmware/pciid/ – from what I can tell it is used in the process of getting unsupported hardware to work.

esxcfg-rescan
Supply this command with a vm hba and it will rescan for new LUNs.

esxcfg-resgrp
Do a esxcfg-resgrp -l and get a ton of information try following it with a “| more”: esxcfg-resgrp -l | more
It does include options to add remove and restore resource groups. Here is a place on the interwebs with information on how to use it.

esxcfg-swiscsi
Used to enable and disable the Software iSCSI Initiator. esxcfg-swiscsi -q will give you the list of the status.
Make sure to create a vmkernel port first.

esxcfg-upgrade
According to the ESX Configuration Guide this command is not for general use but is used to upgrade VMFS2 to VMFS3. Would be very smart to have moved all VM’s off of the VMFS2 before messing with this command.

esxcfg-vmhbadevs
Use the -m tag to list all vmfs volumes. Typical output will look like this:
vmhba0:0:0:3 /dev/sda3 4afc26df-ddbe3ee5-2037-000c29acbc0a

Upgrade to vSphere already

OK, SRM and View 4 are out. Go ahead and start planning those upgrades from 3.x to 4. I mean really, vSphere is out now for almost 6 months. Get Enterprise Plus or the Acceleration kit, just get to vSphere. Here are a few of my reason’s why.

1. Round Robin Storage IO. Those without can giant Fiber Channel SAN infrastructure can start to stack the Software iSCSI ports and get performance above and beyond what was possible before with iSCSI. Equalogic, Lefthand and other iSCSI SAN manufacturers have to be throwing huge parties about this. While talking about iSCSI you don’t need a Service Console just for every iSCSI VMkernel port. This always seemed like extra setup in 3.x.

2 Thin Provisioning, I am not technical enough with storage to know if SAN based thin provisioning is better for some reason. It is great to be able to save space with template and other large footprint VM’s.

3. dVSwitch, VMsafe and vShield zones. New hooks for security will eventually give us insight into areas of the VI we could not see before. VMsafe will let vendors tie into the kernel (at least that is how I understand it). Additionally the new dVSwitch (Distributed Virtual Switch, sometimes it is called something else) will give control and sight into the network stack in ways that was impossible before.

This is stuff many may have read on the release date in May, but now that I have seen vSphere in action and some of the biggest hurdles (SRM and View) have been overcome, it is now time to upgrade, already.

ESX Commands esxcfg-nics

I have been missing for a couple weeks again, which means we have been busy doing VMware installs and that is a good thing. Next command in the order is esxcfg-nics. From the command line you can get some good information about the physical nics on your host. Additionally for troubleshooting purposes or configuration you can hard set physical nic speed and duplex.