Those aren't pillows!...they're clouds

Cloud-builder & whiteboard junkie

[fgshepherd]

Time Configuration in vCloud Director

Re-posting our NTP configuration documentation from my own Community thread VMware.com...hoping it might be useful for a broader audience:

<<------------------------------------------------------------------->>

#Just for those working on configuring RHEL time on their cells, here's a distilled version of what we're doing, so hopefully, it will provide some guidance:

  #Configuration of TIME

  #Edit the ntp.conf file

  #Put the following line at the very top of the ntpd.conf file:

  tinker panic 0

  Note: The directive tinker panic 0 must be at the top of the ntp.conf file.  The configuration directive tinker panic 0 instructs NTP not to give up if it sees a large jump in time. This is important for coping with large time drifts and also resuming virtual machines from their suspended state.

#Comment out the 3 lines pointing to the "pool" servers and add the following:

  server us.pool.ntp.org

  #Update the ntpd.conf file to update NTP every 30 minutes:

  echo '30 * * * * root /usr/sbin/ntpd -q -u ntp:ntp' > /etc/cron.d/ntpd

  #Ensure ntp is set to start with the system

  chkconfig ntpd on

  #Note: VMware recommends you to use NTP instead of VMware Tools periodic time synchronization. NTP is an industry standard and ensures accurate timekeeping in your guest. You may have to open the firewall (UDP 123) to allow NTP traffic. #Using RHEL as the OS for the Cells, update the following:

  #Edit /etc/ntp/step-tickers: us.pool.ntp.org #After making changes to NTP configuration, the NTP daemon must be restarted. Refer to your operating system vendor’s documentation.

  service ntpd restart

  #Update ntp with the following command

  ntpdate –u 0.north-america.pool.ntp.org

  <<------------------------------------------------------------------->>

#It is also important not to use the local clock as a time source, often referred to as the Undisciplined Local Clock. NTP has a tendency to fall back to this in preference to the remote servers when there is a large amount of time drift. #An example of such a configuration is: server 127.127.1.0 fudge 127.127.1.0 stratum 10 Comment out both lines.

<<------------------------------------------------------------------->>

Modified with content lifted directly from: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427

[fgshepherd]

vExpert 2013

After several incredible years of working with VMware's vSphere suite and vCloud Director, I am honored to receive the vExpert designation for 2013.  I happen to know a few of the vExperts from previous years and it's humbling to be named with them this year.  The VMware community drives a significant amount of the work I do (or rather, it helps get me un-stuck on a regular basis), and it will be a personal goal this coming year to provide as much input and feedback for other users as I've been fortunate to receive.

So, congrats to my fellow honorees, and a thank you to VMware and the generous vendor community which is graciously handing out the swag to us all.

[fgshepherd]

vCloud Director Installation and The Worst Installation Feature Ever

THE WORST INSTALLATION FEATURE EVER -- if you plan on using multi-site SSO, the first site has to be configured to be "The first site in a multi-site configuration-- NOT as "BASIC MODE" (which is the DEFAULT)-- and to go back and fix it, all vSphere features have to be uninstalled at the primary site first.

You can do better than this, VMware.  You have to.

[fgshepherd]

VUM after 5.0 Update 2 is not working

Posting our own thread on the VMware Communities from earlier today to provide further search-ability to this topic, in the hopes that it spares someone else a few hours of trying to figure this out.

The Problem:

We just updated vCenter from 5.0 to 5.0 Update 2.  Smooth.

I uninstalled VUM (running on a different server) and reinstalled it.  Now, when I launch a client, I get a message saying "There was an error connecting to VMware vSphere Update Manager - [FQDN of vCenter:443].  Database temporarily unavailable or has network problems."

There's a release note here that says that the plug-in might not work after the update, and to check that you're using SQL Authentication for the ODBC connection from VUM to SQL.  So, we fixed that and now the ODBC connection is working just fine.

I restarted the SQL server, all VirtualCenter services, and the Update Manager service/servers.  No luck.

I've uninstalled the client and client plugin for VUM multiple times.  No luck.

I've run the client and the VUM plugin from both vCenter and from the VUM server.  No luck.

There is no firewall running on either server.

Both servers are in the same subnet.

What's confusing is that it gives the FQDN of the VirtualCenter server, as if that's what it's trying to connect to.  i.e. It thinks that VUM is installed on our VirtualCenter server.

The Solution:

On the VUM server: We ran "C:\Program Files (x86)\VMware\Infrastructure\Update Manager\VMwareUpdateManagerUtility.exe" (as Administrator, btw)

***Note: To log in to the Utility, we had to use a username@domain format for our service account, rather than our typical domain\username format.

(Skipped the Proxy settings)

Under Database Settings, we put in our New, LOCAL SQL-authenticated username and password and it accepted it.

Under Re-register to vCenter Server, we used the DNS name of our VirtualCenter and our username@domain service username and password and it accepted those, as well.

We restarted the VUM service on the VUM server and everything worked as expected.

[fgshepherd]

Multiple Boot LUNs in a Single Storage Group - EMC/UCS/vSphere

EMC's non-VMAX arrays don't allow servers to be members of multiple storage groups.  As a result, there is an challenge in using a single array for multiple boot-from-SAN servers that share storage, since every server must have its own storage group with a unique "LUN Zero" to boot from.  As new shared LUNs are presented, they must be presented to every server's storage group that needs to see the LUN.  (LUNs can be members of multiple storage groups, unlike hosts.)

We recently discovered an alternative that resolves the operational overhead on the array by allowing all servers to have their boot LUNs in a single storage group, along with the shared LUNs.  (The operational overhead is not eliminated completely, and the merits of where the overhead is handled can be argued back and forth for quite a while, as we discovered.)

Important: Watch what you're doing.

This approach is specific to Cisco's UCS platform, because they make it relatively easy to centralize the configuration steps.

Our approach assumes that you'd still install ESXi in a "traditional" 1:1::Host:Boot LUN (ID 0) setup, to minimize the chance of over-writing a shared LUN with production data on it.

After the ESXi has been installed to a host's LUN 0, remove both the host and the LUN from the installation storage group.

Add the Boot LUN into the Shared storage group and assign it a non-Zero Host ID.

In UCS, modify the Service Profile's Boot Policy (Boot Order tab) (it may be necessary to detach the Service Profile from whatever template it was created from).  In our test cases, we simply created a new Boot Policy that mirrored our original PXE-booting installation Boot Profile.  However, in the new Boot Policy, we specify an explicit non-zero "Lun ID", which corresponds to the "Host ID" under which the boot LUN will be presented when it's placed in the shared storage group.

(I would also recommend removing any LAN/PXE-boot sections of the profile, so that the installer doesn't fire up if the boot LUN is unreachable for some reason.)

Now, the Service Profile is set to look for the correct Host ID.  When it boots up, you'll see the Service Profile looking on the array for the correct Host ID...

...and it will boot using the appropriate ESXi installation.

As I mentioned before, it's not as if this completely removes all operational pain, but it does mean that we can add shared LUNs in one place, right along with these individual boot LUNs without having to make sure that they are added to every storage group when the servers and their boot LUNs are split apart into individual storage groups.

[fgshepherd]

We're not even close to 1000..!

[fgshepherd]

NC Local Food

After months of watching every food documentary we can get our hands on (Joel Salatin is The Man), talking with friends, joining a CSA, shopping at the farmers' market, etc., I was happy to hear about this yesterday on the radio, and even more proud when I saw that it is linked to NC State.

http://ow.ly/cu0GM

[fgshepherd]

My eggs are so bright... (Taken with Instagram)

[fgshepherd]

Great week at #emcworld in Las Vegas. Learned tons about EMC's FAST Suite and a couple of other uses for flash... In my mind, one of flash's primary uses is to compensate non-optimized LUN/workload layouts that occur during rapid growth.

[fgshepherd]

On my way to #emcworld 2012! Looking forward to lots of VNX & Cloud nuggets.

[fgshepherd]

Great week!...wrapped up my 3rd cert in 4 months: #EMC #Cloud Infrastructure and Services, #Cisco #UCS Support Specialist, #VMware #VCP5.

[fgshepherd]

Adding Disk Space to vCenter Operations

I'm recalling that it was tricky to find documentation on this, so for those people who are running out of space on vCenter Operations Manager's Analytics VM, it's pretty easy (though not intuitive) to add more space:

Shut it down the entire vCenter Operations Manager vApp

Add a new (as in separate, additional) VMDK to the Analytics VM

Boot the vApp back up

The Alanytics VM will discover the new disk and append it to its current working volume.  If you extend the existing VMDK, there is no way inside the Analytics VM to extend the volume manually (prove me wrong, VMware!), so you'll just strand that extra disk.

Now, if we can just figure out why this thing is chewing up 100 GB a month...

[fgshepherd]

...Thankful for an incredible day with our son, Noah.  After starting out slightly tentative about a child-carrier backpack, he seemed to warm up to it just a bit: First Hike (by fgshepherd)

[fgshepherd]

"Host cannot download files from vmware update manager patch store"

We recently stumbled across this error while patching some new ESXi 5 servers.  Networking, firewalls, services, databases, file systems...all checked out OK.  The only error I could see in our log files referred to a failure to connect to a "CSCO" directory in our patch repository.  That led me to following VMware KB ( http://bit.ly/IE4lCq ), which completely fixed the problem.  So, if you've recently updated your VUM repository with a new 1000v package, and VUM can't seem to scan or patch your hosts anymore, check the link.

[fgshepherd]

Such a privilege to be a part of this company during an amazing period of growth and development.

[fgshepherd]

VMware Feature Request - Resource Pools: Storage

Looking for the ability to configure "storage reservations/limits" to shared storage for vSphere when setting up a Resource Pool.  VMware, are you listening?

[fgshepherd]

HA Datastore in vSphere 5 SDRS

Dear VMware, Would it be possible to provide an "HA" datastore-- primarily dedicated to volume overflow in a datastore cluster? We'd like to put several datastores in a datastore cluster, then not balance them by I/O latency or space...but if one should happen to fill up, we'd like to designate a slower/thin-provisioned "spillover" target. The net result would be that the VMs on that datastore would be able to stay up, but they'd be slower, getting someone's attention, so that more space could be added to the original datastore/contract. Thank you for considering it!