VMware VMUG announces the Board of Directors

Posted by Brian on Jul 21, 2010 in VMUG, VMware | View Comments

There has been talk about changes to the VMUG program coming and a steering committee meeting took place earlier this year in Chicago. This appears to be some of the upcoming changes that are a result of the planning and new direction. I am waiting to hear how this will have a positive or negative affect on the VMUG program.

VMware User Group Members,

As announced earlier this year, VMware is supporting the establishment of an independent, customer-led, customer-driven global VMware User Group (VMUG). The VMUG Steering Committee has been focused on forming the structure for this new organization and we are pleased to announce the inaugural VMware User Group Board of Directors.

The board is comprised of a group of experienced VMUG leaders whose knowledge, expertise and vision will provide an invaluable contribution to the VMUG organization. There is much for this Board of Directors to accomplish, as we look forward to the formal launch of the independent VMUG at VMworld in San Francisco this coming August.

The board has developed a VMUG mission statement to reflect the new organization:
The VMware User Group is an independent, global, customer-led organization, which maximizes members’ use of VMware and partner solutions through knowledge sharing, training, collaboration, and events.

The VMware User Group is a user community—of the users, for the users, by the users. Through an independent global VMUG, we believe we can strengthen our collective VMware and VMUG value proposition with expanded collaboration, member programs, and benefits.

As a VMUG member, your feedback and ideas will be critical to improving the VMUG experience and taking it to the next level. We believe that some of the benefits of the new model will be:

• Tap into new VMUG member benefits and programs, such as Special Interest Groups and VMware technical education offerings
• Increase your value to your organization by becoming the recognized VMware subject matter expert through knowledge and contacts gained through VMUG
• Gain more direct access to VMware subject matter experts
• Become part of a global, collective customer voice, impacting VMware products/services

While we are planning the official launch of the new group for August, there are several ways VMUG is already driving value to the members:

• The VMUG Voice—VMUG’s monthly newsletter—will provide news and updates for members
• New member recruitment activities at all VMware events
• Development of new onsite program for VMUG Regional Events
• VMware Technical Sponsors have been assigned to all VMUG Local Groups
• VMUG members will receive the discounted “Early Bird” pricing throughout the VMworld registration period

As we work to establish an independent VMUG, we want you to know that your voice will be heard. To that end, the VMUG Board of Directors is conducting a short survey of our members to better understand the members’ vision for VMUG and define the VMUG value proposition. It should only take about ten minutes of your time and all results will be kept completely confidential. In addition, all survey respondents can enter to win an Apple iPad—just complete the survey by July 30.

We look forward to hearing your feedback and ideas about the new organization. Please direct all communications to memberservices@myvmug.org or 1.800.606.8695.

Together we look forward to launching the new VMUG at VMworld and we hope to see you there!

Sincerely,
The VMware User Group Board of Directors

VKernel Capacity Analyzer goes head to head with VMware CapacityIQ

Posted by Brian on Jul 20, 2010 in Tools, VMware | View Comments

After a recent release of a comparison chart from VMware marketing it appears that VKernel is also taking the gloves off. In the past the two parties seem to be playing nice and VMware was not actively marketing the CapacityIQ product. But VMware seems to be on the attack now and is no longer going to concede this segment to third parties. I recently received the email listed below from VKernel as their response to VMware’s actions, They feel their product stands up against VMware CapacityIQ and is willing to offer administrators a challenge.

Hi There,

You may have seen a recent VMware marketing sheet comparing VMware CapacityIQ to VKernel’s products. We are flattered by their attention!

So here is our challenge: download CapacityIQ from VMware and do the same for Capacity Analyzer. See which one more accurately shows current performance bottlenecks in your VM environment or predicts future bottlenecks.

If we lose, dinner is on us from Omaha Steaks, or we will make a $100 contribution to a charity of your choice.

Either way, you will end up with a full belly or a VM environment free of performance problems.

Best regards,
Bryan Semple
CMO, VKernel
Blog: http://blog.vkernel.com

VKernel Corp.
300 Brickstone Square, Suite 503
Andover, MA 01810

Error reporting Disk Group occupancy in Command View

Posted by mike on Jul 16, 2010 in VMware | View Comments

So this is an error / issue we’ve had to live with for some time. It’s a bit strange to be sure. Essentially in Command View, the Disk Group occupancy is completely incorrect, and continues to grow. Yes, that’s right, I said grow. For some photo-visual enjoyment, here is what a NORMAL Disk Group looks like.

So as you can see, we have a total Capacity (which is correct and accurate), and the Occupancy. The information listed is correct, and it’s refreshing. Now, for the problematic Disk Group (and please ignore the name as it was before my time).

Here we see the correctly calculated Capacity, but lo! What’s this? What on earth is going on with that Occupancy? It seemingly continues to grow a bit here and there as we take snapshots of various. HP doesn’t know what’s wrong either. When we upgrade from Command View 9.0 to 9.1, it did not fix the issue either. The big problem here is that we have to figure out how much space is actually used since we’ll never get alerted. It is a pain. I can turn to Replication Solutions Manager to obtain the correct size by simply adding all the luns (easy way to view them, as opposed to Command View), so that’s the workaround. Not very satisfying if you consider how much money was spent on these beasts.

Command View EVA Overview

Posted by mike on Jul 16, 2010 in VMware | View Comments

This is a walkthrough for HP Command View for EVA. Part of my daily routine is to take a jaunt through CV, to check things over and look for alerts that I may not already be aware of.

Launched from the shortcut on the Windows host, or is accessible via a web browser at https://servername:2372

You are presented with the login screen:

It is here that you will also see the version number (down below). We have not yet upgraded this server to version 9.2 as we are building a VM to run Command View from and retire this physical box.

After login, you are greeted by the overview page. Here you will see all the EVAs listed, as well as the stats for your overall environment. The first thing of note is that two of my EVAs have bang lights on them, indicating something is amiss. I’ll investigate both as part of my next posting.

On the top right, there are some hyperlinks, your login id, and the ip of the Command View server. Most are self explanatory. Server Options provides for a place to enter license codes, setup RSM relationships, and a few other features. I seldom visit this page, so like once a year?

Moving right along, let’s take a look at a healthy EVA, in this case DS-SAN-2:

As you can see from the above, a healthy EVA has a number of folders beneath it. It breaks out into many subfolders. On the right hand side are the numbers. It would be here that you can get the logs for HP support (I’ll cover that in a separate blog post). You can see the current capacity level, view the Version level (this is the XCS code release running on the EVA. 6220 is the latest for the 8100 series). The left column is broken down like such:

Virtual Disks – this is where the luns (vdisks in EVA-speak) are listed. The folder structure is entirely man-made. That is to say, it’s for human organizational purposes (and plays an important role for setting up RSM jobs. More on that will be covered on a separate posting).

Hosts – here is where hosts are setup in Command View. You will provide the host’s OS, and it’s WWN’s for fiber cards. Hosts MUST be setup on every single EVA that you want to present disks from. Annoying, I know.

Disk Groups – these are comprised of physical disks. Best practice says to build these in multiples of 8, and of all the same speed and size. You can choose to not follow these and your performance will suck majorly. I’ve worked on rebuilding two of the 4 EVAs that had improperly constructed Disk Groups. It is PAINFUL to correct, but I’m glad I did. I will cover that also as a separate blog post. FYI: The ungrouped disks folder is for disks that have failed or been ungrouped on purpose. Ungrouping takes time as the EVA moves data from the drive to free it up to be removed or replaced.

Data Replication – it is here that you can create DR groups. This allows you to replicate (synchronous or asynchronously) between EVA arrays. A replication group is comprised of 1 or more vdisks. Sounding like a broken record, I will have a separate posting on replication.

Hardware – it is here that you can check out the status of the hardware. Both controllers are listed, as are all the disks. If there are hardware issues (per a bang light) then you can come here to find out why. The status of failed items is usually fairly straightforward and understandable as to what happened and what should be done.

There is a password authentication bug in VMware vSphere ESXi 4.1

Posted by Brian on Jul 15, 2010 in VMware, vSphere | View Comments

While doing my usual surfing in the VMware forums I came across a thread about a password issue with ESXi 4.1. The issue seems to be that the latest version of ESXi only looks at the first 8 digits of your password. So as long as you type in the first 8 digits of your password correct the rest does not matter. I was able to recreate this in my home lab using a 10 digit password.

So to make it crystal clear when I installed ESXi 4.1 with Build # 260247 I entered a 10 digit password for “root”. After the install and a reboot I was able to login using my password as expected. I then enabled TSM mode for local and SSH access. I was then able to log on using local or SSH as the method using my exact password, just the first 8 digits or the 8digits plus anything else after. I even tried entering the first 8 digits and several digits of random characters afterward and it still accepts the password.

I will post a follow up to this post once something is released from VMware regarding this password issue. Until then you can follow along with the thread over on the VMware forums if you wish.

Update July 19th, 2010

VMware released a KB article today that basically explains the issue but does not really offer a fix. It really looks like there will not be a fix and we will just be limited to 8 character passwords. VMware KB Article.

Pre-install requirements for upgrade to VMware vCenter 4.1 server

Posted by Brian on Jul 15, 2010 in VMware, vCenter Server, vSphere | View Comments

With this weeks release of vSphere 4.1 from VMware the operating system requirements have been raised to 64 bit. What this means is that all management consoles and related tools have moved or will be moving soon to 64 bit only systems. Most importantly is that vCenter server 4.1 is now dependent on a 64 bit OS to run. This means that before you rush to upgrade you will need to make sure if your running on a physical server that it is 64 bit capable. If not then you will require a new server or you could elect to move it to a 64 bit virtual machine.

Currently only the operating systems listed below are the only 64 bit options support by the new vCenter 4.1 server.

Something new with this release is the vCenter Server Data Migration Tool. This new tool will help to migrate some of your data and settings over to a new server depending on what your configuration was. There are some very rigid rules on what it will and wont move across. The list below is the only options that it will migrate. Judging from that list every production setup I’ve ever seen is going to require the usual manual steps to be done. Since I don’t think anyone out there is using SQL express as their DB in anything other than maybe a small lab environment. Your gonna need to configure 64 bit DSN’s for your vCenter and Update Manger Databases on the new server yourself.

You can use the vCenter Data Migration Tool to automatically migrate the following to a new server:

• vCenter Server Software and its configuration
• vCenter Update Manager Software and its configuration
• VMware Orchestrator Software and its configuration
• The default SQL Express 2005 database that comes installed with vCenter Server.

To see the full details from VMware on this process refer to this article.

Different ways to enable Tech Support Mode TSM on ESXi 4.1

Posted by Brian on Jul 14, 2010 in VMware, vSphere | View Comments

For anyone that has been running or played with ESXi in the previous versions you should have a good idea of what Tech Support Mode is. The Tech Support Mode or TSM is a sort of simple version of the system console that was available on the classic versions of ESX. Except that the TSM mode is not Linux based and does not have all the capabilities that the old COS had. But you can now access Tech Support Mode locally or via SSH if you follow the instructions below to enable them. I have become very comfortable with the old console access and that’s probably my biggest complaint about having to use ESXi. I’ve been playing around with the vMA or virtual management appliance that can be used to remotely manage ESXi hosts in the lab but its just not the same. I guess it will become second nature the more that I use it since classic ESX will no longer be offered in ESX 5.0 when it is released in the future.

1. At the DCUI of the ESXi host, press F2 and provide credentials when prompted.
2. Scroll to Troubleshooting Options, and press Enter.
3. If you want to enable local TSM, select Local Tech Support and press Enter once. This allows users to login on the virtual console of the ESXi host.

   If you want to enable remote TSM, select Remote Tech Support (SSH) and press Enter once. This allows users to login via SSH on the virtual console of the ESXi host.

4. Optionally, if you want to configure the timeout for TSM:
5. 1. Select Modify Tech Support timeout and press Enter.
   2. Enter the desired timeout value in minutes and press Enter.
6. Press Esc three times to return to the main DCUI screen.

1. Select the host and click the Configuration tab.
2. Click Security profile > Properties.
3. Click Local Tech Support or Remote Tech Support (SSH) and click Options.
4. Choose the desired startup policy and click Start, then click OK.
5. Verify that the daemon selected in step 3 shows as running in the Services Properties window.

1. Select the host and click the Configuration tab.
2. Click Advanced Settings.
3. Change the UserVars.TSMTimeOut field to the desired value in minutes.
4. Click OK.

1. At the main DCUI screen, press ALT+F1 simultaneously. This opens a virtual console window to the host.
2. Provide credentials when prompted.

   Note: When typing the password, characters are not displayed on the console.

1. Open an SSH client.
2. Specify the IP address or domain name of the ESX host.

   Notes:

3. • Directions may vary depending on what SSH client you are using. For more information, consult vendor documentation and support.
   • By default, SSH works on TCP port 22.
4. Provide credentials when prompted.