All Posts

Backup and Desaster Recovery in our VI3 has been a mess until today... How did we backup 'n restore before: backup type 1: agents inside the VMs (expensive license costs) restore type 1: fresh install a VM from a template, adjust VMDK size and configuration, restore from tape/disc backup type 2: snapshots using the vcbMounter command on the ESX host console for VMs which didn't need to be backed up periodically (lots of work to be done by hand) restore type 2: restore using the vcbRestore command on the ESX host console How do we backup 'n restore now : Today there is only one backup policy using vizioncore's vRanger installed on our backup server. We save VMs to another ATA disc storage array Unfortunately the is no possibility today to use differential backups and backup over SAN with vRanger. Because we are limited on space at the storage array we are not able to make daily full backups to use the SAN functionality in combination of vRanger and VCB. Restore is very easy using vRanger and works quite well. Problems left: We see empty (zero sized) differentials on VMs configured with RDM. Snapshots have to comitted otherwise differentials are of the size of full backups. Because we are forced to use LAN backup || ESX (LAN) >Backup Host (SAN) >storage array || backup lasts very long. We are looking forward to a SAN based method.

Procedure Overview: Restore Files VM Registration Restore Files: Browse to http:// Power on VM using Virtual Center. Troubleshooting: "The system cannot find the file specified" - This is caused by 'scsi0:0.fileName' parameter in the vmx file pointing to an incorrect vmdk file or to the *-00000?.vmdk file "A file was not found." - Same as "The system cannot find the file specified"

This post inspired by kimono's recent post, On my way out from Buffalo to VMworld, I made a slight detour to visit family east of Sacramento. Here is my Uncle's custom sand rail... it could be the world's fastest processor (on wheels): Yes, he might work somewhere in the Folsom area

If you haven't gotten ahold of this, do so. Now!!! Seriously, stop reading this and go get it. VI Perl Toolkit Now that you have it in whatever flavor you choose: compile yer own, x86 binary package, or the virtual appliance (how easy can they make it for you?), start playing around with the included demo applications. I've been tinkering with viperltoolkit since the alpha showed up on sourceforge.net last year. Its perfect for all those little things that you just can't get out of Virtual Center directly. In particular I use it for automating reports that keep our operational staff clued into any VMs that seem to be in PSM (perpertual snapshot mode) or those that have virtual CDROMs mounted (which caused those VMs to be excluded from DRS operations). I've been keeping things pretty simple, but some folks are doing a heck of a lot more than that with the toolkit, based on some discussions I seen on VMTN. If you're still reading this, yet haven't gotten the tool... shame on you. - Random semi-non-virtualization thought: Trying to potty-train a 2 year old is far more difficult than setting up VI3.

Here is a quick 2 line change to enable ssh for root. cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig sed 's/PermitRootLogin no/PermitRootLogin yes/' /etc/ssh/sshd_config > /etc/ssh/sshd_config If you want the changes immediately before a reboot also execute: service sshd restart Again, very handy in kickstart.

One of the initial issues I had with Virtual Center is that it did not always show the correct firewall settings. The command esxcfg-firewall seemed to be the authority on open ports. By executing 'service mgmt-vmware restart' at the command prompt it syncs up VC with esxcfg-firewall. If you decide to script this and plan on having commands after this, you will want to add a 'sleep 20' command on the next line so that the VM management service has a chance to finish the sync.

TSM v5.4.1.0 Installation 1. Execute: rpm -ivh TIVsm-API.i386.rpm 2. Execute: rpm -ivh TIVsm-BA.i386.rpm 3. Create/edit config files. Configuration The way I like to do it is to copy my config files from a static source and then edit them on the fly with a few replace commands. This facilitates kickstart deployment. I have included my sample config files below. Commands to execute for tsm server and node replacement sed -i.old -e 's/tcpserveraddr tsm1/tcpserveraddr tsm3/g' /opt/tivoli/tsm/client/ba/bin/dsm.sys sed -i -e 's/nodename yourvm-bu/nodename vm01-bu/g' /opt/tivoli/tsm/client/ba/bin/dsm.sys Included files: dsm.sys - Base config file for TSM on ESX dsm.opt - Base config file. Not typically used on ESX but included just to be safe. inclexcl - Include/exclude file. This dynamically changes with my TSM backup script.

When running TSM for the first time on ESX, you are prompted for a username and password. Here is a script to auto answer the first run questions. It assumes that the dsm.sys file exists and is correct. It also assumes that the node has been created on the TSM server. I would recommend this script if you wish to auto-configure TSM during kickstart. Requirements: TSM Configured perl module IO::Tty perl module Expect.pm

Here is a TSM backup Script that I automate on each of my servers. I actually run this off of a mount. tsmex and tsmvm.pl should be in the same directory. tsm is a cron job file that goes in /etc/cron.d. After copying execute the following statements: chmod 0644 /etc/cron.d/* service crond restart

Here is a simple way to change you NTP settings. I have found this perl script handy to run during kickstart. Open the script and replace ntp1.yourserver.com and ntp2.yourserver.com with your NTP servers.

After finishing the consolidation project in which we were migration most of our matured servers to VI3 we had a problem :smileyshocked: Look at the attached pictures to get some impression what we had to drag out of our datacenter ...

Hi there, my name ist Daniel and I am IT-Infrastructure Project Manager at the University Hospital in Leipzig (Germany). We recently started a project to build up two new datacenters as the heart of a redundant infrastructure of our IT. After two years testing and consolidation with ESX and VI3 we focus now standardizing our infrastructure using VMware. Today we use WMware VI3 for testing purposes as well as for production. We are running some of the most critical application servers on VI3 like e.g. our surgery operation documentation system MCC some of our Citrix presentation server nodes, intranet server, DHCP server, printing server and so on ... If you are interested about our ongoing projekt RedIT come back for more information. Please also do not hesitate to ask questions using the comments functionality of this blog. Regards, daniel