So this is the game: Four full-line enterprise superpowers battling each other for datacenter dominance and coveting the extra profits of a few verticals. HP clearly believes they can chip away at EMC and Cisco in storage and networking; Dell and IBM have so far focused mainly on storage; and Oracle hasn’t made a move in either direction, instead challenging the other three in the core server and software space.

Right on, especially with the “coveting the extra profits” part. For years, Dell, IBM, and HP have been busy commoditizing the compute node side of things. They’ve been driving the prices down on CPU and RAM for so long that the margins aren’t there anymore. And now, with the onset of widespread virtualization, the volume is no longer there to make up for it. However, storage is still a high-margin endeavor, and probably the single most expensive thing in my data center; I have $400K in CPU & RAM connected to $2m in storage. It is not surprising that there is a huge bidding war for 3PAR, and an open season on data storage companies. It’s one of the best ways for big companies to continue bleeding IT budgets, at least until SSD capacities rise and prices fall, and it does to storage what virtualization is doing to servers.

The thing is, virtualization is all about driving costs down in IT, and I just don’t see these big consolidation efforts as an actual way to do that in the long term. EMC has been downright nasty with my organization because they thought we were locked in. Cisco has done the same, and Oracle is generally regarded a bunch of jerks. Why would anybody choose UCS, VBlocks, or an all-in-one option from Oracle knowing that you’re locking yourself in? Even if the pricing is competitive right now, it won’t be for the fourth or fifth year of support where they think they’ve got you trapped.

Stephen’s last paragraph speaks of rebel alliances:

Although I would love to see a rebel alliance rise (imagine Juniper, NetApp, and Symantec joining forces!) this is not a likely scenario.

Like Stephen, I would enjoy seeing a rebel alliance, but I doubt it is likely, for two reasons. One, companies like buying from a single source, because they can get support guarantees, the purchasing process is a lot easier. Second, consolidated efforts like UCS and Vblocks are about software as much as they are about hardware. The promise of a true single pane of glass is very appealing.

If you look at some of the rebels in the software world, like Automattic and Flickr, you’ll notice something: their openness. In both of these cases they allow customers to do whatever they want with their own data. Want to pick it up and leave? That’s fine by them. Contrary to the thinking behind the sales models of EMC and Cisco, though, those companies have great customer retention rates. Because the fundamental idea that their customers are free to choose colors everything they do, they spend their time looking to make customers happy, not lock them in. And as a result you get products people want to use, and not products that are just a little less evil than the other guy.

Seeing that a true rebel alliance is unlikely, I’d love to see Dell become the open, rebel alternative to companies like EMC, Cisco, and Oracle. Even going so far as to develop a “Dblock” based on open technology, sold in increments, delivered in 19″ racks, managed through a single pane of glass, and marketed as the antithesis to vendor lock in. A Dblock could have Dell servers in it, Equallogic/3PAR storage, and Xsigo interconnects (imagine an array full of SSD and quad-rate Infiniband connections), and be very compelling. Especially if their answer to a question like “Can I attach my NetApp to it?” was “the ports are on the top left.” I’d be happy to do business with a company like that.

It’d just need one little twist: a change in attitude.

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. Vendors Who Don’t Realize Virtualization Is Here To Stay
2. Why Am I Still Buying Physical Servers?
3. Storage VMotion GUI, Stepping Backwards

There are three fundamental decisions we made a long time ago that, had they not been made, would have drastically changed how virtualization has proceeded here.

1. Clearly defined maintenance windows.

Knowing exactly when someone can do maintenance on server has been crucial to getting things done in our virtualization environment. There are many adjustments you can & should make in virtual environments, but if you can’t ever take the VMs down to make the changes you’re stuck. We’ve been able to do physical to virtual migrations, performance tuning, VMware Tools upgrades, vSphere upgrades, and a whole slew of other things in relatively short timeframes because we have this all worked out already. This also lets us “right-size” our VMs — rather than deploying huge VMs just in case they need the CPU or RAM, we deploy smaller ones and then can take an outage to add CPUs and RAM if we need to. The maintenance windows for a server are negotiated between the application/service admins and the system administrators when a machine is put into production, we track it in our CMDB, and any member of the whole team supporting the service can take the maintenance window, as long as they follow some rules about notifications for the change (timeframes, etc.).

2. Use of load-balancing technologies.

We use application load balancers (layer 4 of the OSI model) to decouple services from individual servers. Not only does this allow us to take a host down without affecting a service, but it also lets us spread the load out more among the physical hosts we have in our virtual infrastructure. In a lot of cases having more, smaller VMs results in better workload scheduling by ESX and DRS, especially on smaller ESX hosts.

Of course, this also plays nicely into the other points, because it’s very liberating to be able to do what we call “rolling maintenance” on a service, just taking one machine down at a time so that customers are not impacted. It also means that system administrator quality of life goes up, for now we can do maintenance tasks during the day instead of on weekends and off-hours. Doing maintenance during business hours has a couple of benefits. First, it means that the maintenance will actually get done. If you try to use someone’s personal time to do work they tend to opt out of that work. Servers go unpatched, tuning doesn’t happen, lots of things that should get done don’t because people will choose their personal time over work. Second, it means that if something goes wrong there are others around to help out. Doing work at 5 AM on a Sunday is fun, but if things go sideways you have to wake someone up or try fixing it yourself. Doing work during the day means you have the rest of the team around to lend a hand.

Third, it gives you a way to make incremental changes and then watch the effects. This has been particularly awesome for performance tuning of applications and our virtual environments themselves. Testing tuning changes is often hard, because test suites and test load generators are synthetic and often don’t compare to real load. But because the load is spread out we can make a change to one VM, or one ESX host servicing one VM, and keep an eye on it. I’m not advocating being a complete cowboy — you still have to do testing — but the risks to your production environment are a lot lower if you can catch problems on one VM first.

There are usually some other benefits to load balancers, too, that make them virtualization-friendly. Many will offload SSL processing, so your VMs have less work to do. Others have features, like iRules in F5′s products, that let you rewrite network traffic on the fly, which has some really neat implications for security, monitoring, and service delivery. And if you don’t want to buy a piece of hardware you can often get a virtual appliance from these vendors, though the physical appliances are usually a lot faster.

3. Commitment to operating system and application patching.

It is a fundamental belief of mine that one of the best ways to stay secure is to keep up on your patching. My organization agrees, and by using load balancers and defining maintenance windows we’ve made it easy for ourselves to keep our hosts up to date with regular patching cycles. Because we can take servers down without taking services down, and because sysadmins know exactly when a server can come down, we can schedule maintenance cycles easily, whether it’s six months out or two weeks. We can also respond very rapidly to emergency situations, like recent remote execution vulnerabilities in Microsoft Windows, by rolling patches out to development & test hosts, then QA & production, over the course of just two days if needed.

Keeping up to date with patches not only keeps you secure, it also lets you take advantage of new features that are added to operating systems. For example, Red Hat keeps adding new virtualization-friendly features, like kernel interrupt clock dividers. Being a kernel parameter you can’t just change it on the fly. And if you have to reboot, but can’t get a time to do it, you won’t do it. For us, we just rolled the change into one of our patching cycles and reduced the load on our infrastructure dramatically. Meaning more VMs per physical host, and a quantifiable amount of savings from just a small change on each machine.

Furthermore, our commitment to patching also extends to the virtual infrastructure itself, and we have a rule that we will not implement anything that breaks vMotion or Storage vMotion. Why? Because then it becomes very difficult to cope with ESX updates, or hardware failures, or any situation where vMotion could be used to prevent an outage. Sure, this means that we still need physical hardware for some applications, but it’s still just a fraction of the hardware we were buying years ago. This also makes virtual infrastructure easy to upgrade when the time comes, for new versions of vSphere, new storage arrays, and new physical hosts. Instead of planning outages on hundreds of VMs we just vMotion them, and nobody is the wiser.

Disclosure: F5 is a sponsor of Gestalt IT Tech Field Day, of which I have been a participant. I am not a customer of F5 at this time, though.

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. How Much Capacity Should I Have For VMware?
2. Why This VMware Time Bomb Issue is a Big Deal
3. Leopard on ESX Would Be Nice

Entrants must explain how they plan to “pay it forward” if they get to go to VMworld. Will you start a blog? Write some tutorials? Contribute to a forum or online community? Present to your local VMUG? Get creative and spread the wealth of knowledge you get from the event!

Our panel of judges is made up of none other than the most-excellent roster of past Tech Field Day delegates! They’ve proven themselves to be independent-minded and knowledgeable, and we’re sure that they will pick the best entry!

I’ll be one of the judges — I’m looking forward to seeing some really great proposals! Go over to Gestalt IT for all the details.

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. Gestalt IT Tech Field Day Seattle
2. VMworld 2007
3. VMworld 2010 Call For Papers: Last Day!

So if you have 96 GB of VMs running you will use 96 GB of your disk as swap, even if those VMs are only actively using 2 GB of RAM.

Yet another argument against overcommitment, in my opinion. If you right-size your VMs you not only save RAM, but storage as well.

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. Terms of Use
2. License Changes
3. Creative Commons

First off, and slightly off-topic, I’m quoted in the article, and it’s always interesting to see what reporters choose for quotes from me. This isn’t a criticism, as anybody who has talked to me in real life knows I talk like that. Beth didn’t edit anything, which I really appreciate. However, I now can cross “use the word ‘cram’ in an interview” off my list of life goals. :)

Second, and back on-topic, per-VM licensing makes a lot of sense for things like AppSpeed, as well as some of the other management tools. There are a lot of VMs in my environments where I don’t need to know application latency, for example, and I’d rather not pay for for licenses for those VMs. I know just a little about Site Recovery Manager, but if this license model is similar that would be great for companies that don’t need to protect all of their VMs.

On the other hand, per-VM licensing for a tool like CapacityIQ is pretty sketchy, in my opinion. You are trying to use that tool to increase the number of VMs in your environment, which in turn increases your licensing fees. That’s counterproductive, and I can see how a number of potential licensees may be turned off by this change, at least specifically for CapacityIQ.

Changing a licensing model isn’t ever easy. A lot of IT shops are the least nimble business units you’ll ever see, and any change to anything evokes Chicken Little-esque comments, complete with falling skies. Certainly with a change like this comes a little more management overhead, because you have to manage two licensing schemes. But virtualization is about driving costs out of IT, plain and simple, and these changes are likely to outweigh the cost of staff time needed to cope with them. They’ll also open the door for some customers who were previously put off by the high prices. I think that’s a win.

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. Terms of Use
2. VMware License Server
3. You Want Nutrition? Eat Carrots.

Storage I/O Control:

This is a global, cluster-wide I/O scheduler, working to throttle I/O to ensure that a single VM cannot monopolize a single datastore’s capabilities. If you consider that a datastore’s backend storage can only sustain a certain numbers of IOPS it’s possible, and likely, that a single VM will consume a disproportionate amount of those IOPS. This feature lets you control which VMs get priority when there is congestion.

This is enabled per-datastore, and will kick in when latencies are 30 ms or greater by default, though you can adjust the latencies as you see fit via advanced settings. This feature is configured through VMware vCenter, but the ESX servers communicate between themselves via shared headers on each datastore. This preserves the ability for the cluster to continue to operate when the management interfaces are inoperative.

Storage I/O Control is only available to Enterprise Plus customers.

Network I/O Control:

As network connectivity on hosts moves from multiple 1 Gbps Ethernet links towards one or two 10 Gbps per host it becomes more important that network operations get prioritized, to avoid starving any particular operation. Network I/O Control does this by adding a few different features.

First, it implements the ability to schedule and prioritize traffic types. There are six types of traffic that are identified: VM, management, NFS, iSCSI, VMotion, and FT logging. You can assign limits to these types of traffic, to absolutely cap the amount of bandwidth being consumed by each. You can also assign shares to these types of traffic to designate the relative priority of that traffic. These limits and shares are always enacted on egress, meaning that it’s only outbound traffic that is throttled.

Second, a new feature called Load-Based Teaming has been implemented, to alter the physical NIC being used for a type of traffic when ESX detects that a link is more than 75% utilized over 30 seconds. This will be especially useful for 1 Gbps links, spreading the load across different links as utilization rises.

This technology only works as part of a vNetwork Distributed Switch, and as such is only part of Enterprise Plus licenses.

Memory Compression:

Memory overcommitment, while a hotly-debated topic at times, is a reality for a lot of people. Overcommitment is a gamble, though, and sometimes you end up with virtual machines that, in total, need more RAM than you have. vSphere 4 tried helping you out in three ways when you were caught short. First, it used transparent page sharing to try to deduplicate RAM. Second, it used the VMware Tools balloon driver to reduce the amount of RAM actively consumed by a VM. Third, it just paged to disk.

Paging to disk is a terribly slow operation. Disks operate thousands to millions of times slower than RAM  and CPUs, so VMware added another technology to stave off the need to page to disk: memory compression. ESX will take a configurable amount of memory and compress it. Of course, the optimal situation is to not need any of these technologies, but another way to avoid disk accesses is great.

Those of you having bad flashbacks to MS-DOS and RAM Doubler should consider that CPUs and RAM are much faster, this is configurable via the advanced settings on a per-VM basis, and that VMware says that decompression takes about 20 μs, which is still way faster than disk.

Memory compression is available to all licensed customers.

vMotion & EVC Improvements:

vMotion has had evolutionary improvements to it, to significantly decrease migration times. They do this through some behind-the-scenes improvements, as well as increasing the number of concurrent vMotions. You can now have 4 vMotions running simultaneously on a 1 Gbps link, and 8 on a 10 Gbps link. One datastore can also have 128 concurrent vMotions running on it.

Enhanced vMotion Compatibility (EVC) has also been updated to consider the CPU feature set of a running VM, rather than the features supported by the host. This allows for some better compatibility while moving VMs around, and better error detection when adding new hosts to clusters.

vMotion is also now officially spelled with a lowercase ‘v’ — whew! :)

vStorage API for Array Integration (VAAI):

Any old mainframe IT guy will look at all this new virtualization technology and make a snide remark that they had all this 25 years ago. In a lot of cases it’s true, especially when you consider coprocessors. While my iPhone has more CPU time than a mid-1990s mainframe, the mainframe didn’t actually have to use its CPU for much. Everything non-CPU was offloaded to coprocessors, especially I/O.

Continuing this trend among us naive open systems types, VMware and a variety of storage partners are working to enable offloading of storage operations to the arrays themselves, coprocessor-style. Initially there will be three operations handled by the arrays: full copy, zero-out, and locking. For operations like cloning this means that ESX won’t copy a template out over the SAN or network just to put it right back on the array. This is going to be a killer performance improvement for people using slower storage link, like iSCSI over 1 Gbps links. Likewise, the locking functions will help avoid locking the whole datastore for management operations. That will make datastores more scalable, as locking is a concern for big datastores.

Actual support on arrays is forthcoming, and vendors such as Dell, NetApp, IBM, Hitachi, HP, and EMC are actively working to release compatible array firmware. This feature is only available to Enterprise and Enterprise Plus licensees.

ESXi:

vSphere 4.1 is the last major release to support the classic ESX software with the service console. Future releases will be ESXi only, using APIs to control and configure the host, and people should consider moving towards ESXi. There is a nice “VMware ESX to ESXi Upgrade Center” to answer a lot of questions, and help smooth the transition.

ESX 4.1 really brings it up to the level that ESX has been at for a while. They have added boot-from-SAN capabilities, scripted installs, enhanced Update Manager to push drivers and other modules, added built-in Active Directory support, and now fully support both local and remote Tech Support Mode.

This will be a big change for a lot of people, and some thought and testing would be prudent for everybody, beginning now.

High Availability:

High Availability has had its limits increased, to 32 hosts, 320 VMs per host, and 3000 VMs per cluster. These limits are enforced after a failover, of course, so you still need to think about your cluster as N+1, and keep N under those limits. The concept/limit of 5 primary nodes still exists as it was.

Reporting of problems is much improved, via the new Cluster Operational Status window. It shows a better view of what is wrong, as determined by a new health check process. High Availability and DRS now work together to move resources to better help restart VMs after a failure.

High Availability now also has APIs for working with applications. This lets monitoring agents work with HA to do a variety of things, including a full guest restart. This works through the VMware Tools and involves guest to host communication, which may be a security concern in some cases. However, while VMware hasn’t said much so far it opens the door for some interesting monitoring and self-healing possibilities.

Fault Tolerance (FT):

Still no SMP support in FT — that’s a much harder problem than it seems because there’s hardware support for FT for single-CPU VMs, but none for SMP VMs. However, a lot of other restrictions have been lifted. DRS can now move FT VMs around, which is great. Having FT VMs locked to a specific host was terribly restricting. It requires having EVC enabled, but a lot of people are already doing that. You can also have ESX hosts at different versions.

Dynamic Resource Scheduling & Dynamic Power Management:

There is a new set of host affinity rules for DRS, that can give VMs affinity (or anti-affinity) for a set of hosts in a cluster. This helps a lot when someone is faced with host-based licensing restrictions, for instance. These rules can be set to preferred or required, and both DRS and HA will obey these rules.

DPM now has a set of scheduled tasks to help control it, turning it on and off at certain times of the day if you’d like. Disabling DPM will bring all the hosts out of standby, to help guarantee that no hosts get stuck in a useless state.

vCenter:

The changes to vCenter are really too numerous to list here. The biggest change is that it is 64-bit only, which will be a giant problem for a lot of people who are running 32-bit Windows. There are a lot of other incremental improvements, including a lot more information being presented to the users, often in conjunction with the new features throughout vSphere 4.1.

Whew. Get testing, people!

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. VMware vSphere 4 Update 2 Highlights
2. SLES For Free + vSphere 4.1 Information Leak
3. How Much Capacity Should I Have For VMware?

If you want to change the log retention policies, you can follow most of the instructions in KB 1004795 but there are two things I think you should know if you’re running on Windows 2008:

1. Your vpxd.cfg file and your logs are actually in:

C:\ProgramData\VMware\VMware VirtualCenter

2. The XML stanza for the logging is commented out in 4.0 Update 2, so remove the <!– and –> lines to make it work. For example, make:

...
  <logName>CpuFeatures</logName>
 </level>
 <!--
 <log>
   <maxFileNum>10</maxFileNum>
   <compressOnRoll>false</compressOnRoll>
   <level>info</level>
 </log>
 -->
 <vpxd>
    <das>
...

into:

...
   <logName>CpuFeatures</logName>
 </level>
 <log>
   <maxFileNum>100</maxFileNum>
   <compressOnRoll>true</compressOnRoll>
   <level>info</level>
 </log>
 <vpxd>
    <das>
...

You may also want to change the compressOnRoll to ‘true’ as I did above if you are concerned about disk space usage.

This may seem obvious to a lot of people, but for those that only occasionally make changes to vpxd.cfg it helps to have been pre-warned about the differences. At least you’ll vaguely remember that something’s changed… :)

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. Microsoft Windows Server 2008 SP2 & IPv6
2. VMware RCLI, Windows, and libxml2 errors
3. VMware ESX Server 3.0.2

If creating a SCSI virtual disk, it is recommended that you set the SCSI value to SCSI 1:0.

When you specify a SCSI Virtual Device Node the numbering scheme is Bus:ID, so what they’re really recommending by suggesting 1:0 is to let vSphere create another virtual SCSI controller. By default, that new SCSI controller will be set to “LSI Logic Parallel.”

What I’ve noticed, though, is that the VMware Data Recovery appliance has the pvscsi modules installed, so you can change the type of SCSI controller to “Paravirtual” and take advantage of the performance gains. Nothing is mentioned in the documentation, pro or con, but it’s been working for me under VDR 1.1 and now under VDR 1.2. I’ll certainly take the free performance boost, especially on an I/O intensive VM!

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. VMware & Linux Hot-Add Disks
2. VMware SRM Survey = $10 to UNICEF
3. elevator=noop

Over the last couple years my organization has been building out an alternate site, for disaster recovery and business continuity purposes. I’ve noticed a disturbing trend, both among my own coworkers and others who are starting to think about DR & BC: that by having multiple data centers, multiple servers, or using multiple cloud vendors they’ll reduce the number of problems they’ll have.

From a system administrator’s point of view that idea is absolutely false.

Every piece of equipment you have can fail, and the more equipment you possess the more likely a failure will be. The more servers, switches, chillers, PDUs, and power grids you have the more likely it will be that one dies. Heck, that’s even true of components within the servers. As I add more servers to my own environment, each with mirrored disks and tens of DIMMs, I spend more time replacing failed drives, failed DIMMs, updating firmware, etc.

Alternate data centers also add other problems than just mechanical failure. Your second data center is probably attached to a different power grid, so now you have two power utilities to worry about, and are subject to twice as many outages. You also have to maintain the equipment in that other data center, change the air filters on the air handlers, etc. And it isn’t twice as much work as having one data center, it’s three or four times when you count the overhead of traveling to a remote site, not having tools available, etc.

Having alternate sites, and multiple servers, can certainly improve application reliability by keeping services available to customers in case something happens. It’s a good bet that a power problem in San Jose won’t affect your site in Omaha, for example. But it absolutely increases your odds of having equipment failure, and while your customers might be happy your operations folks won’t be.

More equipment means more that can go wrong. So what do you do? Keep it simple. Have fewer, bigger machines. Have machines with fewer moving parts. Use a cloud provider with multiple sites. Use VMware DPM and keep your alternate site machines in standby most of the time, and the HVAC off. There are lots of ideas, but remember that the more you have, the more that will fail, and those failures mean time spent not moving forward.

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. Not Virtualizing Everything, or Know Your Dependencies
2. Complexity vs. Availability
3. Should I Convert My Old Servers to ESX?

- David Wheeler, though often attributed to Butler Lampson, who has some great quotes, too:

“When in doubt, use brute force.”
“In handling resources, strive to avoid disaster rather than to attain an optimum.”

Lots of good stuff if you read his “Hints for Computer System Design.”

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. Terms of Use
2. License Changes
3. Creative Commons

1. Enhancement of the esxtop/resxtop utility. esxtop & resxtop can now show you NFS datastore performance stats, as well as power statistics (via the ‘y’ key). Both are very welcome changes, but NFS stats are killer.

2. Speed and duplex settings for a NIC might not be retained after ESX/ESXi server reboots — fixed! Thank goodness. Similarly the Host Profiles feature now properly records NIC duplex & speed settings, which was annoying.

3. Added a network setup script to configure the network without using esxcfg-* commands. /usr/sbin/console-setup – sweet! I really hate when I have to fix a misconfigured console from the console using a million commands.

4. Removing all snapshots from a virtual machine with the Delete All option can use large amounts of disk space. Read the release notes for the long story, but the short story is that they changed which deltas they start consolidating first so that they reduce the amount of space used as well as the amount of copying. I love you, VMware (in a sort of human-corporation platonic way). This is huge!

5. For devices using the roundrobin PSP the value configured for the –iops option changes after ESX host reboot. Chad Sakac wrote about this back in December, now it’s fixed. I’ve been looking forward to messing with it in the search for better round-robin load balancing to my arrays.

6. ESX fails to boot after installation on a server with more than 190GB of physical memory. All the server hardware that I just ordered has 256 GB of RAM. Just-in-time bug fixes! :)

It also looks like there’s been a lot of work on the VMware Tools, which is a welcome thing for many people, too. My environment has had a rocky relationship with the Tools, and I’m hoping things will get a lot better now. Overall, looks like a worthwhile release to upgrade to, and I’m going to stick it in my test environment first thing tomorrow morning!

Links:

- VMware ESX 4.0 Update 2 Release Notes
- VMware vCenter Server 4.0 Update 2 Release Notes
- Chad Sakac/Virtual Geek: vSphere 4 NMP RR IOoperationsLimit Bug and Workaround

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. VI 3.5 Update 2 Hardware Status
2. Update Manager & Loss Of VMotion Capabilities
3. How to Cancel a Stuck VMware Tools Install from the ESX CLI

When you make a qualifying purchase of VMware vSphere, the industry’s leading virtualization platform, you will be entitled to receive SUSE Linux Enterprise Server (SLES) for VMware and a subscription to patches and updates at no additional cost (see terms and conditions below). By running SLES for VMware, you’ll also have the option to purchase technical support services for directly through VMware.

The list of eligible VMware SKUs is pretty long, you might want to check it out and see if you qualify, especially if you have been doing some upgrading lately to support 12-core CPUs. I am a Red Hat Enterprise Linux person, but I know a lot of people are really happy with SUSE, too, and it’s a great way to get licensed for it.

The “Terms and Conditions” section of that page is pretty interesting, though, too[0]:

VMware vSphere 4.1 will be generally available in 3Q2010. It will contain additional features and be provided at no additional charge to customers with active vSphere SnS contracts.

Additional features! :) Hehehe.

————————–

[0] Here’s to hoping I don’t get accused of violating any NDAs with this repost of public information. :)

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. Staff Time Isn’t Free
2. VMware vSphere 4.1: What’s New
3. VMware License Server

Holy buckets, I’ve been invited to be a 2010 VMware vExpert! Thanks to all that were involved in doing this, especially John Troyer and all the VMware Communities folks. I’m speechless[0], being in such wonderful company.

———————-

[0] Which is a feat, for those of you that know me.

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. Terms of Use
2. License Changes
3. Creative Commons

For example, if you have a set of datastores named with the prefix “netapp-” you can display the disk usage for all of the virtual machines in them with:

# du -s /vmfs/volumes/netapp-*/*
26214528        /vmfs/volumes/netapp-linux-1/vm-hr-1.company.com
40952192        /vmfs/volumes/netapp-linux-1/vm-payroll-2.company.com
49340800        /vmfs/volumes/netapp-linux-2/vm-payroll-1.company.com
48292224        /vmfs/volumes/netapp-linux-2/vm-hr-2.company.com
69263744        /vmfs/volumes/netapp-linux-3/vm-wiki.company.com

If you’d like the output with human-readable numbers, try using ‘-h’ with du:

# du -sh /vmfs/volumes/netapp-*/*
26G        /vmfs/volumes/netapp-linux-1/vm-hr-1.company.com
40G        /vmfs/volumes/netapp-linux-1/vm-payroll-2.company.com
48G        /vmfs/volumes/netapp-linux-2/vm-payroll-1.company.com
47G        /vmfs/volumes/netapp-linux-2/vm-hr-2.company.com
67G        /vmfs/volumes/netapp-linux-3/vm-wiki.company.com

Maybe you’d like to sort by VM name. Use the ‘sort’ command:

# du -s /vmfs/volumes/netapp-*/* | sort -k 5 -t '/'
26214528        /vmfs/volumes/netapp-linux-1/vm-hr-1.company.com
48292224        /vmfs/volumes/netapp-linux-2/vm-hr-2.company.com
40952192        /vmfs/volumes/netapp-linux-1/vm-payroll-2.company.com
49340800        /vmfs/volumes/netapp-linux-2/vm-payroll-1.company.com
69263744        /vmfs/volumes/netapp-linux-3/vm-wiki.company.com

The ‘-t’ parameter changes how sort detects fields, specifically that the field delimiter is a different character than a tab (\t). The -k parameter tells it what field to sort on. If you want to sort by space used, use the -n parameter, which tells it to treat the sort fields as numbers:

# du -s /vmfs/volumes/netapp-*/* | sort -n
26214528        /vmfs/volumes/netapp-linux-1/vm-hr-1.company.com
40952192        /vmfs/volumes/netapp-linux-1/vm-payroll-2.company.com
48292224        /vmfs/volumes/netapp-linux-2/vm-hr-2.company.com
49340800        /vmfs/volumes/netapp-linux-2/vm-payroll-1.company.com
69263744        /vmfs/volumes/netapp-linux-3/vm-wiki.company.com

Keep in mind that you’re seeing the disk space used by everything in that folder, including swap files (.vswp), snapshots, etc. Also keep in mind that this is only useful on ESX where you have a command line, so if you are running ESXi, or thinking about it, a PowerCLI or other API-based solution would probably be better. But for quick & dirty information this way is pretty handy.

Update: Dan in the comments does point out that ‘df’ is another utility that will show you your datastore usage. However, my intent was for per-VM breakdowns, and I updated my first sentence to reflect that. Use whatever tool does the job for you!

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. Abstraction is Your Friend
2. How File Deletions Work
3. That RAM Usage You’re Seeing? It’s Filesystem Cache.

1. VMware will gain some information about who is and isn’t using SRM, and how they are or aren’t using it. This is important, because surveys like this are how VMware product teams gather information about what customers want to see in upcoming releases. It’s also important if you aren’t using SRM, because it helps tell them that and why.

2. You’ll get a free PDF copy of Mike Laverick’s book “Administering VMware Site Recovery Manager 4.0.” The book is the only SRM book out there, and it’s $20 otherwise.

3. VMware will donate $10 to UNICEF. That’s pretty cool. UNICEF does good work all over the world.

I just filled out the survey, as an SRM non-user, and it took me about 2 minutes. You can spare 2 minutes, right? Go! :)

Update: I’m a tool and forgot to link the survey. Sorry.

This post written by Bob Plankers for The Lone Sysadmin. Unless otherwise noted it is © 2010 Bob Plankers and licensed under the Creative Commons BY-NC-SA 3.0 license.

Related Posts

1. Not Running VMware Capacity Planner as root on Linux
2. VMware Data Recovery & Paravirtualized SCSI
3. Rain Forecasted, From The Cloud, On Your Desk