HOWTO: Dell vSphere 6.0 Integration Bits for Servers

When I do a review of a vSphere site, I typically start by looking to see if best practices are being followed – then look to see if any of the 3^rd party bits are installed. This post picks on Dell environments a little, but the same general overview holds true of HP, or IBM/Lenovo, or Cisco, or…. Everyone has their own 3^rd party integration bits to be aware of. Perhaps this is the part where everyone likes Hyper Converged because you don’t have to know about this stuff. But as an expert administering it, you should at least be aware of it, if not an expert.

I’m not going to into details as to how to install or integrate these components. I just wanted to make a cheat sheet for myself, and maybe remind some folks that regardless of your vendor, make sure you check for the extra’s – its part of why you’re not buying white boxes, so take advantage of it. Most if it is free!

The links:

I’ve picked on a Dell PowerEdge R630 server, but realistically any 13G box would have the same requirements. Even older 11/12G boxes such as an R610 or R620 would. So first we start with the overview page for the R630 – remember to change that OS selection to “VMware ESXi v6.0”
http://www.dell.com/support/home/us/en/04/product-support/product/poweredge-r630/drivers

 

Dell iDRAC Service Module (VIB) for ESXi 6.0, v2.2
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=2XHPY

You’re going to want to be able to talk to and manage the iDRAC from inside of ESXi, so get the VIB to allow you to do so. This installs via VUM incredibly easy.

 

Dell OpenManage Server Administrator vSphere Installation Bundle (VIB) for ESXi 6.0, v8.2
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=VV2P2

Next, you’ll want to be able to handle talking to OMSA on the ESXi box itself, to get health, management, inventory, and other features. Again, this installs with VUM.

 

OpenManage™ Integration for VMware vCenter, v3.0
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=8V0JG

This will let your vCenter present you with various tools to manage your Dell infrastructure right from within vCenter. Installs as an OVF and is a virtual appliance, so no server required.

 

VMware ESXi 6.0
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=CG9FP 

Your customized ESXi installation ISO. Note the file name – VMware-VMvisor-Installer-6.0.0-2809209.x86_64-Dell_Customized-A02.iso – based on the -2809209 and the –A02 and a quick Google search, you can see that this is v6.0.0b (https://www.vmware.com/support/vsphere6/doc/vsphere-esxi-600b-release-notes.html) vs v6.0U1.

 

Dell Systems Management Tools and Documentation DVD ISO, v.8.2
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=4HHMH

You likely will not need this for a smaller installation, but it can help out if you need to standardize, by allowing you to configure and export/import things like BIOS/UEFI, Firmware, iDRAC, LCC, etc settings. Can’t hurt to have around.

 

There is no longer a need for a “SUU” – Systems Update Utility, as the Lifecycle Controller built into ever iDRAC, even the Express will allow you to do updates from that device. I recommend doing them via the network as it is significantly less hassle than going through the Dell Repository Builder, and downloading your copies to a USB/ISO/DVD media and doing it that way.

Now, the above covers what you’ll require for vSphere. What is NOT immediately obvious is the tools you may want to use in Windows. Even though you now have management capability on the hosts and can see things in vCenter, you’re still missing the ability to talk to devices and manage them from Windows – which is where I spend all of my actual time. Things like monitoring, control, management, etc, all are done from within Windows. So let’s go ahead and change that OS to “Windows Server 2012 R2 SP1” and get some additional tools:

 

Dell Lifecycle Controller Integration 3.1 for Microsoft System Center Configuration Manager 2012, 2012 SP1 and 2012 R2
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=CKHYR

If you are a SCCM shop, you may very much want to be able to control the LCC via SCCM to handle hardware updates.

 

Dell OpenManage Server Administrator Managed Node(windows – 64 bit) v.8.2
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=6J8T3

Even though you’ve installed the OMSA VIB’s on ESXi, there is no actual web server there. So you’ll need to install the OMSA Web Server tools somewhere – could even be your workstation – and use that. You’ll then select “connect to remote node” and specify the target ESXi system and credentials.

 

Dell OpenManage Essentials 2.1.0
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=JW22C

If you’re managing many Dell systems and not just servers, you may want to go with OME if you do not have SCCM or similar. It’s a pretty good 3^rd party SNMP/WMI monitoring solution as well. But will also allow you to handle remote updates of firmware, BIOS, settings, etc, on various systems – network, storage, client, thin client, etc.

 

Dell OpenManage DRAC Tools, includes Racadm (64bit),v8.2
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=9RMKR 

RACADM is a tool I’ve used before and have some links on how to use remotely. But this tool can grandly help you standardize your BIOS/IDRAC settings via a script.

 

Dell Repository Manager ,v2.1
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=2RXX2

The repository manager as mentioned is a tool you can use to download only the updates required for your systems. Think of it like WSUS (ish).

 

Dell License Manager
http://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?driverId=68RMC

The iDRAC is the same on every system it is only the licence that changes. To apply the Enterprise license, you’ll need the License Manager.

 

Hopefully this will help someone keep their Dell Environment up to date. Note that I have NOT called out any Dell Storage items such as MD3xxx, Equallogic PSxxxx, or Compellent SCxxxx products. If I tried to, the list would be significantly longer. Also worth noting is that some vendors _networking_ products have similar add ins, so don’t forget to look for those as well.

HOWTO: Fix pbm.fault.pbmfault.summary when cloning

Let’s suppose you’re cloning some VM’s from a template, and you receive a “pbm.fault.pbmfault.summary” error and it fails. 

A very quick google search will find you the following VMware KB article. 

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2062112

While it references the vCenter Server Appliance, and a DNS issue, the key portion is that it comments on the vCenter Server Inventory Service.

Which should certainly not be STOPPED, never mind what type of server it’s on or if DNS is working. 

Get that started, and there’s a good chance you won’t have to worry about if you’re on the appliance or have DNS issues. 

This is also probably a good time to look at your service failure handling:

Perhaps you want to automatically restart the service, send an e-mail, or restart the computer.  In any event, give some thought to how you’ll make this more self-healing in the future!

vSphere 6.0 Announced!

Well, finally, VMware has announced vSphere 6.0.  It’s been a long beta, with the typical NDA’s that have kept anyone from talking about what they’ve been testing.  For the last while, it’s been an open beta, so those interested were able to take a look at what’s under the hood. 

First some VMware links to get some information collected all in one spot, and some summary:

What’s New In vSphere v6.0

* Jumbo VM support – this probably won’t matter to most of us, but to think that we can do 128 vCPU and 4TB vRAM per VM is crazy. 

* Instant Clone using a forking technology to deploy VM’s up to 10x faster than today

* vVols!  Policy based storage containers for everyone, not just for VSAN.

* Long distance vMotion up to 100ms round trip – this means vMotion across the country is now possible. 

* 4 vCPU Fault Tolerance – again, probably not something we’ll see a lot of use for, in my opinion.   Anything that needs this level of uptime, probably has some manner of HA or clustering already – but it sure is nice to have the option.

* Content library – now we can make VM’s, Templates, and ISO’s available without having to keep them on a datastore.  We can also set it up to replicate this content between library’s, making it easy to keep this information in sync.

* Cross vCenter Clone and Migration – this goes hand in hand with the long distance vMotion, and allows migration from Private to Public, Private to Private, and more.  Tons of options.

* A faster Web UI – yeah, it’s the Web UI.  But it IS faster!    (Please keep the C# client VMware, we truly despise the Web Client. 

If you’re looking for deeper levels of information, I highly recommend these other links:

http://vsphere-land.com/news/summary-of-whats-new-in-vsphere-6.html

http://www.wooditwork.com/2015/02/02/whats-new-vsphere-6-0-introduction/

http://virtualgeek.typepad.com/virtual_geek/2015/02/vsphere-6-epic-on-every-level.html

http://www.yellow-bricks.com/2015/02/03/vsphere-6-0-finally-announced/

Now, I’ve been spending considerably more time in the SMB to SME space as of late.  Even without that role, my experience tends to lead me towards smaller environments.  And at that, small is not always “Small”.  Hosts with 384-768GB of RAM, can run a pretty decent sized environment with less than 10 hosts.  For me, it’s not all the “big” things that impress me – or make my work life that much better.  It’s the trickle down, and how it helps me help businesses of this size. 

Some of THOSE features that make me excited, which repeat some of the above:

* Long distance vMotion is going to change some of the options we can provide for DR and disaster avoidance.  The bigger issue is getting networks that support this at the 3-5 host level without tons of fancy software or licences.  Otherwise, it’s going to be something that’s stuck on other side of the glass.

* Simplified installer will make installations quicker and easier.  It’ll be nice to have a single installer, with all the questions asked up front, that runs through the rest in the background.

* Content library’s will be a great way to keep Template’s and ISO’s standardized and up to date.  In a previous multi-site environment, keeping those templates updated with all the patches, software deployments, etc, was a pain. 

* vSphere Replication can compress replication traffic on a per VM basis. 

* vSphere Data Protection now includes everything from VDP Advanced – up to 8TB of DeDuplicated data per appliance, up to 800 VM’s, application level backup/restore of Exchange/SQL/SharePoint, replication to other VDP appliances, and Data Domain support.  I’ve always preferred Veeam Backup & Recovery to VDP, but hopefully this will help those customers that just can’t (or won’t) step up to an excellent backup product.  Something, is better than nothing, and this is a lot better than what it used to be.

* VSAN 6 now supports All Flash configurations.  With the price of decent Enterprise class SSD’s dropping, this is actually starting to be a possibility.  Especially for those that can keep host counts down to keep licencing costs at bay.  We can now specify fault domains to ensure that nodes aren’t in the same chassis/rack/etc.  Hybrid (SSD+HDD) configurations can see an increase of 2x from 20K IOPS to 40K, and All-Flash can see 90K.  Still lacking features like DeDupe and Compression, so there may still be places for the traditional array’s.  Deep integration with VDP and vSphere Replication, however, start to offset some of the traditional array’s core features. 

All in all, I can’t wait to get my hands on the GA bits and start deploying this.  Remember kids, always check  your application/3rd party compatibility.  No one wants to upgrade and find out their antivirus, backup, monitoring, etc, solutions don’t work on the new version yet. 

HOWTO: Fixing mixed FQDN/Host naming in vCenter

Have you ever run across an environment, where no matter what you do, you can’t seem to get the ESXi host to register as a FQDN? Have you ever had to work in an environment without AD and without local DNS? Yeah – it’s tons of fun. The customer is always right though, and while they have some Windows systems, this is what they grew the company being used to, and use IP’s for everything. Such is life. Let’s talk about how to fix the hosts though, without trying to force AD and full on DNS naming down their throats.

First, the problem:

That name WAS specified with a FQDN. Then it went away.

And this is what it looks like in vCenter. I realize that this is going to be tough to demonstrate properly while redacting some of the names, but we’ll get the general point across. Here you can see that the first two hosts are added with their FQDN, but the 3^rd is just using the hostname. I removed and re-added the host, reset settings at the DCUI, nothing made a difference.

When you try updating the configuration from the DCUI, you’ll get:

So it DOES show up.

When you try to add it (or add it back) to vCenter you see:

Clearly, I’m specifying the FQDN. Click Next though….

Someone want to tell me where my FQDN went?

The answer, seems to be in due to it having previously been added incorrectly. I found a VMware KB that talks about how to reconfigure it – WITHOUT removing it from Inventory first – which I still haven’t gotten working before finding the KB. Remember, removing the host from inventory removes all history and performance data for it – something you MAY not want to do!

So I follow all these steps:

· Disconnect (not Remove, if you want to keep performance stats) the host in vCenter

· Connect the vSphere Client to the host directly and remove the “vpxuser” user

· Reconnect the host, which should find the new host name.

And no go. Same as above.

Remember now, this site doesn’t have AD or DNS. So I started looking around. Here’s what existed prior, most of which I knew, but working in an environment like this isn’t ‘normal’ for me, so I didn’t think a lot about it:

· The OLD vCenter v4.0 was running DNS in a half-ass way on 192.168.100.20

· The NEW vCenter v5.5 server I had made a C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS file with entries for the hosts

· Hostnames were first then FQDN. This means the first name it found to resolve would be the hostname alone

· DNS on this NEW vCenter v5.5 server was pointing at the old server – something I did so I could get started, but didn’t finish up. It never knew about this 3^rd host.\

So – what fixed it? Some combination of:

· Add DNS role to the new vCenter server. Not a great place for it, but then at least I HAVE DNS available

· Add the Hosts (and iDRAC records, and whatever else) to the new zone you create in DNS

· Modify the local HOSTS file to be FQDN then Hosts – or remove it altogether is probably a better option

· From an administrative CMD prompt on the vCenter server, run “ipconfig /flushdns”.  You have to do this on the vCenter Server, not where you are running the vSphere Client from (which MAY be the server, I don’t know what you’re doing), because the client is telling the server to add the host – and thus, vCenter is doing the resolution, not your client system. 

· Re-add the host:

Yeah. That’s right. It’s finally there J

Another quick issue to note with lack of DNS – Veeam was giving NFC issues trying to back up VM’s on this 3^rd host. Similar issue. IT was pointing at the old DNS, which only knew about hosts 1 and 2. While vCenter was able to find the hosts, Veeam couldn’t resolve them directly, and got angry.

Moral of the story – healthy DNS and name resolution makes for less drinking.

General Availability of VMware ESXi 5.5.2 Patch & vSphere v5.5 U2

I figured I’d spread the word, that VMware ESXi 5.5.2 patches are now out.  One can check out the original announcement right from VMware at: http://app.connect.vmware.com/e/es.aspx?s=524&e=41732608&elq=12684a06f96444ed8d0d52503f7035b7

Also, vSphere v5.5 Update 2 was recently announced as well.  One of the best posts I found on this was over at Vladen Seget’s blog:  http://www.vladan.fr/vmware-vsphere-5-5-update-2-released/ 

The best highlights of the release, in my mind?

• vSphere Client (C#) will now allow editing of VMware Hardware v10 VM’s.  Note that it will only allow editing of features exposed in v8 hardware.  So you won’t be able to edit any vSphere Flash Read Cache or AHCI disks, but otherwise, you’ll largely be okay.  On the one hand, this is good as it buys us some time to stay with the C# client – on the other, it’s a bitter reminder that soon we’ll have only the Web Client…
• vCenter Server now supports running on SQL Server 2012 SP1 and 2014
• vCenter Server is now at v5.5 U2 – which is far better than trying to figure out if it’s on v5.5 U1a/b/c/driver-rollup.  They really need to standardize this – when is it a x.y.0(a/b/c), when is it an x.y Update, etc? 
• Just about every product got an update to coincide with this one, including many v5.8 versions announced at VMworld 2014.
• Horizon View v6.0.1 and Horizon Workspace v2.1 are also refreshed.

Release notes can be found at: https://www.vmware.com/support/vsphere5/doc/vsphere-vcenter-server-55u2-release-notes.html

Downloads can be found at: https://my.vmware.com/web/vmware/details?productId=353&downloadGroup=VC55U2

Remember to check your 3rd party software for compatibility before jumping ahead.  Software such as Trend Micro DSA or Veeam Backup & Recovery may require updates before they’re 100% compatible.

As always, it’s best to clone your vCenter into an isolated environment (with a DC and DB server) to test the upgrade process with safety before you jump in all the way.

HOWTO: VMware Horizon Suite 6 – vCenter Server Configuration

In the previous post, https://vnetwise.wordpress.com/2014/09/07/howto-vmware-horizon-view-6-vcenter-server-installation/, we covered how to get your basic vCenter v5.5U1 installed – which will largely be the same be it for vCenter for general infrastructure, for View or for Horizon. In this article, we’ll be doing some basic configuration of vCenter to get some hosts and a cluster built so we have a place to deploy Horizon Suite.

To begin, we’re going to want to launch the vSphere Web Client. If you’re doing so from the server vs a workstation, you may run into your first minor hiccup:

You’ll need to install Adobe Flash Player. So you’ll need to make a decision as to if you want to install this on your server, or continue the work from a workstation that has allowances for this. Perhaps your server policy doesn’t allow additional software installed. Maybe Flash specifically is banned. Maybe it is not, but browsing the public internet from a server is denied by force or request. In either manner, we’ll assume you’re performing the remaining of these steps from a system with Adobe Flash installed.

1) Launch your browser and point at https://<vcenter>:9443/vsphere-client:

Note that you may need/want to add the self-signed SSL as trusted, and also that pop-ups and/or plug-ins may be blocked as you go. So if a feature doesn’t work, check this.

Login as administrator@vsphere.local

2) Click on ADMINISTRATION and then SINGLE SIGN ON\CONFIGURATION:

We want to confirm that our AD domain is present. If not, we need to add it. vSphere 5.5 U1 is much better at ensuring this is added by default.

3) Click on SINGLE SIGN-ON\USERS AND GROUPS:

When you click on ADMINSTRATORS, you will note that the only member is the administrator@vsphere.local account. Click the ADD MEMBER icon.

4) From the DOMAIN drop down, choose your AD domain. Change it to SHOW GROUPS first, and search for your AD group.

In my case, I have created a “vSphere Admins – VDI” group so we don’t use the Domain Admins or similar. Select the item and click ADD so it shows up in the GROUPS field. Then click OK.

You can verify that your group now shows up.

5) Next, we’ll need to click HOME:

vCenter:

vCenter Servers:

Select your vCenter Server:

Then MANAGE -> PERMISSIONS and -> ADD:

Note the only group currently is the VSPHERE.LOCAL\ADMINSTRATOR user. This is what we’re going to be adding to, so our new group has rights.

6) Similar to Step 4 above, click ADD, change the domain to your AD domain and search for your group. Click ADD.

This returns you to the ADD PERMISSION screen with the group selected. Next you need to change the ASSIGNED ROLE to ADMINISTRATOR. Then click OK.

Now your AD group shows up as an Administrator at the vCenter Server object – and it’s children.

7) Choose to log out from the drop down:

We want to log back in as an AD user of the AD group we’ve added, so we can confirm things are working as expected.

Remember that it is in UPN format, so it will be <username>@<domainname>

8) Click on VCENTER -> VCENTER SERVERS -> <your vCenter>. Click ACTIONS, and choose NEW DATACENTER.

Enter the name of your datacenter and click OK.

9) The client will automatically take you to the new DATACENTER object. Click on ACTIONS -> NEW CLUSTER:

Enter the name and details for your cluster. Enable HA and DRS. Click OK.

Click on CLUSTERS to change to that context. Then double click on the cluster name in the lower right corner.

NOTE: There are some configurations within the Horizon Suite that require DRS to be enabled – even if you have a cluster of one host. So ensure you do set it, even if you set the operation to MANUAL.

10) Click ACTIONS -> ADD HOST:

Add the host name and click NEXT.

Enter the username and password for the host:

Accept the SSL thumbprint and click YES.

In my case, the host is already being managed by another vCenter. So I’ll click NEXT to bring it into this vCenter.

The existing host already has a licence. If not, you can either enter a key or choose to use Evaluation Mode. Click NEXT.

We will choose to NOT enable lockdown mode. Click NEXT.

We’re going to use the default Resource Pool. Click NEXT.

Click FINISH to complete the host addition.

Repeat for any additional hosts. I’ll be adding NW-ESXI02.netwise.ca as well.

At this point, the basics of the vCenter for View are now configured. We now have:

· A Cluster inside a Datacenter object

· 2 hosts, so we can do some vMotion/DRS and test failover – what good is a PoC that doesn’t test failure situations to ensure that it behaves as you expect

· Hosts have storage and networking configured and are otherwise ready to go.

We haven’t touched on other settings such as alerts, or NTP/SysLog/etc, but they’re really more in-scope for a general vCenter walkthrough, and we’ll assume either this is just a demo environment or you’d be performing those tasks anyways, and you’re just here to find out how to get Horizon Suite up and running. Also, we haven’t touched on things I’d be typically using like NetApp VSC, VAAI for NFS, or VMware Update Manager (VUM). We’ll talk about this later, once we get the general environment going.

Our next step will be to actually deploy some of the Horizon components.

HOWTO: VMware Horizon View 6 – vCenter Server Installation

This is a document in a series, started by HOWTO: VMware Horizon View 6 – Overview.

In this document, we’ll install the basic vCenter server required for use by Horizon Suite 6. Some general prerequisite notes are:

· We’ll need the vCenter Server v5.5 U1 ISO to perform the installations

· We’ll be utilizing the default administrator@vsphere.local accounts, at least initially. As we go forward, we’ll configure AD groups and roles

· We’ll be utilizing locally installed SQL Express instances for any SQL requirements

· We’ll be utilizing Windows 2012 R2, which will require the installation of .NET 3.5 as a pre-requisite. See: HOWTO: Add .NET 3.5 to Windows 2012 or 2012 R2

· We will be accepting all defaults, for ports, file locations, etc.

With that in mind, let’s begin.

1) Start the vCenter Server installation:

2) Run the vCenter Single Sign-on Installer.

a) Accept the licence agreements, and accept the pre-requisites.

Click NEXT.

b) We’re going to create this as a standalone vCenter Single Sign-on. Bigger more complex environments may wish to use a common single sign-on environment.

Click NEXT.

c) Enter the Administrator@vsphere.local password. Don’t forget to add this to your password documentation.

Click NEXT.

d) Configure the site – we’ll use the default “Default-First-Site”.

Click NEXT.

e) Accept the default port:

Click NEXT.

f) Accept the default destination folder.

Click NEXT.

g) The final screen, will present the installation options to review.

Click INSTALL.

Click FINISH when the installation is complete.

3) Run the vSphere Web Client installer:

a) Accept the licence agreements, and the default Destination Folder.

Click NEXT.

b) Accept the default ports.

Click NEXT.

c) Enter the Adminstrator@vsphere.local password.

Click NEXT.

d) Accept the SSL prompt:

Click YES.

e) You’ll be asked to install the certificate.

Click INSTALL CERTIFICATE.

f) On the Ready to Install screen – click INSTALL.

g) Click FINISH to complete the installation.

4) Launch the vCenter Inventoory Service installer

a) Accept the licence agreements, and the default Destination Folder.

Click NEXT

b) The local FQDN should be automatically and correctly populated.

Click NEXT.

c) Accept the default ports.

Click NEXT

d) Configure the JVM Memory – almost certainly you’ll be “Small”.

Click NEXT.

e) Enter the Adminstrator@vsphere.local password.

Click NEXT

f) Accept the SSL prompt:

Click YES.

g) On the Ready to Install screen, click INSTALL.

Click FINISH

5) Launch the vCenter Server installer:

a) If you did not install .NET 3.5 as per the pre-requisites, you’ll see the following message:

Ensure you go and install .NET 3.5 via the Add-Features.

b) The first screen after the licence agreements, will ask for a licence key:

You’re able to skip this at this point, so click NEXT. We can add licences later if this PoC stays around.

c) Accept the licence agreements, and the default Destination Folder.

d) On the Database Options screen, you’ll need to make some choices.

As this is both small scale, and a PoC, we’ll use an SQL 2008 Express instance. This might work just fine long term for a small environment with a few hosts. Click NEXT.

e) The vCenter Server Service will ask how it will run.

Most sites opt to use a named service account. If you uncheck the USE WINDOWS LOCAL SYSTEM ACCOUNT option, you’ll find that you cannot change the Account Name – this is why we always run the installations logged in as the user who will be the service account. Note, however, this service account doesn’t yet have any rights to SSO or vCenter Inventory, so you may have to go back a step to fix/configure that, if you want to go forward with a named service account. It should be fine to utilize the Local System Account. Click NEXT.

f) Next, we have to choose if we’re using Linked Mode or not.

A proper enterprise deployment would likely consider a Linked Mode deployment. However, there are simplicities that come from having a standalone environment. I’ll be using a standalone vCenter. Click NEXT.

g) On the Configure Ports screen, accept the defaults:

Click NEXT.

h) On the JVM Memory screen, we’ll be selecting SMALL:

Click NEXT.

i) Enter the SSO password for the administrator@vsphere.local account.

Click NEXT

j) Accept the SSL warning.

Click YES.

h) Configure the SSO administrator or group:

We’ll be configuring and confirming all AD group authentication after the fact, so we’ll accept the default. Click NEXT.

i) On the vCenter Inventory Service Information screen, accept the defaults:

Click NEXT.

j) Choose your Destination Folder:

Click NEXT.

k) When the Ready to Install the Program screen appears:

Click INSTALL.

Click FINISH when it is complete.

6) Launch the VMware vSphere Client installer. As this is still vSphere v5.5, we’re going to require the C# client for things like VUM and SRM if we go that far. We’re all familiar with this install, it’s “Next, Next, Finish.”

7) Launch the vSphere Update Manager installer

a) Accept the licence agreements

b) On the Support Information screen, leave the default checkbox for DOWNLOAD UPDATES:

Click NEXT.

c) On the vCenter Server Information screen, remember that we have not yet configured SSO for AD and/or a service account. So you will need to configure this using the administrator@vsphere.local account for the moment. Enter the password for this account:

Click NEXT.

d) VUM requires a database of its own. The default will install a separate instance, which is fine for our needs:

You would almost certainly want to share a database instance with vCenter and/or other infrastructure. Note that VUM still requires a 32bit DSN, which has some hoops to jump through to be created on a 64bit OS. Click NEXT.

e) VUM wants to know how it will be identified on the network. From the drop down choose the FQDN and leave the firewall ports default.

Click NEXT

f) Choose the destination folders:

Click NEXT

g) VUM by default, suggests 120GB free on the VUM drive:

Keep this in mind, as you’ll likely be expanding the VUM disk at some point. Click OK.

h) Click INSTALL to install:

Click FINISH when it is complete.

The next step will be to configure the vCenter server. Steps such as creating a datacenter, a cluster, adding hosts, etc. Also any modifications required for AD roles and assignments.

Lab Learning Lessons–01

So I figured I’d start a new theme, which the title represents.  This is “Lab Learning Lessons” or things you learn in the lab, that are better learned here than in Production somewhere.  Hopefully this will help you out in the future, or if nothing else will reinforce for me that I’ve done this before.  So with that in mind – this week’s lessons!

 

1) I can’t find the stupid ISCSI Target!

Ever have one of those days?  Setup a new SAN, configure the NIC’s, configure ISCSI, make some LUN’s, configure your Initiator Groups, and… nothing?  Add the ISCSI target to the Dynamic Initiators in the ESXi Software ISCSI Initiator and…. it never finds any Static Initiators like it should?  So you try to do a “vmkping <target_IP>” and sure enough, THAT works.  Worse yet, you do the SAME thing on the secondary NetApp (in this case) controller in that chassis, and IT works.  So you’re doing the right thing.  So you check against the OLD controllers – and your settings are similar as they should be.

So you change the IP addresses on the Targets and… boom.  It works.

Lesson Learned:  IP Address conflicts don’t tell you if the thing that is responding to your test pings is the device you WANT it to be.

 

2) Can’t vMotion VM’s.  Or create a new one.  Or create objects on a new datastore.

Sounds strange right?  The error includes “pbm.fault.pbm fault.summary” for everything you do.  VM’s are otherwise working and doing what they should be.  You can start, restart, reboot, etc.  You just can’t move them around.  A little Google-fu will suggest that you restart the vCenter Inventory and/or Profile Driven Storage service(s).  Sounds reasonable.  Except those take forever to do so.  So you reboot the vCenter server, hoping that’ll help.  No go.

Then you open Explorer…. and realize your vCenter is out of space.  Except all the services are quite happily started.  No “Automatic” services are unstarted or failing to start.  Nothing is tripping an error.  It’s just “not working”.

Lesson Learned:  Maybe if you’re not going to use a 3rd party monitoring solution (eg: Nagios, ZenOS, PRTG, SolarWinds, etc), then you should configure basic Windows Scheduled Tasks to send e-mails when a drive gets to a certain used amount.  Might save some stress.

 

3) IP Address Planning.

I’m big on having “predictable” IP Address standards.  If you can, have “Primary” addresses be a x.y.z.1# and “Secondary” be x.y.z.2#, or some other system that works for you.  Also if you have 4 NIC’s maybe the #’s in the previous examples should be the NIC #.  So on a NetApp, e0c and e0d would be 3 and 4, so your IP would be x.y.z.13, x.y.z.14, x.y.z.23, x.y.z.24, or something else.

The downside is you really need to be able to look at the final configuration, and work backwards.  Are you going to do one IP per NIC?  One per LACP/PortChannel?  (Not so much for ISCSI, but for NFS/CIFS).  if you do one for a virtual interface like an LACP vif – what # is it?  It’s none of NIC 1-4 (e0a/e0b/e0c/e0d).  Would you make it .10 and .20?  Maybe.  Or maybe .19 and .29, as it’s ‘odd’.

What if you have a second unit in the same place?   Is your solution scalable?  The if your first pair of controllers is NW-SAN1 and NW-SAN2, and is .1x and .2x, then NW-SAN3 and NW-SAN4 could easily be .3x and .4x – but are you chewing up a lot of IP’s?  Maybe.  But in my opinion, it’s so worth it.  Reading logs and troubleshooting becomes amazingly simpler, as you can now logically map one device to another by IP, hostname, port and NIC.

Lesson Learned:  Plan out as much as you can in advance.   But if you can’t, try it in a simulator and work through your options.  This is why they exist, and why we have labs.

HOWTO: Dell OMSA v7.4 VIB updates for ESXi via vSphere Update Manager (VUM)

I’m sure that I’ve covered this before, but maybe it a similar post on my blog: https://vnetwise.wordpress.com/2012/04/23/dell-omsa-v7-0-is-out-for-esxi-v5-0u1/

Dell Open Manage System Administrator (OMSA) is the tool installed on ESXi to allow access to the system directly vs via the iDRAC. As ESXi is neither Linux or Windows, it requires VIB’s to install software created by certified partners of VMware. This will cover the process to get the new update installed and available to update hosts during the next maintenance window.

1) Download the latest OMSA VIB – v7.4 for ESXi v5.5. This can be found at: http://www.dell.com/support/drivers/us/en/19/DriverDetails/Product/poweredge-r720?driverId=YCYN1&osCode=XI55&fileId=3351566865&languageCode=EN&categoryId=SM

2) Open the vSphere Client and browse to HOME -> SOLUTIONS AND APPLICATIONS -> UPDATE MANAGER.

3) Click on the PATCH REPOSITORY tab and then click IMPORT PATCHES on the upper right corner:

4) Select the OMSA v7.4 file you downloaded in Step 1:

Click NEXT

5) When the file is finished importing, click FINISH.

6) Click FINISH to confirm the import:

7) Click on the BASELINES AND GROUPS tab:

You can see previous “Dell OMSA v7.x.x” baselines we’ve created. We’re going to create a new one for v7.4.0 so click CREATE.

8) Name your baseline “Dell OMSA v7.4.0” and ensure you select “HOST EXTENTION”:

Click NEXT.

9) Type “openmanage” in the search box and sort by Release Date:

Select your option and click the DOWN ARROW to add it to the lower EXTENTIONS TO ADD window. Click NEXT.

10) Click FINISH on the READY TO COMPLETE screen:

11) Next, on the right hand side of the BASELINES AND GROUPS tab, expand your Baseline Group (you should always have created one – that would be another topic).

Note that if you select the pre-existing DELL OMSA v7.3.0.2 the <- arrow turns green so you can remove it. Do so. Then select DELL OMSA v7.4.0 and click the -> right arrow.

12) Note that your Baseline Group is now updated:

13) Click the COMPLIANCE VIEW link in the upper right hand corner.

14) Click SCAN in the upper right corner to scan your hosts for upgrades, patches, and extentions.

15) Check box boxes and click SCAN.

16) Let your SCAN complete:

17) Once the scan is complete, you’ll see your list of hosts now show the EXTENTIONS column as “non-compliant”:

At this point, the next time your have a maintenance window, you can simply click REMEDIATE and choose the BASELINE GROUP. If you have vSphere Patches, ESXi Upgrades (eg: v5.5.0b to v5.5.0 U1), or Extensions (eg: OMSA VIB’s), all 3 will happen automatically in sequence as or if required.

HOWTO: vSphere vCenter Server v5.5.0a to v5.5.0 U1 upgrade

With the recent release of vSphere v5.5.0 U1, I figured I’d do a quick post on upgrading from v5.5, as I’ll be doing a few of these in the near future, and notes are always a good thing.

Always make sure you’re as safe as possible.  Back up your vCenter SQL server/database, and vCenter Server.  If you can afford the luxury, clone a DC, vCenter, and your SQL server into a non-network connected lab, and test your upgrade there to verify you’re not going to blow anything up. 

Go download and unpack the VMware-VIMSetup-all-5.5.0-1623099-20140201-update01.iso (https://my.vmware.com/web/vmware/details?downloadGroup=VC55U1&productId=353&rPId=5258 – login to MyVMware to get access).

Login to your vCenter server as your vSphere service account (svcVMware in my case) – this will ensure that all services are installed using this account, as some of the options do not ask for credentials. 

NOTE:  Now would be a good time to double check that you have enough free space on your vCenter Server and do a cleanup.  I ran out of space midway through this process, and didn’t notice until it had to be fixed.  Stupid mistake, hadn’t been poking around on that machine in the lab in a while.

Next, launch the AUTORUN.EXE, to get the installer screen up:

As this should be a straightforward “patch” like installation, we’ll simply do the “simple install”.

However, in my case, I was told I already had components installed.  So I guess we’ll be doing it via the Custom Install.

Launch the vCenter Single Sign On installer:

The remainder of this is a NEXT, NEXT, FINISH type of installation.

NOTE: On my system, this seemed to trigger an automatic restart, which then reloaded the installer after I logged back in.  It doesn’t appear I did anything wrong, pressed OK, or told it to reboot.  So plan for this to be in an outage window if possible.

After the restart, let’s get vSphere Web Client installed:

Again, as this is an upgrade, it’s NEXT, NEXT, FINISH.

Note that the Web Client might take a few minutes to startup in the background.

Next, install vCenter Inventory Service.  Again, NEXT, NEXT, FINISH.  It may just be the resources I’ve allocated to my VM in my lab, but launching this installer, and the time it took  where it would sometimes disappear off the screen were surprising.  So give it time.  Make sure you don’t click the installer a bunch of times, as multiple parallel installs will obviously fail.  If you do this, just click “no” for the extra installers and THEN start the first one. 

Then, install vCenter Server.  This was the first one that had any real interaction:

It asked for a username and password for the database, but didn’t allow it to be edited – thus the reason we run the installer as our service account.  Click NEXT, then NEXT, NEXT, FINISH. 

Other than my disk space issue, nothing terribly exciting here.  Everything went as planned. 

Not a very fancy post, but any time you’re doing a major update that isn’t just a patch, it’s worth validating.  I had to check it out for my own lab as well as the stuff in the office, so it made sense to give it a document in case I ran across anything silly.

Don’t forget to update the remainder of the components you use.