I’ve written the following post as it took me a while to figure out how to get SLES Linux File based restore from within a VMDK on ESXi.
By default there is support for Debian Guest and RedHat, There is also a helpful article on the VMware forums that details implementation on OpenSuSE 32bit.
You can grab the VDR plugin from here:VMware VDR Plugin Download
This is where my first problem arose, as the VDR FLR programs require 32bit libraries in order to run. The way I approached this was to use a 32bit Guest VM as a donor for the 32bit linker programs, that dont seem to get included in the same way when installing the 32bit runtime environment on SLES 11 x86_64. All of the documentation on the OpenSuSE sites seem to point to declaring runtime variable settings for the linker and compiler by using “-m32” as an argument. Whilst this ‘Works” it fails to actually build the source objects that you require.
So I created a 32-bit guest and after a bit of debugging zipped down the /usr/i586-suse-linux directory and copied it over to and unzipped it on the 64-bit guest that I wanted to have VDR FLR running on. – This will give me a 32bit version of the linker program ‘ld’.
I also found that running on a kernel anything earlier than 126.96.36.199 failed to create the FUSE directories and files correctly under /tmp. So I ran a kernel update by grabbing these files from Novell’s SLES site:
For the following to run successfully you will need to update module-init-tools first:
rpm -Fvh mod-init*.rpm
//This will use these files to update the module-init-tools.
//Next do the kernel update online
move the following files into /usr/local/src/kernelmods
//Next run the update
rpm -Fvh *.rpm
Use YaST to make sure that you have installed the 32bit runtime environment. – Note that some of the steps we are doing after this is to get around a problem that I found with the 64bit linker not seeming to accept “-m32”.
Once this has finished, its best for you to do a reboot, just to make sure you are running everything that you should be.
Download VMware-vix-disklib from the VMware site. I used this version:VMware-vix-disklib-1.2.0-230216.i386.tar. Copy this to /usr/local/src and unpack and install by executing ./vmware-install.pl
Next follow the VDR instructions to get hold of the FLR program:VMwareRestoreClient.tgz. Copy this file to /usr/local/src on the 64bit guest, and unpack.
Next grab a source copy of FUSE from the FUSE site – I used 2.7.3. Here are the build instructions that worked for me:
./configure ‘–prefix=/usr/local/mattsfuse’ ‘–build=i386’ ‘CC=gcc -m32’ ‘LD=/usr/i586-suse-linux/bin/ld’ ‘AS=gcc -c -m32’ ‘LDFLAGS=-L/usr/local/mattsfuse/lib’ ‘–enable-threads=posix’ ‘–infodir=/usr/share/info’ ‘–mandir=/usr/share/man’ ‘–libdir=/usr/local/mattsfuse/lib’ ‘–libexecdir=/usr/local/mattsfuse/lib’ ‘–enable-languages=c,c++,objc,fortran,obj-c++,java,ada’ ‘–enable-checking=release’ ‘–with-gxx-include-dir=/usr/include/c++/4.1.2’ ‘–enable-ssp’ ‘–disable-libssp’ ‘–disable-libgcj’ ‘–with-slibdir=/usr/local/mattsfuse/lib’ ‘–with-system-zlib’ ‘–enable-__cxa_atexit’ ‘–enable-libstdcxx-allocator=new’ ‘–program-suffix=’ ‘–enable-version-specific-runtime-libs’ ‘–without-system-libunwind’ ‘–with-cpu=generic’ ‘–host=i586-suse-linux’ ‘build_alias=i386’ ‘host_alias=i586-suse-linux’ –cache-file=/dev/null –srcdir=.
As you can see in the configure script I specified an absolute path to the 32-bit linker (ld) ‘LD=/usr/i586-suse-linux/bin/ld’, and used –build=i386 and manually set some other 32bit flags to instruct the compiler on what to do.
Once the configure has run, issue a ‘make’ and ‘make install’ if there are no problems shown in the ‘make’.
You now have a 32-bit source version of FUSE running in on 64-bit SLES!
Almost there, all we need to do now is use ‘ldd’ to look at the VDR programs we need to run and see what libs it thinks are missing.
you should see something like this:
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib/libdl.so.2 (0xb7d72000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7d5c000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7d29000)
libz.so.1 => /lib/libz.so.1 (0xb7d17000)
libvixDiskLib.so.1 => not found
libfuse.so.2 => not found
libc.so.6 => /lib/libc.so.6 (0xb7bea000)
The items showing ‘not found’ are the ones we need to move around.
cp -a /usr/local/mattsfuse/lib/libfuse.* /usr/lib
find / -name libvixDiskLib.so.1 -print
cp -a libvixDiskLib.so* /usr/lib
–> This should now show you the locations of the missing files that have now been found:
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib/libdl.so.2 (0xb7e4a000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7e34000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7e01000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7def000)
libvixDiskLib.so.1 => /usr/lib/libvixDiskLib.so.1 (0xb7c98000)
libfuse.so.2 => /usr/local/lib/libfuse.so.2 (0xb7c7f000)
libc.so.6 => /lib/libc.so.6 (0xb7b53000)
librt.so.1 => /lib/librt.so.1 (0xb7b4a000
Next you should be able to run “VdrFileRestore -a “ As per VMware’s instructions on the 64-bit guest.
Follow the onscreen instructions to select which backup day that you want to mount the filesystem for. You will then need to SSH onto the 64-bit guest. If you run ‘df’ you will see that there is a /tmp/xxxxxx file mounted in the list. – Do not try to use this as a file path to grab files from. Instead use the suggested /root/HOSTNAME-DAY mount point.
For a test I moved /etc/hosts /etc/hosts.myold and then copied /root/HOSTNAME-DAY/etc/hosts /etc/hosts, and checked that I could read it ok.
Hope that someone might find this useful. VDR is an amazing backup tool that is free with the Enterprise licence. You can either do a complete host restore, or use FLR as described above to restore single files from inside the machine image.
[amazon asin=B004MMEJ2M&template=iframe image&chan=default]
© Matt Palmer 29 Jan 2012