vSphere Data Protection 5.1: Backup fails for Windows Server 2008 R2 VMs

So today I got to the bottom of another interesting case concerning backups with vSphere Data Protection.

After deploying the virtual appliance, registering it to the vSphere Server and creating backup jobs, something interesting happened: Linux VMs got backed up, whereas Server 2008 R2 VMs got errors.

To make a long story short: It has to do with the UUIDs of the virtual HardDisks and Windows VSS, and the fix is quite easy, as can be seen in this KB from VMware:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2035736

esxtop not working in OS X terminal

Also, as I did some troubleshooting lately and came across this issue, here is how to resolv the problem with the OS X terminal and esxtop:

Simply change the setting of the terminal emulation from xterm-256-color to just xterm. voila it works!

Thanks to Punching Clouds: http://www.punchingclouds.com/2013/01/30/esxtop-data-display-issues-with-osx-terminal-application/

Registering vSphere Data Protection to vCenter does not work…

So it seems that when you install vSphere Data Protection and want to use a distinct user that is not Administrator or root, you need to give that user (in this installation it was called datarecovery from the old version) rights on vCenter Level on its own. Just putting that user into a Active Directory Group will not suffice, as registration to vCenter will then give an error as result.

Bild

vSphere/VMware: failed to connect virtual device ethernet0

failed to connect virtual device ethernet0

That message said hello for every single VM after there was a major breakdown in a data center. The breakdown was seen as a welcome opportunity to upgrade everything from 4.1 to 5.1. And since everything was broken anyway (although the VMs continued to run, yeah VMware ;-)) no one bothered going the proper path but just evacuated some ESXi-Hosts, re-installed them with 5.1, created a new vCenter and tried to import the VMs.

What was happening?

The GUI gave no hint as to what was wrong. But in the ESXi host logfiles something gave away what was going on: “vShield filters cannot be found for ethernet0”. Now, that is a clue, indeed!

The old 4.1 was running with everything filtered through vShield, whereas it was decided to not use vShield in this setup for 5.1 anymore. But in every single vmx-file for every VM there had to be removed the following two lines in order for everything to work as it should:

ethernet0.filter0.param1 = “uuid=5006f477-a2df-b018-b331-b2b61f1b95f9.000”
ethernet0.filter0.name = “vshield-dvfilter-module”

So, people, beware of vShield when moving VMs from one cluster to another.

All the best,

Thomas

vShield Manager 4.1 spikes in CPU usage, acting up…

Since a couple of weeks we let vSphere monitor our VMs in addition to the nagios monitoring we have had from the beginning.

The vShield Manager VM started to show odd behavior: CPU spikes to 100% every 10 to 30 minutes, then returning to normal. Operation worked as normal, nothing showed in the log files (although: you don’t really see the system log files in the interface).

Somewhere I read something about the mySQL database having problems, and a reboot would fix that. So, reboot… After all, what could go wrong, right? The single firewall VMs are working independent from the Manager, so nobody should even notice… so far so good.

vShield Manager VM did not boot up properly again. You could not login via the web interface. On the console you’d see only the message “System startup is not complete. Please logout and log back in after a few minutes.”

After some hours still the same. On the console (you don’t get a full bash, just a stripped down management shell that does not much) not much was showing. On thing made us curious though: “show filesystems” did say something about mount file could not be read.

A bad foreboding struck my colleague and me: Filesystem corrupt? Without a bash there is not much you can do. So we downloaded a live linux cd, rebooted the VM into that livelinux, and saw it in an instance: The filesystem simply was full. 0 bytes free. Ok, that definitely is a reason for mySQL and tomcat not to start, and definitely a reason why nothing shows up in the log files.

Now with a bash at hand, we investigated, and our first thought where the log files. But we found only 20 MB worth of log files in /var/log. Everything rotated, gzipped and deleted as supposed. So what was going on?

Turns out vmware forgot about the tomcat logfiles. Tomcat saves its own logfiles into its own directory. And that directory was full of catalina-logfiles, going back to the very day the system was installed.

Simple fix: Delete the old junk no one needs, and the vShield Manager is rebooting like a charm.

So, vmware, I’d guess you have fixed that in a newer version already, although I have not checked yet. If not: Shame on you. Leaving admins out with no proper bash or other good way to determine what is going on. That is a shortfall on your side!

P.S.: No hard feelings though, vmware. I still love you 🙂

bridging ethernet interfaces under OS X

So, one of our domain printers was acting up and the printer department wanted me to sniff all the packets to and from the printer. So far so good, usually you could use a hub (still got one around? neither do I), or for example a switch with a monitoring or promiscuous port (not available? Welcome to the club!). Ok, now I could start arp spoofing the printer, but was too lazy to do that, besides: we have intrusion prevention up and running…

Take a good look at your machine. Is it a portable laptop like mine? Does it have any flavor of Unix or Linux on it? Well, so does mine, in this case Apple OS X (10.8.2). There’s got to be a way to bridge two ethernet interfaces, connect myself to the network and let the printer talk to the world through my laptop? You betcha!

Here’s what I did:

  • grab one of those USB or Thunderbolt Ethernet Adapters
  • ifconfig // to find out which interface is which
  • sudo ifconfig en3 up // bring up the USB/Thunderbolt adapter, or it won’t work!
  • sudo ifconfig bridge0 create
  • sudo ifconfig bridge0 up
  • sudo ifconfig bridge0 addm en0 addm en3
  • sudo sysctl -w net.inet.ip.forwarding=1

It works! Now we can sniff away with tcpdump or wireshark for example, and are sure that no packet is going to escape us…

And to undo what we just did:

  • sudo ifconfig bridge0 down
  • sudo ifconfig bridge0 deletem en0 deletem en3
  • sudo ifconfig bridge0 destroy
  • sudo sysctl -w net.inet.ip.forwarding=0

Many thanks to Chrissy from netnerds, who set me on the right track with her post about NAT on OS X 🙂

vmware: no snapshot in snapshot manager, but *0000002.vmdk still around?

I ran into this problem a few days ago when I tried to give a vm a little more storage. I could not, it was greyed out. After looking into it I found the problem: This virtual machine was running on a snapshot. So, go to the snapshot manager and find: nothing!

Tracking the problem back: A while ago the vm needed a snapshot in order to be safe for an update. So, create snapshot, install updates. All fine. After that, the snapshot was deleted, and in the snapshot manager you did not see any snapshots.

But somehow the vms config still pointed to the delta-file instead of the original. And the delta was still growing. All in all over a 100GB, because this has been going on for quite some time now.

With vSphere 5 / ESXi5 there is a quick solution. In the virtual machines tab look for “Needs consolidation”. It is says yes, right click the vm -> snapshots -> consolidate.

But here we have ESXi 4.1 and vSphere 4.1, so no “consolidate” nor “needs consolidation”. How to fix this?

It can be done in most cases quite easily, but I needed some encouragement from others that already performed this: Create a new snapshot, and right when it is done: Delete all.

This will consolidate even the not shown snapshots and leave you with an all functioning vm.

So, for me, that did the trick. But sometimes it is not so easy. Please consider reading these links first:

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1002310

http://communities.vmware.com/thread/315862

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005049

http://malaysiavm.com/blog/manual-commit-snapshots-delta-file-to-vmdk-flat-file/

Wish you the best of luck with your problem, and please read my disclaimer 😉