Remember to upgrade Virtualbox Guest Additions when you upgrade Virtualbox!

If you’re wondering why you might not be getting access to your shared folders in your guest OS after upgrading Virtualbox, this could be the reason. Virtualbox Guest Additionals (like VMware tools for Virtualbox) might need to be upgraded as well.

You can expect a system error 53, network path not found if the Guest Additions is not installed. When in the UI, it will say something like this: “Windows cannot access \\vboxsvr error code: 0x80070035 The network path was not found.”

Hope this help!

ovftool …

OVF is an open-standard for VM distribution. OVF has a number of important benefits, like encapsulating the entire VM in a single file, storing metadata, support for multi-VM configurations, disk compression, and platform independence. VC 2.5 also allows the VI client to import an OVF image from a URL and download it and install it automatically over the
internet.

In order to create an OVF image, you can use the OVF tool that VMware provides to convert an existing VM into an OVF image.

You can get more information about OVF from:
http://www.vmware.com/appliances/learn/ovf.html

docs here:
http://www.vmware.com/pdf/ovf_tool.pdf

You can download the OVF tool from:
http://www.vmware.com/download/eula/ovf_eula.html

In terms of building and packaging the VA, a good starting point is the VA build page: http://www.vmware.com/appliances/build/how.html. I suggest you also take a look at the VA best practices doc (http://www.vmware.com/files/pdf/vam_best_practices_building.pdf), which covers issues about how to package and distribute virtual appliances. A few key suggestions from the paper including using virtual SCSI (and not IDE) drives, disconnecting virtual CDROMs, floppies, etc, and installing VMware tools. If you follow the best practice guidelines, you can request to certify the virtual appliance as well. Those guidelines are at http://www.vmware.com/appliances/build/list.html. I suggest you read and follow the best practices paper whether you plan to certify or not, as it will allow maximum portability for your virtual appliance.

VCB integration

Introduction

This document explains how to use the VCB scripts installed on the proxy as part of the VCB installation to integrate with a backup application.

How VCB Works

VMware Consolidated Backup is a technology that allows users to backup a full image or certain files of a virtual machine while it is running, affording you business continuity and zero downtime. (Currently, file level backups are only available on Windows filesystems.) In order to do this, we leverage VMware’s snapshot technology. In essence, on the backend, the snapshot technology redirects disk I/O from the original vmdk to a delta file so that it frees the lock on the original vmdk and all new writes to disk go onto a new delta file. With the original vmdk free, you can use it read-only and backup your data. (You can only access it read only because since the VM is running, there will be reads from time to time from the original vmdk if necessary from the running VM itself. Your backup will not be the sole user of the vmdk file.)

The instructions for creating the integration are very simple in most cases and only get complex if the default settings won’t work for a given application. Generally, the default settings will work if backup software supports to following features:
1) Relocatable root for backups
2) Ability to associate data with arbitrary hostnames
3) Support for DNS hostnames

If these conditions are not met, there may be a need to customize the VCB scripts.

A VCB backup sequence consists of 7 parts:
1) Optionally quiesce the VM
2) Snapshot the VM
3) Unquiesce the VM (if quiesced)
4) Mount the VMDK
5) Run the backup
6) Unmount the VMDK
7) Remove the snapshot

Backup Vendor Integration Options

The backup vendor has a couple possible integration points: quiesce scripts and/or backup integration. A specific vendor could do either or both. However, without the backup integration, the customer will need some other backup solution.

For quiesce scripts, the backup vendor could provide the scripts needed in steps 1 and 3 to quiesce and unquiesce the applications. This is accomplished by providing scripts to the users and then installing them inside the VM in the as the pre-freeze and post-thaw scripts described on pages 40-41 of the Virtual Machine Backup Guide or here:
http://pubs.vmware.com/vi301/backup/wwh … .4.22.html
Quiescing is important for the integrity of your data. If you don’t quiesce your applications, when you restore from backup, you will end up with the application in your VM as if it had powered down hard. VMware does a quiescing of the filesystem, so that a restore backup doesn’t require a chkdsk or fsck, but it doesn’t do quiescing for applications. Quiescing the applications allow you the opportunity to safely shutdown the applications or commit any logs to databases or do whatever your applications need to do. This way, you can avoid having to replay logs or recover from database logs when you restore. If you do shutdown the application, please note that you can unquiesce the VM immediately after the snapshot is created, so if you do need a window for this, the time should be fairly small. Most applications can be quiesced without being shutdown.

Backup integration is accomplished through the VCB proxy. The backup vendor’s client software is generally recommended to reside on the VCB proxy. This is typically the same or very similar to the client software that would reside on a non-VCB host being backed-up. There are a few hooks into the VCB framework to allow the backup software to mount and unmount the vmdk.

How to Integrate

In order to work with VCB, all a backup client has to do is run a VCB command to snapshot and mount the VM (literally a single command) run its own backup command on the VM disk image or file mount, and then unmount the VM (again a single command). There are some cases where changes to the standard backup client software might be needed, for instance if the backup system can not handle a relocated disk image or file mount by default.

While there are a number of ways to implement the VCB backup process, essentially you just want to create a wrapper around the backup executable to run the extra two commands. You can see examples of the wrappers in the Sample Integrations provided on the VMware website (http://www.vmware.com/download/vi/drivers_tools.html, go down to Consolidated Backup Integration Modules). For instance in the Legato Sample Integration, the wrapper script is called vcb-backup.wsf (which actually runs the main function in vcb-backup.js, where most of the code is). The vcb-backup.js script runs basically the same setup described below, then calls the Networker-specific save command as part of the RunSaveCmd() function, then performs the same cleanup as described below.

You can take a look at the other Sample Integrations to see some different ways of implementing this, though it may be easier to understand and implement something closer to the generic templates.

The generic template script accomplishes all the same steps of the backup integration, but provides a simple and easy to integrate way of creating the wrapper script. Using the generic templates, here’s what you actually need to do to write a VCB integration:

1) Create a directory named after your product under ‘C:\Program Files\VMware Consolidated Backup Framework
2) Copy the content of the generic directory into that directory
3) Make any modifications you need and create your VCB wrapper command in the directory.

Essentially, all you need in the wrapper script is a call to pre-command.wsf, a call to your vendor-specific save command, and a call to post-command.wsf.

In most cases that should be everything you need. If for some reason you need to do something more complex than what the templates let you do, here’s an explanation of how the templates work:

The template files are installed in ‘C:\Program Files\VMware Consolidated Backup Framework’ as part of the standard VCB install. The templates and APIs come from the ‘generic’ directory.
• The generic/glue.js contains API functions for calling the VCB framework (described in more detail below).
• The generic/utils.js scriptfile serves as a library of useful routines.
• The generic/pre-command.wsf file is a template for snapshotting and mounting a VM on the proxy.
• The generic/post-command.wsf scriptfile is a template for cleaning up after a backup.
• The config/config.js file is a user configuration file. The backup vendor should leave the file alone, though they may need to modify it for testing. The file sets some local variables like usernames and passwords that are needed for VCB to run.

The pre-command.wsf script expects 2 arguments, the ID number of the VM to backup (required) and the type of backup (optional and described below). A brief explanation of what the pre-command.wsf command does follows:

1) Loads up an environment from the standard configuration file ($VCBDIR/config/config.js)
1) Loads the API functions from utils.js and glue.js. It uses local copies in the specific integration directory, but you can also load the copies from the generic directory.
2) Makes a call to Util_InitializeConfigVars (part of util.js) to load up the default configuration variables and throw errors if any are not set correctly. Essentially this is verifying that the config.js file (which you already loaded) is correctly formatted and populated. In addition, it sets the Util_vcbPath to the path to the VCB install directory and sets the default mode (which is SAN).
3) Creates a VMInfo object defining the VM to be backed-up. This uses the VMid and the backup type from the command arguments. There is a third argument representing the path within the VM mount directory to be backed-up. This is not used by the template because we are assuming whole VM backups. The legal backup types are vcbBackupTypeUnknown (same as “unknown” on the command line), vcbBackupTypeFile (same as “file” on the command line), and vcbBackupTypeFullVM (same as “fullvm” on the command line).
4) Makes a snapshot of the VM specified and then mounts it using prepare for backup function from glue.js. It’s documented in the script and takes 3 arguments: the VMinfo object representing the VM being backedup, a Boolean representing whether you want VCB to take the snapshot for you, and a Boolean representing whether VCB should discard the snapshot when it is done. The Booleans are generally just some standard global variables documented in the code. It is best to use those. The actual implementation of this uses the vcbmounter command line. In rare cases, you may need to create a new js function to call it if you are trying to do something really unusual. The command syntax is: vcbmounter.exe -h -u -p -a {ipaddr: or name:} -r -t {fullvm,file} -m {mode}

Following the pre-command.wsf file, you would generally call your backup products save command from within the same wrapper file that called pre-command.wsf.

Following that, the post-command.wsf would be called. In the unlikely event you need to change its behavior; but it does the following:

1) Loads up an environment from the standard configuration file
($VCBDIR/config/config.js)
2) Loads the API functions from utils.js and glue.js. It uses local copies in the specific integration directory, but you can also load the copies from the generic directory.
3) Makes a call to Util_InitializeConfigVars (part of util.js) to load up the default configuration variables and throw errors if any are not set correctly. Essentially this is verifying that the config.js file (which you already loaded) is correctly formatted and populated. In addition, it sets the Util_vcbPath to the path to the VCB install directory and sets the default mode (which is SAN).
4) Makes a call to CleanUpAfterBackup (part of glue.js) with the location of the mount point of the VM as the only argument. CleanUpAfterBackup is an API to the command line ‘vcbmounter.exe -U’. If you need to do something crazy, you can access the command line directly using the syntax: vcbmounter.exe -h -u -p -U

Troubleshooting notes:

Hardware requirements: The VCB proxy will need network access to both, the VirtualCenter and ESX servers. It will also need to be presented the same LUNs (LUN numbers need to match) on the storage side that are presented to the ESX hosts (that you’re expecting to backup).

If the vcbMounter command doesn’t work, here are some steps you can go about troubleshooting. You can get additional debug information from the vcbMounter command by appending “-L 6” to end of the command.

If you’re having authentication issues, you can run:
vcbUtil -h -u -p -c ping

If it’s not finding the VM via the name or ip address, you can run:
vcbVmName -h -u -p -s any
This will list all VMs found on that VirtualCenter host. If you don’t have VMware Tools installed inside the guest OS, you will not be able to use ipaddr or name. With this output, you have the opportunity to use moref or uuid.

Looking at the log files will be helpful as well.

Some Log file locations on the VCB proxy server:
vmount service logs – C:\WINDOWS\Temp\vmware-vmount[*]–>vstor log files – C:\WINDOWS\Temp\vmware-vlun[*].log

You can find pre/post script log files under
C:\WINDOWS\Temp\ pre_.log
C:\WINDOWS\Temp\ post_.log
C:\WINDOWS\Temp\ browsestart_.log
C:\WINDOWS\Temp\ browseend_.log

3rd party backup Logs – C:\Documents and Settings\Administrator\Local Settings\Temp

Log files for VirtualCenter:
C:\WINDOWS\Temp\vpx\vpxd-*.log]]>

How to install VMware Tools in Trustix Secure Linux

How to install VMware Tools

This is taken from: http://www.trustix.net/wiki/index.php/VMwareTools

How to install VMware Tools

This has (so far) only been verified to work on VMware Workstation v5.5 and a TSL 3.0 installation with the following groups installed: “Minimal with SSH”, “Commonly used local utilities” and “Commonly used network utilities”; a typical, almost minimal, TSL system.

Required packages

You need the following packages installed on the system to get VMware Tools to compile the needed modules (other packages may be installed due to dependencies):

make
gcc
glibc-devel
kernel-source

All in one using swup:

swup --install make gcc kernel-source glibc-devel

n.b. –ignore-filter may be required on TSL 2.2 to allow kernel-source to be installed.

Configure kernel-source

VMware tools won’t compile if you have not configured and prepared the kernel-source.

  • The kernel-source installs itself in /usr/src/kernel-source-<version>. You should link this folder to /usr/src/linux:
cd /usr/src
ln -s kernel-source-<version> linux

We also need to copy the kernel config file into our kernel-source:

cp /boot/config-<version> /usr/src/linux/.config
  • Lets prepare the kernel-source for VMware Tools:
cd /usr/src/linux
make oldconfig
make modules_prepare

n.b. With TSL 2.2 use ‘make dep’ in place of ‘make modules_prepare’.

Install VMware Tools

Having your TSL 3.0 installation active, release the lock (CTRL+ALT) and go to the menu and choose:

VM -> Install VMware Tools..

Mount the virtual CD-ROM containing the VMware tools and install the rpm there. Then unmount it.

mount /mnt/cdrom
rpm -Uhv /mnt/cdrom/VMwareTools-<version>-i386.rpm
umount /mnt/cdrom

Compile and configure VMware modules for TSL

To finish the VMware Tools installation we run the VMware tools configure script and it will compile the VMware Tools modules:

vmware-config-tools.pl

Answer yes to all questions and all but the X Windows display driver is configured. See below for X Window driver support.

Optimized network driver – VMXnet

When TSL 3.0 was installed as guest OS it found and installed the pcnet32 driver. You could stick with it, but I would recommend you change it for the optimized vmxnet driver which was just compiled. The following instructions are displayed after vmware-config-tools.pl finish to help you replace the network driver:

service network stop
rmmod pcnet32
rmmod vxnet
vi /etc/modprobe.conf /etc/mkinitrd/modules <-- change vmnics to vmxnet
tsl-fixboot.sh --install <kernel-version>
depmod -a
modprobe vmxnet
service network start

X Window

You need the following packages installed to have the X Window driver compile (other packages may download and install due to dependencies):

xorg-x11
xorg-x11-devel

As always, you may install them all in one using swup:

swup --install xorg-x11 xorg-x11-devel

Now run vmware-config-tools.pl again to compile the svga driver:

vmware-config-tools.pl

NB! You may get a warning about not being able to compile the vmxnet driver. Just ignore that. You already have it installed if you followed the instructions above.

Please note, this will only give you a minimalistic xorg-x11 without gnome or another DE/WM. I would recommend you check out the Desktop Environment section to get a fully working and useful desktop.

If you get the error when compiling the tool: “The kernel defined by this directory of header files does not have the same address space size as your running kernel.”

The way I fixed it was just by using a newer version of VMware-tools. I used the source from ESX 3.0 and you can search on the web and you should be able to find it.