December, 2009 | 2vcps and a Truck

December 30, 2009

Recap of 2009

Thank you to everyone out there that gave any attention to this little blog. I tried to supply new information where I could and also document my journey trying to improve at the esxcfg- commands. In 2009 the traffic increased from less than 100 visits in a week to approaching 500 in a week. That is a slow hour for some of the best vm bloggers (Yellow-Bricks, Scott Lowe) but I am not trying to replace them.

In March I was layed off. I spent 2 months full time looking for work. The VMware community really stepped up. Special thanks go out to a few people that tried to help out or checked in with how the search was going: @jasemccarty @maishk @jasonboche and many others. By the end of April I started a new position as a Virtualization Infrastructure Engineer at Veristor Systems. This job required moving the family from Memphis, Tennessee to Atlanta, Georgia. All the fun of a new job, house hunting and moving to a completely new city. We closed on our new house just a few days after VMworld 2009. My first trip to VMworld was amazing but I would suggest not buying a house while you are in and out of conferences, labs and seminars. Lots of details to fix, I will be happy if this is not the case ever again.

After such a busy year it was only the beginning of September. The rest of the year was filled with VMware Installation projects and VMware health checks. I was all over the Southeast US. Maybe I can come visit some of you in 2010?

Technical/VM/Blogging Goals for 2010:

Continually improve the quality of content going to this blog.
Schedule, take and pass the VCDX exams.
Improve my overall storage knowledge.
Renew my expired CCNA (bad move letting this lapse in 2009)

2009 was such a big year personally. I hope and pray for a little more stability in 2010 but I also love the excitement of new challenges, but the VCDX should be enough. 🙂

Also, I scheduled a Merry Christmas post, but for some reason I didn’t do what I thought I did. So a late Merry Christmas to all of you out there.

December 23, 2009

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)

December 22, 2009

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.

December 21, 2009

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: [[email protected] 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 [[email protected] root]# esxcfg-vswif -i 172.16.50.41 -n 255.255.255.0 vswif1 Setting IP config Nothing to flush. [[email protected] 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

December 20, 2009

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.

December 17, 2009

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.