Yellow Bricks

by Duncan Epping

Archives for 2009

Changed block tracking?

· ·

I was reading Eric Siebert’s excellent article on Changed Block Tracking(CBT) and the article on Punching Cloud on this new feature which is part of vSphere. CBT enables incremental backups of full VMDKs. Something that isn’t covered is what the “block” part of Changed Block Tracking actually stands for.

Someone asked me on the VMTN Communities and it’s something I had not looked into yet. The question was around VMFS block sizes and the way it could potentially have its effect on the size of a backup which uses CBT. The assumption was made that CBT on a 1MB block size VMFS volume uses 1MB blocks and on an 8MB block size VMFS volume uses 8MB blocks. This is not the case.

So what’s the size of the block that CBT refers to? Good question I’ve asked around and the answer is that it’s not a specific size but it has a variable size. The block always starts with 64KB and the bigger the VMDK becomes the bigger the blocks become.

Just for the sake of it:

  • CBT is on a per VMDK level and not on a VMFS level.
  • CBT has variable block sizes which are dictated by the size of the VMDK.
  • CBT is a feature that lives within the VMKernel and not within VMFS.
  • CBT is a FS Filter as shown in the VMworld slide below

ESXi Lessons Learned 2 revised

· ·

I mentioned in ESXi Lessons Learned 2 that Jumbo Frames were not supported for the VMkernel. It seems that it’s a mistake in the ESXi Config Guide as mentioned in this blog article on the VMware ESXi Chronicles Blog. Charu already contacted me about it but we needed to wait to update you guys before we received the definitive green light.

Charu Chaubal:

I am happy to say that this is merely an error in the documentation.  In fact, ESXi 4.0 DOES support Jumbo Frames on VMkernel networking interfaces.  The correction will hopefully appear in a new release of the documentation, but in the meantime, go ahead and configure Jumbo frames for your ESXi 4.0 hosts.

Cool Tool Update: RVTools 2.7.3

· ·

Rob de Veij has just updated RVTools to version 2.7.3. This excellent tool now includes the following additional features and fixes:

Version 2.7.3 (December 19, 2009)

  • Files in .snapshot directories are no longer reported as zombies.
  • CTK files are no longer reported as zombies.
  • The problems with VM files which are placed in the root directory are now solved.
  • Under some condition the filter screen terminated with an exception. This is fixed now.
  • New fields on vDisk tab: ThinProvisioned and split.
  • New field on vTools tab: Virtual machine hardware version.

Read the full releasenotes/documentation here. And make sure to get this new version, in my opinion this is one of the most valuable tools out there.

Where should you get SRA’s from?

· ·

I received Michael White’s(VMware BCDR Specialist SE) weekly newsletter over the weekend and the following is a question I also receive on a regular basis so why not blog it?!

I had a disagreement with a friend about where to get SRA’s from. He was under the impression that we didn’t have the arrays in our premises for all of the SRA’s on the market and so it was OK to take an SRA from a vendor as they could test it.  The fact is we do have most, or all of  the arrays for each SRA in-house but that is actually not relevant.  It is important to only take SRA’s from the VMware web site for a different reason.  When a vendor finishes updating or writing an SRA, it is run against a special program that produces a log.  The SRA and log are sent to VMware and we check them out.  Sometimes they are sent back for improving or fixes.  This continues until the SRA passes and then it is posted on our web site.  If you took the SRA from the vendor you may accidentally get an SRA that in a week or a month we might decline and send back to be fixed.  So please, make sure you get the only safe copy of an SRA available, and that is from our web site!