Mounting a Windows share on ESX is very easy with the smbmount command.

Before you start, create a directory where the share should be mounted. For instance, /mnt/tmp. Just issue the command:

mkdir /mnt/tmp

Then, use smbmount as follows (one line):

smbmount //<server>/<share> /mnt/tmp -o username=<domain>\\<user>,password=<password>

where

• <server>: name of the Windows server
• <share>: sharename on the server; you can also use c$, d$, ...
• <domain>: domain of the server or the servername if you use an account local to the server; note the double backslashes behind the domain or server name
• <user>: domain account or server account
• <password>: password of <user>

If you now go to /mnt/tmp, you should see the files that are in the share.

A couple of gotchas here:

• Make sure you allow outgoing SMB connections in the ESX firewall: command to do this is esxcfg-firewall --enableService smbClient
• Make sure that the Windows server does not have SMB signing policies. Even policies that state "if client agrees" should be disabled!

The last gotcha is usually causing the most trouble. When there are signing policies in effect, you will notice that mounting works perfectly. However, when you try to use the mount, you will get the error: stale NFS file handle.

Among other uses, smb mounts are handy to easily restore full vm VCB backups. After you mount the share where the backup files are located, you can use the vcbRestore command to restore the vm to your ESX box.

If your ESX box freezes after a SAN rescan with VI Client, check out this blog post.

We had this yesterday when we connected IBM DS8000 SAN luns to shiny new HP DL580 G4s.

In yesterday's post, I talked about esxRanger 3.0 and the integration of that product with VCB. Today, a colleague enabled VCB in a test environment we have running. The test environment consists of two ESX servers (DL580 G3) and just two 500GB luns from an HP EVA 5000.

To review the basics, VCB is a platform to facilitate taking backups of virtual machines. It provides a way to get to the virtual machine's disks using a fibre adapter in a Windows Server 2003 machine. Because of that, VCB needs to be installed on a physical machine running Windows Server 2003. VCB requires extra licensing and thus cost and is included in the Enterprise edition of VI3. You also need some scripts (integration scripts) that allow you to integrate VCB into your backup software. Our environment is using TSM (Tivoli Storage Manager) and scripts are provided to integrate with VCB. Basically, when you create a backup job, you run some pre and post-backup scripts to get the data onto the VCB server and to clean up afterwards. The big advantage of VCB is that it allows you to take a LAN-free backup of your virtual machines with no load on the ESX servers. Of course, it is only LAN free between the VCB and ESX server.

There are basically two types of VCB-based backups:

1. Full vm: each virtual machine file including all disks (vmdk files) are dumped to the VCB server so that your backup software can back them up
2. File mount: the virtual machine's volumes are mounted on the VCB server so that your backup software can get to the files in each volume

For a full vm backup, you need enough space on the VCB server to dump the complete contents of the virtual machine. For a file mount, you do not need any additional space.

So, in our test environment, a VCB server was setup with a single path to both our test luns. This is required as multipathing is not supported with VCB. VCB was installed, the TSM client was configured and the TSM integration scripts were installed as well.

You do not need to use your backup product and the integration scripts to test how VCB works because you can use the vcbmounter command line tool as well. This tool can be found (by default) in C:\Program Files\VMware\VMware Consolidated Backup Framework.

To create a snapshot of a full virtual machine, you can run vcbmounter with some command line options. For example:

vcbmounter -h <virtualcenterserver> -u <username> -p <password> -a ipaddr:<ip or name of vm> -r <a path you choose> -t fullvm -m san

This just creates a backup of a virtual machine with the ip address you specify behind ipaddr: to a path of your choice (-r). You need to specify the name of your VirtualCenter server and username and password because vcbmounter needs to send some instructions (such as create a snapshot) and also needs to get some information about which lun the vm uses.

Below you see a screenshot of vcbMounter's progress. I also specified another switch (-M 1) to export as a monolithic file instead of breaking up the vmdk in 2GB parts. The disk is compacted by default but not compressed.

I think it is clear from the above that you need enough disk space on the proxy to backup full virtual machines. The above backup took about 2 minutes. The vm had only 1 disk of 8GB and about 1,5GB of that disk was in use. Because this backup was compacted, you effectively only need 1,5GB of space on the proxy. If you would do this backup with vizioncore esxRanger 3.0, the file would be even smaller because they can also compress the data.

On the backup proxy, the saved files looked like this:

Instead of backing up the full vmdk, you can also mount the disk on the proxy so you can get to the files inside the virtual machine. Your backup software can then backup these files. To do a file mount, use the following command:

vcbmounter -h <virtualcenter> -u <username> -p <password> -a ipaddr:<ip or name of vm> -r <a path you choose> -t file -m san

The output of this command is:

The result in Windows looks like this:

This vm had only one volume (c:). In vcbMounter, I chose to mount the virtual machine's volumes under D:\Mount\XV401895-files. Under that folder, there were two subfolders: digits and letters. As you can see above, the letters subfolder contains a subfolder for each of the vm's volumes.

When you are done with the files in the mount point, don't forget to unmount the volumes. You do this with the following command:

vcbmounter -h <virtualcenter> -u <username> -p <password> -U <mount point>.

In the example above, my mount point is D:\Mount\XV401895. There is a file in this folder called umount.dat containing info needed to unmount the volumes.

In VirtualCenter, you will get some feedback from all the above operations in the recent tasks window:

It should be clear again that file mounts do not require any additional space on the proxy because nothing is copied to it. The virtual machine's disks are merely mounted on a Windows folder so they are there for the taking by your backup software.

Next steps for us are further testing with TSM and the integration scripts and also esxRanger 3.0.

I just attended a webinar hosted by vizioncore about their new esxRanger 3.0 and esxCharter 2.0. If you are into virtualization with VMware ESX, you should definitely check out their products.

The nice thing about esxRanger 3.0 is the integration with VMware's VCB platform. VCB as a platform provides services to get the vmdk off the ESX host using the fiber adapter of the VCB proxy (a separate physical box). Normally, when you integrate traditional backup products such as BackupExec or Tivoli Storage Manager, VCB creates a file on the proxy with a size equal to the vmdk and then dumps the vmdk data into this file. The backup software can then pick it up. What vizioncore is doing is intercepting the data as it is delivered by VCB and do their work such as compression and performing a differential backup. The advantage here is that you do not need as much storage and it is much faster.

VCB in itself does not provide restore options but esxRanger 3.0 does. It is just a matter of selecting a previous backup and specifying additional restore options. Note that the restore is done over the network, exactly because VCB does not provide a mechanism to get the backup to ESX using the fiber connection. This will probably become available in a later release of VCB although that is just my thought.

esxCharter 2.0 now works with VI3 and provides interesting performance views and reports of your entire VI3 environment (above what VirtualCenter 2.O provides). Useful reports include vmfs storage and vmdk files so you can get a nice overview of virtual machine storage. The new billback features allow you to calculate costs for virtual machines more easily to charge back for their use.

vizioncore also has a product called esxReplicator. Support for VI3 is supposedly coming Q1 2007. esxReplicator is interesting in scenarios where you want to provide something like a standby ESX server and you don't want to use features like SAN storage, HA etc... For example, a customer of ours is looking to use such a solution using two ESX Starter editions. ESX Starter only allows local storage so the virtual machines running on the primary ESX server could be replicated with esxReplicator to the backup ESX.

Of the new products, esxRanger 3.0 looks very promising because of the integration with VCB. You should compare the product with esXpress 3.0 before you make a decision. Both products work differently and both are still in beta.

Lots of things are moving in the ESX backup products space. We can only applaud that because backup is one the biggest headaches in a virtualization project, especially when you start virtualizing large workloads that handle lots of data.

Usually, VMotion works very well but today we got the following error after about 90% of the process:

A general system error occurred: Failed waiting for data. Error 16. Invalid argument

Oddly enough, this only happened for one virtual machine. We looked at the VirtualCenter logs in c:\windows\temp but did not really get any wiser. We then disabled and enabled VMotion on each host and that fixed it.