Archive for the 'vmfs-tools' Category

The last release of vmfs-tools (0.2.1) was almost 2 years ago. It was about time to bring some of the changes that have been available in the git repository in an official tarball. So here it is.

It brings some limited VMFS 5 support and experimental extent removal, as well as some deep changes to the debugvmfs tool and various fixes.

Next release (0.2.6) will have a fixed fsck, which, while it still won't fix file system inconsistencies, should at least report actual inconsistencies (which is far from being true currently). I won't give any estimation as to when this will happen, though.

Today I added an initial VMFS 5 support to vmfs-tools. For the most part, VMFS 5 is VMFS 3, so these should just work as before, and adds new features; but this initial support is very limited:

• Unified 1MB File Block Size - Nothing has been changed here, so file size is still limited to 256 GB with 1MB File Block Size.
• Large Single Extent Volumes - This is not supported yet. So the 2TB extent limitation still exists.
• Smaller Sub-Block - This actually doesn't change anything to the on-disk format, but is only really the tuning of an existing value in the format. This should be handled out of the box by vmfs-tools.
• Small File Support - VMFS 5 now stores files smaller than 1KB in the inode itself instead of allocating a Sub-Block. Support for this has been added on master.
• Increased File Count - Like smaller Sub-Blocks, this was supported by the on-disk format, and the change is only about tuning, so this should just work out of the box.

On related news, while the git repository here is kept alive, I also pushed it to github. The main reason I did so is the Issue tracker.

Update: It turns out the small file support makes the vmfs-tools crash when accessing files bigger than 256GB, because the assumption made when reverse engineering was wrong and clashes with how files bigger than 256GB are implemented. It also turns out large single extent volumes may be working already because it looks like it was only about tuning an existing value, like smaller sub-block and increased file count.

Update 2: Latest master now supports small files without crashing with files bigger than 256GB.

Until vSphere 4, the only way to add space to an existing VMFS was to add an extent. This means creating a new partition, most of the time on a new LUN, and extend the VMFS there (vSphere 4 is now able to resize a partition on a grown LUN). This is somehow equivalent to adding a physical volume in a volume group under LVM. But contrary to LVM, once you added an extent to a VMFS, it is impossible to remove it.

Well, until now, it was.

I just pushed my lvm branch of vmfs-tools (get a git snapshot tarball), which includes a new tool named vmfs-lvm, allowing to just do that. For the moment, the tool is not cluster-safe, which means you'd better run it on an offline VMFS (i.e. make sure no server is using it). Data should not be at risk because the tool checks the removed extent doesn't contain any data, but it also assumes the filesystem is in a consistent state beforehand.

The command line to remove an extent looks like the following:

# vmfs-lvm extent0 extent1 ... extentn remove

This will remove the last extent.

Update: There was a bug when setting some values at volume level. The git snapshot link above has been updated accordingly.

This release should have occurred much earlier, but I wanted to work on a test suite before. Seeing how that was not going to happen any soon, I decided to defer the test suite to 0.3.0 and released 0.2.0 today.

It adds a basic support for MBR-style partition tables as they are usually found on VMFS containing LUNs (i.e. a single 0xfb typed partition), a basic fsck tool which only does a few checks and no corrections, and a better debugvmfs shell (but still with the same commands, which ought to change in 0.3.0). It also supports loading a multiple extents VMFS with missing ones (except the first one, which contains everything).

This new release has also been tested to build and work on FreeBSD 7.2, Opensolaris 2009.06 and Cygwin 1.5.25.

I'm currently looking for a (very) fast way to (more or less reliably) checksum multi-gigabyte filesystem images (namely VMFS), to validate that my somehow compressed image files, once expanded, are still accurate to what the original image used to be. One of the main features of the image files is that they are sparse files, so you'd get bonus points with checksum algorithms that allow fast addition of a huge amount of zeroes.

So far, I've considered Adler-32, Fletcher-32, though I'm unsure how they would accurately detect the kind of bogus output I could get, and also "md5 of md5" or "sha-1 of sha-1" (i.e. calculate the md5 or sha-1 sum of the concatenation of the md5 or sha-1 sums of blocks of some size, where you can pre-calculate the md5 or sha-1 sums for blocks full of zeroes).

Dear lazyweb, do you have any better ideas, before I start looking more seriously at the ideas above?

Apart from having been on vacation under the sun, I've been busy working with a friend of mine on something we called vmfs-tools, which is partly why there is still no part 2 to the previous post.

In case you don't know, VMFS is a clustered filesystem designed to store virtual machine disks for VMware ESX or ESXi Server hosts. Our ultimate goal is to give read-write access to these filesystems from some other host, for maintenance tasks such as, e.g. backup.

Files within the VMFS file systems can be accessed either from a CLI tool, or through a FUSE filesystem.

For the moment, only read support is available, and some known issues are still to be fixed, as well as a revamp of a part of the internal API.

The (quite sparse) homepage for this project is hosted here.

A Debian package is also sitting in NEW.