When I suggested CBT to the customer they asked, “Why that one?” and how it worked.  So I explained:  When we replicate from source to target, the first copy is a full copy of the data (the “seed” it is often called).  When we go to replicate the next time, we don’t want to replicate the whole thing again, just what has changed since the last time we replicated (often called a “differential”).  The replication software needs to determine what’s changed.  Prior to ESX 4, there was not a built in method to do this.  The software would have to find another method, such as compare snapshot information and determine which blocks are new.  That uses CPU cycles on the ESX hosts and takes time (differential mode in vReplicator takes  roughly 1 minute per GB of VM data).  On the other hand, CBT is a feature in ESX4 that tracks the block changes that have occurred since a point in time.  It does not keep a copy of the changed data in a separate location, just a log that the blocks in question have changed.  This is a huge help to backup and replication technologies who typically have to determine what has changed on the disks via their own methods.  Now, ESX can tell them directly what has changed and they can get right to copying those changed blocks.  This makes the overall replication and backup jobs much quicker.

Now for a few lessons learned in using it.  First, it requires hardware version 7 VM’s (HW7) and ESX4.  VM’s need to have their VMtools upgraded to the latest version and then you can upgrade the VMs to HW7 when they are powered off via right clicking them (this updates the virtual hardware presented to the VMs and will require another reboot in Windows after powering it on when the OS discovers the new virtual HW and loads the drivers – thanks Microsoft!).  Second, CBT it is not on by default.  It is set per VM and is an advanced option you can set in the VM’s config.  Some software have the capability to change the CBT setting for you.  In our case, vReplicator has this option on the CBT options page.  On that page, it will check every VM that it can see and if they are HW7.  If they are HW7, they will show as supported.  On that screen, you will also see a checkbox for the “enabled” field.  When you click the enabled box on your HW7 VMs, vReplicator makes the change for you in the VM’s configuration.  However, as mentioned earlier, you must completely power down that VM and power it back on.  The reason for this is that, to start using it, ESX needs to create the tracking log for each disk (the log is about .5MB for ever GB of VMDK or Virtual Mapped RDM and it’s stored with the VM) and ESX only does this setup process at VM boot time.  So make note, a restart won’t work.  It has to be a VM power down and VM power back on.  There is a great article that taught me a few things on CBT by Eric Siebert that goes into a little more technical detail and you can find it here.

Once we got this process completed, my customer’s replication jobs ran MUCH faster.  The data being copied from the source to the target was the same, but the time it took vReplicator to determine what to replicate went from minutes to seconds.  Great news too was that we were able to change the replication method on the fly (from Differential to CBT, if you’re using hybrid, I think you need to re-seed).

My final advice, is make sure you understand if your backup/replication software can use CBT and what you need to enable it.  It does take a bit of work to upgrade the tools and virtual hardware (use Update Manager!).  However it’s well worth it in the long run.

• VMware vSphere 4: Exchange Server on NFS, iSCSI, and Fibre Channel – a very nice paper on how NFS, iSCSI, and Fiber Channel performed running a very large number of mailboxes on Exchange.
• Performance Best Practices for VMware vSphere 4.0 – Absolutely a must-read for new administrators and a new addition for my Admin Bookmarks page .  This is also a great review for those looking to upgrade to vSphere.
• Using Local Disks in VMware View Deployment – A very interesting idea: in a remote office running local ESX servers, use a Storage Appliance to gain HA with local disks only for desktops running in View.
• VMware Fault Tolerance Recommendations and Considerations on VMware vSphere 4 – The defacto-standard read if you are planning to use FT in your enviornment.  This article is a keeper of all of the current ins-and-outs of FT.
• What’s New in VMware vSphere 4: Virtual Networking – a great reference for all of the new capabilities in networking in 4.0.  Very detailed and technical.
• What Is New in VMware vSphere 4: Storage – The complete list of everything that’s new from a storage perspective.  From thin-provisioning to Pluggable Storage Architecture, it’s all there.

Microsoft Exchange Server 2007 Performance on VMware vSphere^TM 4 <-Great reading for seeing how Exchange performs on ESX4.

Smart Card and Certificate Authentication in VMware View  <-If you need to use smart cards with VMware View this a must read

Repurposing a PC to a Thin Desktop Using VMware View <-a very common question from customers that want to extend the life of their PC a little longer.  Good reading on a few ideas on how to do so.

Network Segmentation in Virtualized Environments  <-Some good ideas if you need to seperate and firewall off sections of your infrastructure.

You can read all of the details in the white paper here .

You can find all of the details in the article here.

To find out all of the tips and tweaks of running SQL on ESX, better read the Best practices guidlines for running SQL on VMware .

Next up, virtualizing Exchange tips.

Intel has announced a sweet 8-core Nehelem-EX Xeon and it will be interesting how this will apply to ESX.  As mentioned, I don’t know how ESX will license on it but with the processors hitting the street this quarter , we won’t have to wait long to find out.

I will, of course, post additional information as soon as it becomes publically available.

There’s two new hi-level papers on why NetApp storage and VMware view run well together.  They bring up some good points on the advantages.  They can be found here and here .

There are some great ones on Application Virtualization.

• The first is a performance comparison of Application Virtualization technologies which can be found here .  I don’t know if it was a sponsored study or not but the results are compelling none the less.
• Next a great reviewer’s guide for ThinApp was posted.  This is a must have if you are going to download the ThinApp eval and try it out.  It gives you the basics of how ThinApp works and how to get started.

There’s also a new one on Best Practices running Java in a VM on ESX .  Here’s one that I definately get asked on periodically.  Very technical and good reading for those running Java in a VM.

Lastly, one question I get asked often is how many desktops a customer can stack on a ESX server.  That’s not a very easy question to answer as everyone’s workloads are different.  Here’s a great paper on some standard workloads and how they stack up and affect performance.  Definately a good read for those looking to deploy virtualized desktops.

By default, Virtual Center has set the statistics level to 1.  The levels can range from 1 to 4.  Level 4 maintains the most stats on your environment and is typically used for debugging.  I do however believe that there are a lot of benefits to increasing that level to 2 or 3.  For a great list of all of the performance counters that are available at each level, refer to this doc .  This change can be done on the fly with no impact to running VMs.  I cannot stress enough the value of the Database Sizer located at the bottom of the frame pictured.  Once you have changed the statistics to the levels you are comfortable with, before pressing OK, plug your VM and host values into the sizer so that you know you will have enough room in your database.  The last thing you want is to run out of room on your database server because of the expanded growth.

For specifics on the Keep For field, that really is how long the individual data points are kept or "rolled up".  The real time stats in the performance graphs are not archived and are kept for the past hour.  Past day stats take the real-time stats and roll them up so that there is 1 data point for every 5 minutes.  Thus, there are 12 data points per hour and 288 per day.  Past week stats take the past day stats and roll them up so that there is 1 data point for every 30 minutes.  Thus, there are 48 data points per day and 336 per week.  Past month stats take the past week stats and roll them up so there is 1 data point per 2 hours.  Thus, there are 12 data points per day and 360 per month (30-day month).  Past year stats take the past month stats and roll them up so there is 1 data point per day.  Thus, there are 365 data points per year.

For more information, take a look at the Basic Admin Guide for ESX 3.5 starting on page 286 or the Basic Admin Guide for 3.0.3 starting on page 274.

]]> http://vmguy.com/wordpress/index.php/archives/401/feed 0