The Sydney vForum runs from 19-20 October at the Sydney Exhibition and Convention Centre.  This will be my third year attending this show, which is one of the largest VMware events in the Asia Pacific region.  VMware will offer the same hands-on labs to the Sydney vForum attendees that they offered to VMworld attendees.  So EMC decided to add a small set of our own labs at the EMC booth.

Like VMware, we will be running our labs from a cloud hosted in a US-based datacenter.  Also like VMware, these are the exact same labs that VMworld attendees enjoyed in Las Vegas.  While VMware will have a large, dedicated room to accommodate 60 concurrent lab sessions, we are choosing to run a miniature version of this in limited space in the exhibition center.  We will probably be offering about six concurrent lab sessions.

This is the very first time VMware or EMC have offered hands-on labs in an Asia Pacific event.  It represents a great commitment to offer the same high quality technical content to Asia Pacific that the US and Europe have enjoyed for years.  These labs are a significant technical challenge and this delivery is a first.  So, this effort is not without risk.  But one thing I know about the Australia VMware community is that it is not risk averse.

I will be at vForum in October presenting, helping with labs, and working the EMC booth.  I hope to see you there!

VMware has taken a PostgreSQL database on Linux and packaged it as a self-service virtual appliance. They improved upon the traditional database by optimizing the software for virtualization and adding VMware-aware memory management.  And VMware has simplified the deployment model by eliminating operating system and database configuration. Now databases can be configured and deployed with the simplicity of a few drop-down boxes.

This new database-as-a-service (DBaaS) model will allow VMware’s customers to remove administrators from the repetitive process of building database virtual machines. Because vDD uses the self-service provisioning model as vCloud Director, VMware’s admins can allow their database-hungry developers and database administrators (DBAs) to provision their own databases. And this occurs in the same process-driven framework that private clouds consumers expect.

I expect many people in the industry to ask, “Wait…did VMware just announce their intent to compete with Oracle and Microsoft SQL?!?”.

Let me answer simply: No.

VMware can no more expect to take Oracle’s market share in databases than Oracle can expect to take VMware’s in virtualization.

However, I know from years of experience that virtualized databases have multiplied throughout the enterprise faster than rabbits in the summertime. And the great majority of these databases are lightly loaded, barely used instances that consume precious administrator hours. VMware will allow these swarms of light databases, mostly owned during development activities, to be created, monitored, and decommissioned as easily as Gmail account.

I cannot wait to see vDD as it reaches the market.  The high end of database deployments should remain undisrupted.  But the lives of thousands of VMware administrators dealing with millions of database virtual machines are about to get a lot better.

In addition to a wealth of partner and customer meetings, I will be attending a large number of sessions, taking the hands-on labs, meeting old friends and colleagues, and of course enjoying the nighttime fun.  One great point of pride I have is the wide range of labs that EMC will be offering at the EMC booth on the showroom floor.  I thought I would share some highlights of hands-on demos you can take if you stop by the EMC booth at VMworld this year.

Below is an unedited copy of a write-up EMC’s Dave Henry distributed on one of our internal vSpecialist mailing lists.  I am including Dave’s extensive write-up unchanged.  But before I do I want to call out a few demos that I think everyone should check out.

My recommendations for top demos at the EMC booth:

1. VPLEX.  EMC’s highly available storage federation product is always the most electrifying topic in my customer presentations.  Go see how to manage the product at this demo.
2. Avamar.  The tight VMware integration is only part of the reason the Avamar backup message instantly resonates with customers.
3. VSI.  EMC has come such a long way from what I saw at VMware five years ago.  Now virtualization has worked its way into EMC’s DNA and the virtual storage integrator (VSI) is a small (and free!) example of how committed we are to improving the EMC/VMware interlock.

Of course there are many more demos that you will get a kick out of.  And for those of you that will not be at VMworld, rest assured that EMC is going to be putting these labs in a worldwide demo cloud that we hope to have setup in Asia Pacific before too long.  Talk to your local vSpecialist if you are interested in trying these out locally.

Dave Henry’s full article begins now.

The VMware Hands-on Lab is traditionally one of the most popular draws at VMworld, and this year will be no exception.  You’ll have a chance to get hands-on with the latest VMware products and solutions (like all the amazing new stuff in vSphere 5…) and run through them at your own pace.  There will be over 20 different Lab topics you can choose from.

EMC has some joint solutions featured in the VMware Hands-on Lab that you’ll be able to test-drive.  If you’re interested in learning details about what went into creating and powering those labs, two of the vSpecialists responsible for putting them together (Chris Horn (@Horn_Chris) and Simon Seagrave (@Kiwi_Si)) are hosting a session on exactly that topic at the conference — Session LAS4014, EMC Partner Hands-on Lab Design, Development, and Implementation at 14:30 on Wednesday.

EMC Interactive Demo Area

In addition to our participation in the VMworld Hands-on Lab, we’ll have a booth on the Solutions Exchange floor housing an EMC Interactive Demo Area.  This will be in Booth #1001, directly across the aisle from the EMC main show floor booth.

Come to this booth to get the chance to test drive EMC solutions for VMware at your own pace.  See our integration with VMware for yourself.  You’ll have your choice of which labs you want to take, including:

Atmos

In this vLab you’ll configure object-oriented, extremely flexible Atmos cloud storage to create automated turn-key Storage as a Service (SaaS) solutions.

Avamar

Backup built for VMware can reduce your backup window by 90% and backup storage by 95% all while giving you flexible restore options –- individual files within the Guest OS or full VMs.  Take Avamar for a test-drive in this vLab to see its backup and recovery capabilities.

Isilon

This vLab demonstrates the creation of multi-Petabyte filesystems that store millions of files using Isilon’s scale-out storage capabilities.

RSA Archer

This vLab will let you see a full enterprise Governance, Risk, and Compliance (eGRC) solution set up to protect a VMware environment.

Unified Infrastructure Manager (UIM) 2.1

In this Unified Infrastructure Manager (UIM 2.1) vLab, you’ll experience the full capabilities of UIM and see for yourself how easy it is to use as the provisioning tool for VCE Vblock infrastructure packages.

VAAI

The vStorage APIs for Array integration (VAAI) allow vSphere servers to offload specific storage operations to supported disk arrays for unparalleled performance and efficiencies.  In this VAAI vLab you’ll provision your own VAAI-enabled storage and see for yourself the benefits it brings to tasks such as cloning VMs.

Virtual Storage Integrator (VSI) Plug-in for VMware vCenter

In this vLab you will see how performing day-to-day EMC storage- and vSphere-related tasks using the EMC VSI plug-in can be completed quickly and easily from within the VMware vSphere Client interface.  Whether you want to provision new storage, save valuable disk space by compressing a VM or datastore, gain a detailed view of the underlying physical storage, or spin up extra VMs using the Fast Cloning functionality, the EMC VSI plug-in helps you achieve all this via a few clicks of the mouse within the vSphere Client.

VMAX

In this Symmetrix-focused vLab you will get the opportunity to practice using the latest features of the most-recent Symmetrix software (Enginuity 5875) on actual live Symmetrix equipment.

VNX

The VNX Unisphere vLab is designed to familiarize you with the new VNX Unisphere management interface and some of the key features it offers. In addition, this vLab provides a series of activities designed to demonstrate how easy it is to provision NFS storage for VMware.

VNXe

The EMC VNXe series redefines networked storage for the small business to small enterprise user, delivering an unequaled combination of features, simplicity, and efficiency.  This vLab focuses on the VNXe Unisphere Interface and management of the VNXe product.

VPLEX

In this vLab you’ll use the VPLEX Management Console to create Distributed Devices and then configure an ESX server access to them. The purpose of the vLab is to familiarize the user with VPLEX and to show the speed and ease with which a system administrator can create and provision storage to ESX Servers using VPLEX technology.

The EMC Interactive Demo Area will be open during all the hours the Solutions Exchange is open:

• Monday – 17:00 – 19:30
• Tuesday – 9:30 – 17:30
• Wednesday – 9:00 – 16:00
• Thursday – 10:00 – 14:00

Stop by and get hands-on with EMC.

Because some of the details are key to a proprietary technology, at my friend’s request I will omit some of the low-level details. Furthermore, VMware shared with me their intentions for future versions of vSphere that I cannot talk futures. Talk to your VMware representative under NDA and he can fill in the details on future products and their expected release dates.

Now that the boilerplate disclaimer is out of the way, let’s continue.

Regardless of virtual disk type–thick, thin, linked clone, whatever– from the guest operating system’s perspective it’s disk is a “normal” direct attached storage (DAS) disk. Operating systems play some tricks with this contiguous empty space and sometimes are just lazy about file placement. In the “tricks” category OSes will often place critical files near the disk’s edge to benefit from the faster read rates at the platter’s periphery. In the “lazy” category OSes will place new files in the first large unused space that is available. I learned this from my friend Bob Nolan at PerfectDisk (Raxco) during our joint work on guest defragmentation over a year ago. This lazy placement produces fragmented files and free space, both of which harm performance.

The point of this discussion on tricks and laziness is that file placement from the perspective of an OS user is arbitrary. But from the perspective of a vSphere administrator looking at a linked clone the result are minimally sized files. A curious admin will then ask: how does the mapping from the guest’s view to the VMDK work?

VMware has built above VMFS a management layer engineering calls the delta disk. (This is the same name used for snapshots’ delta disk files.) It is at the delta disk layer that guest IOs are mapped to the VMDKs on the VMFS volume. This mapping happens a very granular level. The delta disk tracks IOs that are small enough to avoid internal fragmentation for every IO size.

The benefit of this mapping process is that all IOs from the guest–no matter how logically distant they are from each other–can be placed contiguously in a VMDK. This is very good for storage efficiency. The downside is that the additional layer of indirection can increase latency for IOs. At its worse, one IO in the guest could result in many IOs at VMFS. The first to read the metadata contains the guest-to-VMDK mapping and then possibly many IOs to collect the data that may be spread throughout the VMDKs.

VMFS has for a long time buffered for linked clone metadata. This reduces the need to fetch metadata before every linked clone IO. Note that this is not the same thing as host-based file buffering, which has never been present in any version of ESX.

The fun thing about talking to VMware engineering is you learn all the amazing things they are working on in future releases. The bad thing about being a blogger is that I know all about these things but am prohibited from sharing them here. But for those of you with an NDA with VMware I recommend you buy your system engineer a beer and ask him to tell you about where VMware is going with VMFS. Linked clones are incredibly important to VMware’s strategy with end user computing (nee VDI) and VMware has some righteous plans for continued innovation with linked clones and a future version of VMFS.

And if you don’t have an NDA with VMware or access to a system engineer that can talk you through this stuff, try to attend VMworld this year in Las Vegas. I have no doubt that VMware’s engineering teams will be previewing all of these technologies if they have not already released them.

First, a little background on ESX’s storage queues.  There are two relevant queues in ESX.  First is the device queue, which has one instantiation at each HBA for each LUN.  Second is the kernel queue, which handles “overflowed” IOs that are waiting to be placed in a full device queue.

For Fibre Channel HBAs, the device queue’s default length is 32 commands.  It is much larger for iSCSI. No HBA, and thus no device queue, exists for NFS.  A 32 command queue is capable of opening 32 commands at a time.  Obviously, if you double this queue length then the queue will drive twice as many IOs to the volume.  For the rest of this article I will discuss queues in terms of the 32 element Fibre Channel queue.

Because one device queue is instantiated at each HBA for each LUN, a storage reconfiguration at an array can change the number of queues at an ESX host.  Increasing the number of queues increases the total number of IOs that the host can open against the array.  I demonstrated this in my VMworld presentation with the following figure.

Putting two VMs on two volumes results in up to 64 commands being opened from the pair of them at one time.

This figure shows the simple difference between two virtual machines sharing a single VMFS volume and two that each get their own.  In the first configuration, only 32 commands can be opened from the host and that single queue is shared between the virtual machines.  In the second configuration, the host can open up 64 total commands and each virtual machine can open up to 32.

Your first reaction to this might be, “Wow! I should put every VMDK on a VMFS volume of its own!  Then imagine the total throughput that the host could drive!!”  My first response to this is stop using so many exclamation points.  Nobody likes an overenthusiastic writer.  But second, you should consider that more is not always better.  In fact, I can think of several reasons why you should not reconfigure storage to multiply the number of queues:

1. Allowing a host to open many commands simultaneously may be good for the individual virtual machines but is likely to be dangerous for the shared infrastructure.  This could result in short but extremely intense microbursts of IO that could present challenges to your fabric or storage processors.
2. The device driver (and the HBA) can only open a fixed number of commands depending on the device’s implementation.  You have to use these sparingly.
3. The configuration that results in more queues necessarily requires more VMFS volumes which results in a greater administration cost.

In addition to reconfiguring storage to increase the number of device queues, you always have the option of increasing the length of ESX’s device queues.  This is documented on page 71 of the Fibre Channel SAN Configuration Guide.  But I will caution you from reconfiguring storage queues, too.  This requires manual changes at every host, produces longer queues that more quickly eat into the fixed number of commands each HBA can support, and increases the possible IO intensity every virtual machine on the host.

And if these detailed explanations are insufficient at explaining why storage queue manipulation is unproductive or even counterproductive towards your goal of optimizing your infrastructure, let me point out that VMware has years of experience at consolidating storage and they chose 32 commands per queue as the right number for most environments.  Trust their experience on this one.

Of course I would be remiss if I did not mention that there are rare times that a storage reconfiguration may help performance.  Redistributing virtual machines across different VMFS volumes or increasing queue depths can correct some issues.  And you can identify occasions where this change may help by a large kernel latency.

As I mentioned above, commands that are waiting for access to a full device queue reside in the kernel queue until a device queue slot becomes available.  On the whole, commands should only spend a fraction of a millisecond in the kernel queue on their way to the device queue.  A kernel queuing time of over one millisecond and certainly over two milliseconds suggests the virtual machines are not having their IO needs served fast enough.

You can see kernel queueing times in the kernel latency statistic reported in esxtop (counter: KAVG) and vCenter (counter: Kernel Latency).  When these latencies consistently average any whole number in milliseconds its time to investigate storage.  But know that slow storage can result in high kernel queuing times.  So, before you go manipulating queues, or reconfiguring your storage layout, make sure your storage is serving IOs in periods deemed acceptible by the storage teams (usually 5-10 ms).

This is kind of a long article by vPivot standards, I know.  But cut me some slack.  Chad Sakac bangs out footnotes and parenthetical digressions that are longer than this entry.  This content has already been covered in my VMworld presentations so if you have access to those recordings go listen to Kaushik and I present it there.  But for those of you that were unable to attend I wanted to present this important guidance for your consideration.

The claim that Paul Maritz and Steve Herrod made on stage (twice) is that virtual machines now host more than 50% of the world’s x86 applications. That means that more operating systems are now communicating with hypervisors than physical hardware. The claim is backed by data from IDC, which I recently saw summarized by a VMware presenter at an event in the Philippines:

Sometime in 2009, the number of x86 virtual machines passed the number of x86 servers not running a hypervisor.

Paul hinted at the incredible implications of this change. It is no longer the traditional operating systems that are driving the future of hardware development. We should expect even more virtualization optimizations and improvements from every part of x86 servers.

VMware is obviously claiming the lion’s share of the virtualization market. While I do not have exact numbers, I take them to own 95% of virtualized x86 servers. The import of this is that VMware may now have more control over the future of hardware development than Microsoft.

I asked about nine questions of the forum’s attendees and four of them generated rich discussion.  There were about 25 people in attendance, which were self-selected to have both opinions and total comfort sharing them.  Here are the questions, the results, and my commentary.

Question: What do you think is the state of performance of VMware vSphere 4.1?

Answer options:

1. I am not concerned about performance in any of my virtualized applications
2. I am concerned about performance in a very small number (<2%) of my applications
3. I do not think that vSphere can perform well enough for my big databases
4. I virtualize IT applications, but fear the virtual performance of my lines of business applications
5. I fear performance in general, and only virtualize after rigorous testing

The results:

My perspective on VMware performance is that it is sufficient to virtualize all but about 0.1% of application instances in today’s enterprise since vSphere 4, nevertheless vSphere 4.1.  This means a theoretical penetration of 99.9% for VMware’s hypervisor.  It is clear from these results that VMware’s customers do not yet believe VMware is so close to ubiquitous virtualization.  But often when I dig into performance objections the root of concern is dated results on older hardware and experiences on previous versions of VMware’s products.  My mantra to those of you that remain skeptical of what VMware can do with your big applications is “give it another try”.

Question: How do you feel VMware vSphere 4.1 performance compares against the competition?

Answer options:

1. vSphere 4.1 is generally much better than competing hypervisors
2. vSphere 4.1 is sometimes better and other times similarly performing to competing hypervisors
3. vSphere 4.1 performance is equivalent to other hypervisors, sometimes winning and sometimes losing
4. vSphere 4.1 is consistently slower than at least one other hypervisor
5. Who cares?  I am not making a purchasing decision based on performance anyway

The results:

A few times in my years at VMware I directly engaged in competitive debate on the relative merits of VMware’s products.  But my position on the need of direct competitive comparison has mellowed recently.  I much prefer to put my company’s products in their best light and let our customers decide if its merits outweigh those of our competitors.  But I am always fascinated by the public perception of our work, even when evaluated at a conference largely composed of enthusiasts.

The large portion of respondents that believe vSphere in a dominant position with respect to performance will extol the incredible pace of innovation coming from Palo Alto.  And the sizable portion of attendees that consider most hypervisors at performance parity with each other will surely site all products’ heavy reliance on hardware assist.  I believe that both of these perspectives are true.  When ESX is “dumbed down” to be feature equivalent to another product (by doing something like removing the balloon driver or turning off memory compression) it is possible for a less mature product to deliver comparable performance.  But it is because of the barrage of features included in each launch that VMware can generate more work per server than its competition.

Question: Which of the following represents the most important performance accomplishment in the past three years?

Answer options:

1. The ESX scheduler’s continual improvement
2. Improved hardware assist in the CPU
3. A better vSphere IO stack, including the paravirtualized SCSI device
4. Paravirtualization of the operating system (including Windows enlightenments)
5. Other

The results:

Intel and AMD’s dedication to improving the efficiency of virtual computing environments cannot be overstated.  But it is often lost in that discussion that VMware put tremendous engineering effort to making good use of these features, including rebuilding a scheduler to leverage Hyper-threading more aggressively than ever before.

From my perspective the most important improvement in VMware’s history was the storage stack optimizations that came with vSphere 4.  It took those improvements before one could seriously consider running intense, business-critical, IO-bound applications in a virtual environment.  But now you can.  Storage performance is not longer a problem.  Case closed on this, believe me.

Question: What is the coolest performance feature added to vSphere 4.1?

Answer options:

1. Memory compression
2. Storage IO control (SIOC)
3. Network IO control (NetIOC)
4. Faster vMotion, with more concurrent vMotions
5. Other

The results:

I was glad to see how popular the new vMotion is in vSphere 4.1.  I was surprised that many people took note of this improvement.  But very glad.

I am not surprised that Storage IO Control (SIOC) figures prominently with customers of new features.  Given that storage causes so many performance problems, VMware clearly has a lot of customers that want help correcting them.

My erstwhile colleague and VMworld co-presenter, Kaushik “K-ban” Banerjee, votes strongly for Network IO Control (NetIOC) as the more important addition to the vSphere 4.1 arsenal.  Kaushik argues that 10 Gb networking is exploding in IT and that application performance management on it is very difficult without bandwidth prioritization.  One attendee of the Copenhagen group discussion agreed with K-ban in principle but claimed that 10 Gb networks were not yet prevalent enough to demand the presence of NetIOC.  If this is so, then we can thank VMware for having the foresight to correct a problem before it is widespread.

I hope to soon receive the results from the VMworld in Copenhagen.  When I do I will certainly post a follow-up blog.  The sample size is relative small as a portion of VMware’s US and EMEA business but it could be fun to draw some generalizations from each region’s responses.

For EA7726 – Virtual Machines Outperforming Physical Machines – Crossing the Performance Barrier, VMware’s Dave Korsunsky and I provide a survey of the performance history of VMware and the applications that have defied expectations.  This session highlights the characteristics of applications that inhibit scalability and the improvements in hardware and software that have allowed the circumvention of scalability limits.  We scored 4.46 out of 5 (conference average 3.93) so this was a well-received presentation.

In TA7171 – Performance Best Practices for vSphere VMware’s Kaushik Banerjee and I reprise this perennial favorite at VMworld.  I presented this topic at both previous VMworld Europe shows and Kaushik’s broader performance engineering team presented it in the US shows.  We scored a 4.47 out of 5 (conference average 3.93) for which I entirely credit VMware engineering’s fantastic research.  Unfortunately the projector was not online for the first 20 minute so we filled time with an early, extended Q&A.  I am sure the same problem will not be repeated in Copenhagen.

The 1-on-1 events allow you to schedule a 15 minute meeting with me to discuss anything you want.  I have only been scheduled to two 1-on-1 hourlong sessions which means no more than eight people will be able to get a slot.

The Group Discussion was this year’s best addition to the show.  In this forum the organizers have provided an interactive survey that drives group discussion and questions.  I have preloaded the survey with some of the hottest topics in VMware performance but you are encouraged to ask any question you want to hear my thoughts as well as those of your industry peers.

See you at VMworld Europe 2010!

A perfunctory bit of guidance I include in nearly all of my performance talks (such as the enthralling, entertaining, and cancer-curing* presentations from VMworld 2010 that I will repeat in Copenhagen from 12-14 October) is “follow your application best practices”.  Audiences usually nod and immediately forget because this recommendation we all know to be correct yet somehow ignore.  In that way it is like, “stay away from fatty foods”, “do not drink wine with pain killers”, or “pay attention during the flight attendants’ presentation”.

Part of the reason why people forget this nugget is because advice is general, and not crystalized in a technological explanation that embeds deep in the minds of the audience.  In this case the application best practice that should be followed is to separate data from logs, putting the data on something good for random read performance (like RAID 5) and the logs on something good for sequential write performance (RAID 10).  Obviously I want everyone to consolidate their storage to VMFS and enjoy the technology, but if you are putting VMDKs that contain each of these files on the same volume, you are ignoring application best practices.

In this case I recommend building two VMFS volumes.  One backed by RAID 5 and the other by RAID 10.  Put the data on RAID 5, the logs on RAID 10.  While you will change the access profile at the array by putting multiple log files on the same RAID 10 backed LUN, the resultant IO will be much more sequential write than had you mixed data file reads among them.  So, consolidate multiple data files onto the same RAID 5 LUN and consolidate multiple log files on the same RAID 10 LUN.

Furthermore, if you are using solid state auto-tiering to manage your volumes, you do not need to protect your database log file with this technology.  What I am talking about here is EMC’s Fully Automated Storage Tiering (FAST), which is the most popular thing EMC has created since I have been paying attention.  Despite what some people will tell you, solid state disks are the cheapest way to serve huge amounts of random reads.  But their benefits diminish when the profile is sequential write when they become unattractive from a cost perspective.

EMC’s FAST works by creating a volume that is like a vertical stripe of multiple RAID groups.  LUNs, which become VMFS volumes, are then placed in that FAST volume.  Since FAST is a great technology for solid state disks, RAID 5 is the most cost efficient configuration for database data, and solid state is wasted on sequential IO such as redo logs, my best practice for virtual storage configuration for databases workloads when FAST may be present can be boiled down to the following rules:

• Always create RAID 5 volumes for your read-intensive database data.
• Always create RAID 10 volumes for your database logs.  If you have write-intensive data, you may consider putting them here, too.
• If you have FAST, use it to stripe across multiple RAID 5 volumes of different disk types and put your random, read-intensive data on VMFS on this volume.

The last bullet is clearly the most important here. I really love FAST, and it seems that EMC’s customers are crazy for it.  But its not the technology you need for sequential write workloads like redo logs.  Separate those data onto their own “normal” (not FAST-backed) VMFS volumes that use no SSDs.  Then you will have the best of all worlds: optimally deployed disk technologies, application best practice compliance, and righteous virtualized database consolidation.

(*) The claims made by the author of this blog do not reflect the views of his employer, the conference organizers, the government of the Kingdom of Denmark, or reality, for that matter.

• Monday, 30 Aug, 3:00-4:00PM: EXPERTS – 02 – Knowledge Experts One on One (Moscone West – Level 2)
• Tuesday, 31 Aug, 11:00AM-12:00PM: EA7726 – Virtual Machines Outperforming Physical Machines (Moscone South Room 307)
• Tuesday, 31 Aug, 2:00-3:00PM: TA7171 – Performance Best Practices for vSphere (Moscone South Room 104)
• Wednesday, 1 Sep, 12:00-1:00PM: EXPERTS – 08 – Knowledge Experts One on One (Moscone West – Level 2)
• Wednesday, 1 Sep, 3:00-4:00PM: EA7726 – Virtual Machines Outperforming Physical Machines (Moscone South Room 308)
• Thursday, 2 Sep, 12:00-1:00PM: GD 35 – Performance with Scott Drummonds (Moscone West Alcove 2)
• Thursday, 2 Sep, 1:30-2:30PM: TA7171 – Performance Best Practices for vSphere (Moscone South Room 302)
• Thursday, 2 Sep, 2:30PM-1:00AM: XX1234 – Post Conference Celebration (Various Bars in SF)

The registrations for the performance best practices talk are insane!  1100 people have already signed up for the talk and we are positively thrilled and humbled at the interest.  I know that you will not be disappointed with this year’s talk, because I am bringing a secret weapon.

This year, VMware’s head of outbound engineering will be leading the session.  Kaushik Banerjee has been at the helm of the outbound group since before I joined the company (Jan. 2007).  Every time I talked, blog, tweeted, wrote, or presented performance information Kaushik was behind me doing the research and providing the technical credibility.  It was his team that did the research for the Exchange 16K, 100K IOPS, 365K IOPS, DRS, and SPECweb announcements, among dozens of other white papers and blogs.  It is my pleasure to be able to share the stage with him next week.

On top of that, my good friend and former colleague Dave Korsunsky has asked me to co-present with him on the other topic, “Virtual Machines Outperforming Physical Machines”.  Dave and I co-presented the record-breaking “16,000 Exchange Mailboxes” talk at VMworld Europe 2008 (the data for which Kaushik gathered).  Dave’s expertise as a manager in VMware’s alliances organization goes beyond performance and he has worked on dozens of applications on a wide variety of configurations over the years.  I am again lucky to be invited to join him on stage.

As you can see it is going to be a fun show, and I am looking forward to it.  I’ll be on Twitter and trying to keep up with email so let me know if our paths will cross.