• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • Unexplored Territory Podcast
  • HA Deepdive
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

Archives for February 2009

vCenter and SQL service dependencies

Duncan Epping · Feb 12, 2009 ·

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

Duncan Epping · Feb 11, 2009 ·

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

My statistics for January 2009…

Duncan Epping · Feb 11, 2009 ·

I was just checking my statistics for January and it’s gone up again and looking at february I will hit a major milestone possibly. Here are the stats for January 2009:

  • Daily Avg unique visits: 3103
  • Daily hits: 33.364
  • Monthly Total unique visits: 96.216
  • Monthy Total hits: 1.034.297

And so far this month I’ve already had 37.214 unique visits, with VMworld coming up I should be able to break 100.000 unique visitors.

Thanks everyone for contributing via comments / tips and thanks for reading!

Update: Meet the VMTN Experts, Dates & Time

Duncan Epping · Feb 11, 2009 ·

Okay, the dates and time have been set for the Meet the VMTN Experts session. We are still looking for an official name for the session but just write down these dates and times and be sure to be there:

Tuesday 24th – 13.00 – 14.00
Wednesday 25th – 13.00 – 14.00

Location: Community Lounge on the solution exchange

Who will be there:

Jason Boche – Boche.net + VMTN Moderator
Thomas Bryant – VMTN Moderator
Steve Beaver – thevirtualblackhole.com + VMTN Moderator
Eric Sloof – NTPro.nl + VMTN/VMUG Contributor
Scott Herold – VMGuru.com + VMTN Contributor and author of VMware ESX Server: Advanced Technical Design Guide
Wil van Antwerpen – vi-toolkit.com + VMTN Contributor
Gabrie van Zanten – gabesvirtualworld.com + VMTN Contributor
Alan Renouf – teckinfo.blogspot.com + VMTN Contributor
Tom Howarth – PlanetVM.net + VMTN Moderator
Duncan Epping – Yellow-Bricks.com + VMTN Moderator

Load Balancing your LUNs on Active/Active SANs?

Duncan Epping · Feb 10, 2009 ·

I really love the discussions going on in some of the blog postings. And some posts even trigger other bloggers to respond. Frank Denneman commented on my “Balancing LUN paths with Powershell” post and explained in short why load balancing your LUNs on some Active/Active SANs might not always lead to a performance increase. It even can lead to a performance decrease.

Frank was so kind to elaborate on why this exactly is some more on his own blog:

The arrays from the EVA family are AAA arrays. In an Asymmetric Active-Active both controllers are online and both can accept IO, but one controller is assigned as the preferred (owning) controller of the LUN. The owning controller can issue IO commands directly to the LUN. The non-owning controller, – or to make this text more legible – proxy controller can accept IO commands, but cannot communicate with the LUN. For example, if a read request reaches the array through the proxy controller, it will be forwarded to the owning controller of the LUN.

If the array detects in 60 minutes that at least 2/3 of the total read request to a LUN are proxy reads, ownership of the LUN is transitioned to the non-owning proxy controller. Making it the owning controller. Justin’s powershell script assigns the same path to every server the same way. This way the EVA should switch the managing controller within the hour. (If you have multiple ESX hosts run multiple VM’s on the LUN of course)

Now, you will probably say that this is just what should happen… But for LUNs replicated via HP’s Continuous Access this might be a problem. Go to Frank’s blog and read why…

I was just about to publish this article and noticed that Chad also wrote an article on this subject yesterday! Chad seems to be reading my mind.

An “Active/Passive” array using VMware’s definition would be a EMC CLARiiON, an HP EVA,NetApp FAS or LSI Engenio (rebranded as  several IBM midrange platforms).   These are usually called “Mid-range” arrays by the array vendors.   It’s notable that all the array vendors (including EMC) call these “Active/Active” – so we have a naming conflict (hey… “SRM” to storage people means “Storage Resource Management” – not “Site Recovery Manager” 🙂   They are “Active/Active” in the sense that historically each head can carry an active workload on both “brains” (storage processor), but not for a single LUN.   I say historically, because they can also support something called “ALUA”, or “Asymmetrix Logical Unit Access” – where LUNs that are “owned” by a storage processor can be access via ports from the other using an internal interconnect – each vendor’s implementation and internal interconnect varies.   This is moot for the topic of loadbalancing a given LUN with ESX 3.5, though, because until the next major release, ALUA is not supported.   I prefer to call this an “Active/Passive LUN ownership” array.  The other big standout is that these “midrange” Active/Passive arrays lose half their “brains”  (each vendor calls these something different) if one fails – so either you accept that and oversubscribe – accepting some performance degradation if you lose a brain (acceptable in many use cases), or use it to only 50% of it’s performance envelope.

Read Chad’s full article here cause there’s a lot of useful information in this post! Thanks Chad for clearing this up.

  • « Go to Previous Page
  • Page 1
  • Interim pages omitted …
  • Page 5
  • Page 6
  • Page 7
  • Page 8
  • Page 9
  • Page 10
  • Go to Next Page »

Primary Sidebar

About the Author

Duncan Epping is a Chief Technologist and Distinguished Engineering Architect at Broadcom. Besides writing on Yellow-Bricks, Duncan is the co-author of the vSAN Deep Dive and the vSphere Clustering Deep Dive book series. Duncan is also the host of the Unexplored Territory Podcast.

Follow Us

  • X
  • Spotify
  • RSS Feed
  • LinkedIn

Recommended Book(s)

Advertisements




Copyright Yellow-Bricks.com © 2025 · Log in