Yellow Bricks

by Duncan Epping

Howto

Increasing the queue depth?

· ·

One of the most promising blogs of this moment is definitely Frank Denneman‘s blog. Frank is a freelance consultant with a focus on virtualization and storage. His latest addition “Increasing the queue depth” is an excellent article and really shows that Frank knows what he’s talking about!

When it comes to IO performance in the virtual infrastructure one of the most recommended “tweaks” is changing the Queue Depth (QD). But most forget that the QD parameter is just a small part of the IO path.

The IO path is made up of layers of hardware and software components, many of which can have a huge impact on the IO performance. The best results are achieved when the whole system is analysed and not just the ESX host alone.

I’m not going to copy and paste his entire article of course. Head over to his website and start reading. I can also recommend these articles: SRM and HP Continous Access DR Group Design and HP CA and the use of lun load balancing scripts. Don’t forget to bookmark the site or add it to your rss reader!

VI:OPS

· ·

I’ve recently added VI:OPS to my rss reader. The amount of high quality documents/articles released over the last couple of days really amazed me. For those that don’t know VI:OPS:

If you look at the existing forums and resources, they are very focused on the products and technology from VMware with most users being VCPs / VMware administrators. However, there are some topics that aren’t covered in the existing forums (such as Availability) and the purely technical focus of the existing topics is not relevant to a whole other field of professionals that have different challenges with virtualization, like the Operations team.

To bridge this gap, we created VI:OPS to widen the discussion beyond pure, deep technical by adding five topics that VMware staff, partners and customers talk about all the time but where there is no online collaboration facility for these topics.

In short, VI:OPS focuses more on procedures and processes. A great example is this article by Rob Ford: Implementing ITIL V3 Capacity Management in a VMware environment. This is were VI:OPS clearly differentiates from the VMTN Community. I guess you could say that VI:OPS guides you towards operational readiness where VMTN is more educational in terms of technology and troubleshooting.

One of the best articles this week was written by Rodney Haywood aka Rodos. Rodney wrote a great VI:OPS article on Migration Methodologies. The document outlines all necessary steps for a successful migration from physical to virtual. It even includes a description of several migration tools including VMware Converter and Platespin Powerconvert.

Another great read is definitely Steve Chambers document “Initiating the deployment“. This document is still under heavy construction but already contains a wealth of information for Architects, VCPs, Project Leaders and even Managers. It describes the various pre-stages of a virtualization project ranging from Financial Justification to a Project Charter.

And what about these two posts, a library of VMware Visio Stencils and VMware Icons and Diagrams in PPT form. A must have for everyone documenting VI3 or Designing virtual environments.

Now head over to VI:OPS and start reading and of course contribute!

Train Signal virt CBTs still 25% reduction

· ·

A couple of weeks ago I wrote about Train Signal, the post included a reduction coupon, YELLOWBRICKS. This coupon gives you 25% reduction on the Train Signal virtualization CBTs. Train Signal was so kind to also provide me with an additional coupon that gives you free shipping:

All you need to do is head over to Train Signal and enter the following coupon code “YELLOWBRICKS” and “FREESHIP”. By buying a CBT you also support Yellow-Bricks.com! Both coupon codes are valid till the end of the month, just two weeks left…

vCenter and SQL service dependencies

· ·

During several projects I noticed that for some reason the vCenter service would not start correctly. After a quick browse in “services.msc” and the eventlog I noticed that the vCenter service started before the SQL service. As you can imagine vCenter needs SQL to be up and running before it can actually start. I fixed it by creating a dependency. For some weird reason I never blogged this, but today I noticed this KB article that describes how to set up this dependency:

Adding a dependency to the VirtualCenter service so that it waits for SQL Express remedies this.

To create a service dependency:

  1. Click Start > Run.
  2. Type services.msc and press Enter.
  3. Locate the SQL Express instance for VirtualCenter. For example, SQL Server (SQLEXP_VIM).
  4. Open the SQL Express instance and note the Service Name. For example, MSSQL$SQLEXP_VIM .
  5. In the Run dialog, type Regedit.exe and press Enter. Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vpxd .
  6. Double-click the DependOnService key and add the Service name using the name identified in step 4.
  7. Close Regedit .
  8. Go back to the Services Panel and open the SQL Server properties.
  9. On the Dependencies tab, verify the VMware VirtualCenter service is listed as depending on the SQL service instance.

As you can see the solution is fairly easy. Keep in mind that you need to be running the SQL Server locally on the vCenter server for this to work, especially for larger environments I wouldn’t advise running both on the same box. For SMB environments this should work just fine.

Increasing the time-out within vCenter for remote ESX hosts

· ·

One of my colleagues is deploying an enormous VI3 environment. The customer wanted to have 1 central management console for all ESX hosts of which most hosts are located in a satellite offices. (One central management system for more than 200 hosts remote) With a 1Gb or more link this shouldn’t be a problem, but this customer had 64Kb links between these satellite offices and head quarters. This means that most ESX hosts were displayed as “disconnected” most of the time. To avoid this a time-out value for vCenter was increased:

The ESX Host sends heartbeats every 10 seconds, VirtualCenter server has window of 20 seconds to receive it. If the UDP Heartbeat message is not received VirtualCenter server will treat ESX as not responding.

By increasing the timeout limit in VirtualCenter, it will show the ESX host as continuously “connected”.

  1. Edit C:/Documents and Settings/All Users/Application Data/VMware/VMware VirtualCenter/vpxd.cfg
  2. Add the following in the <vpxd> tags.
    <heartbeat>
    <notRespondingTimeout>60</notRespondingTimeout>
    </heartbeat>
  3. Restart VirtualCenter server service