This came up on Twitter Sunday, and having happened upon it in the past, I thought I’d share the solution that Ed Haletky (Blue Gears) and I came to. Basically it boils down to the service start order for the vCenter and related services. Specifically the order should be:

1. SQL (MS SQL, Oracle, etc)
2. ADAM (only when using linked mode)
3. vCenter Server
4. vCenter Server Update Manager

In our case the problem service was vCenter Server Update Manager. To correct it, follow this Microsoft KB article: http://support.microsoft.com/kb/193888 to set the service dependency. Hope this was helpful.

I had been meaning to give HyTrust some more love. After winning the Best of Show & Gold award at VMworld 2009, it is more than worth checking out.

(Note: I generally try to shy away from writing “promo” type posts and the like, however I strongly believe in HyTrust, and what they provide in the way of security for your virtualizaiton environment. I should also note here… that this is not a paid review, nor was it prompted by the HyTrust folks in any way.)

What is HyTrust

From the HyTrust site:

The HyTrust™ offers a centralized, single-point-of-control for virtual infrastructure access, policy management, security configuration, and compliance. By combining the same control mechanisms of the physical world into a comprehensive solution for virtual infrastructure, HyTrust cost-effectively enables virtual infrastructure to achieve the same level of operational readiness as that of physical infrastructure.

Essentially, the HyTrust appliance functions as an intelligent proxy of sorts for all commands going into and out of your VMware environment:

Basically it allows you to filter all of your multitude of connections (SSH, API, vSphere Client, etc) through a single proxy that allows for fine grained control of actions against the infrastructure. It also provides a method for logging access centrally, that can cover both vCenter, the vSphere client, and any direct host manipulation (ssh, etc). In other words, it gives you one spot to look when you have an incident, rather than piecing together logs from multiple sources.

How do I try it? (Community Edition)

Well, while all of the above is fine and dandy, if you’re anything like me, you will want to kick the virtual tires in a lab setup. To do this, HyTrust provides a free Community Edition. The community edition will protect up to three hosts (great for the vSphere starter editions!), and can be downloaded after signing up at the HyTrust site. As the Community Edition is offered as a vApp, installation is a snap, download and deploy.

There are some configuration tasks to be taken care of afterwards, but… they are covered in the “installation” pdf (just below the download of the Community Edition). For a PDF, it’s quite good, and covers the basic “Demo” setup, as well as tying it to Microsoft Active Directory, including setting the permissions it requires

I strongly encourage you to go forth and give it a go.

I recently got a comment on a post I had done a while back on VMware tools and Time Sync. While the one-liners there may be useful, they don’t particularly explain how they got to the end results. With that in mind, today I hope to explain some of the logic used when you need to find particular properties of an object. To that end we’ll use the example proposed on the post:

Can you tell me how can I find out the poweroff Vm and also when it is poweroff and by whom with powershell script.
I know how to get the poweroff vm, but not able to get the other details.
If possible can you put your comments on this.

Power Off tasks for a VM. Well, where do we normally find those in the vSphere client?

Turns out it’s listed under Tasks & Events for that VM:

This gives us an idea about the information we’re looking for, as well as provides us a place to start looking. Let’s dip into the PowerCLI:

[vSphere PowerCLI] C:\> $vm = Get-VM | where { $_.Name -eq "Wiki" }

What this does is set the variable $vm to the object that represents our VM. What is an object? For our use an object is anything in your Virtual Infrastructure, and the properties and methods that belong to it. Take a turtle for example (yes… turtle, hang with me). That turtle will have some properties: breed, gender, length, weight, etc. For a VM these properties are quite numerous:

[vSphere PowerCLI] C:\> $vm | fl *

PowerState          : PoweredOff
Description         :
Guest               : VMware.VimAutomation.Client20.VMGuestImpl
NumCpu              : 1
MemoryMB            : 256
CDDrives            : {CD/DVD Drive 1}
FloppyDrives        : {Floppy drive 1}
HardDisks           : {Hard disk 1}
NetworkAdapters     : {Network adapter 1}
Host                : 192.168.15.253
HostId              : HostSystem-host-26
HARestartPriority   :
HAIsolationResponse :
DrsAutomationLevel  :
CustomFields        : {}
Id                  : VirtualMachine-vm-47
Name                : wiki

What we did there was take our $vm object, and expand out a list (using short hand for Format-List) of all properties (using * ). Quite a few properties, no? None are exactly what we need, however, so lets dig a bit deeper. As the information we’re looking for is an Event, we need to pipe, or pass our $vm object to the Get-VIEvent cmdlet:

[vSphere PowerCLI] C:\> $vm | Get-VIEvent | select -First 1 | fl *

info                 : VimApi.TaskInfo
key                  : 2177
chainId              : 2177
createdTime          : 10/12/2009 10:09:35 AM
userName             : NERV\cody.bunch
datacenter           : VimApi.DatacenterEventArgument
computeResource      : VimApi.ComputeResourceEventArgument
host                 : VimApi.HostEventArgument
vm                   : VimApi.VmEventArgument
fullFormattedMessage : Task: Power Off virtual machine
dynamicType          :
dynamicProperty      :

Ok, this particular bit of output is doctored. Why? The list of events for a give VM is huge, and this provides us with the information we’re looking for

Looking at the output we see that there are several properties of interest here, the time the VM was powered down, the user who initiated the task, and of course the message notification. Let’s put these all together to answer the original question:

[vSphere PowerCLI] C:\> $vm | Get-VIEvent | where { $_.fullFormattedMessage -like "Task: Power off*" } | select createdTime, userName, fullFormattedMessage

createdTime                userName                   fullFormattedMessage
———–                ——–                   ——————–
10/12/2009 10:09:35 AM     NERV\cody.bunch            Task: Power Off virtua…

Hope this was helpful. If you’ve any questions or comments, drop a line in the comments section.

I just received my copy of Steve Jin’s “VMware VI and vSphere SDK: Managing the VMware Infrastructure and vSphere ”,

As I tech edited the book I’ll not post a long review, other than to say that the book is a good resource, and overall a good book. If you are, or will be programming using the VI or vSphere SDK’s, you’ll want to start here.

From Amazon:

Jin walks you through using the VI SDK and cloud-computing vSphere SDK to manage ESX servers, ESX clusters, and VirtualCenter servers in any environment–no matter how complex. Drawing on his extensive expertise working with VMware strategic partners and enterprise customers, he places the VI SDK in practical context, presenting realistic samples and proven best practices for building robust, effective solutions. Jin demonstrates how to manage every facet of a VMware environment, including inventory, host systems, virtual machines (VMs), snapshots, VMotion, clusters, resource pools, networking, storage, data stores, events, alarms, users, security, licenses, and scheduled tasks.

Now that I have you at attention, let us take this time to talk of things. Important things. The things your parents never told you about VMFS. First let us start with some definitions, each of these will be taken in the context of VMware Virtualization using ESX/vSphere, and VMFS, but you knew that, didn’t you? We’ll work from there to the “When & Why”.  Sound like a plan? I think so!

(Note: This post brought to you by Twitter! Special thanks to @rogerlund)

Definitions

Extent

The VMware Resource Guide for vSphere has this to say about extents: “An extent is a partition on a LUN. You can add a new extent to any existing VMFS datastore. The datastore can stretch over multiple extents, up to 32.” Pretty simple, no? I’ll spare you additional explanation then.

Growing

Also from the resource guide is this gem on Growing: “Grow an extent in an existing VMFS datastore. Only extents with free space immediately after them are expandable. As a result, rather than adding the new extent, you can grow the existing extent so that it fills the available adjacent capacity.”

Read another way, if your SAN supports LUN resizing, you can grow the VMFS volume (much like using diskpart in Windows Server). So now that we’re clear on the what part (you are clear, right?), we can move to discussing which one to use and when.

When & Why

Extents

To clarify, in VI3 (ESX 3.5 with vCenter 2.5) extents were your only option for expanding a datastore. What this means is that in VI3, if you needed to expand your datastore, this was how you did it. Period. This will also be the only way to go if your SAN does not support LUN resizing. Even if it does, you can’t just resize the SAN LUN while the volume is live. This causes you to call VMware support in a hurry.

This changes in vSphere 4 (ESX 4 with vCenter 4, etc), but that does not mean extents are not useful. When would you use one? The first case jumps right out at me from the definition, you’d use an extent when you can not grow the datastore, as the extent does not have any adjacent capacity that is free. This may happen when you’ve carved out another LUN for another VM or other server, and are otherwise unable to let the LUN & Extent grow into this space. Mind you, there may be some methods at the SAN level to move these around, however, there may be other constraints in your environment that prevent this, division or responsibility, etc.

Growing

When do you grow a datastore? Well, as stated above, you can only do this in vSphere 4. Growing VMFS comes into play when you have otherwise filled your VMFS volume and cannot risk a storage VMotion (the snapshot for this is stored on the host), and cannot afford the downtime that happens with a “Cold Migration”.  Growing gives you an option above and beyond adding an extent, which has historically been ‘interesting’ (Just search for ‘VMFS extents’ on Google & the VMware forums).

How

Well, I could discuss the “How” for each of these here, and fill more lines on the screen, but that would both annoy you, and put me in the awkward position of trying to cover material that some much smarter folks have already covered. So to that end, @DuncanYB gives you a how-to on growth on his Yellow-Bricks blog. The extent part is spelt out about three comments down in this VMware communities post.

Doesn’t that title bring back 1996. I can almost feel the texture of the hard plastic shell of the 3.5 inch disk AOL would mass mail me. Useless little things in today’s world aren’t they? Really, with USB disks, iso files and the like, when was the last time you needed one? They are still useful however, at least a .flp image is. Let’s setup a little story… all things go better with a story. Get your milk and Oreos and get comfortable.

You’re a net admin. You’ve just virtualized EVERYTHING, or most of it anyways. You are heralded as the next great hero, that is until your security admin reminds you that all new “Servers” deployed, including VMs, must be hardened off the network. Great you think, lets use the same USB key you’ve used to deploy physical servers in the past! Except, ESX 3.5 does not support usb, and can’t pass it through to a VM. Well what now? It’s just 3 scripts…

In comes .flp to save the day. Using dd for Windows, or my favorite (but pay utility) WinImage.

After creating the image, drag your files in, and save. Upload to your datastore, attach to the VM, and go!

Questions? Comments? Story too long & otherwise useless? Leave me a note in the comments section.

There are now four, FOUR ATDG chapters available, HA ha ha!

http://www.vi3book.com/index.php/component/content/article/83

I can’t say this enough, but if Virtualization is the new Religion, this is it’s bible, and should be required reading all about.

No I’m not kidding either. Found this via Twitter last evening in fact. There is now a Twitter plugin for the VI client. Not sure how much use it is, but it shows how flexible the plugin stuff can really get. Go to the source and check it out yourself.

At least three of these, and laminate at least one. Really.

The VI Toolkit Quick Reference card by Virtual-Al is a perfect starter guide, and quick reference doc for those working with the VI Toolkit. Not only because I’ve got a line or two in it, but because it really is useful, take a look:

This is a perfect compliment to the VI3 Card

The VMware Networking Blog has posted a useful set of slides on troubleshooting VMware networking:

At VMworld last September, one of our engineering staff, Srinivas Neginhal, delivered a fabulous breakout session  on the topic of “VI3 Networking: Advanced Troubleshooting.” Srinivas squeezed a 79-slide deck into the available time—he could have easily doubled or tripled the session time given the enormous density of information in his deck

Go have a look!