11 May 2009
Rate this item
(0 votes)

If you’ve ever had trouble installing VMware tools on certain distributions of Linux, it may be worth a shot looking at VMware Tools Operating Specific Packages, or VMware Tools OSP.

VMware Tools OSPs are VMware Tools software packaged in the native package format and standards for selected supported Operating Systems (Guest Operating Systems). These packages are distributed for example in packages such as rpm and dep.

Currently VMware Tools OSPs are supported for the following Guest Operating Systems:

·         Red Hat Enterprise Linux 4 and 5 (RHEL)

·         SUSE Linux Enterprise Server 9 and 10 (SLES)

·         Ubuntu 8

You can download a user manual for OSP at http://www.vmware.com/pdf/osp_install_guide.pdf
Read more...
02 May 2009
Rate this item
(0 votes)

VIRTUALVCP.COM was down between 25-04-2009 and 02-05-2009 due to a firewall failure in my hosting environment whilst I was away on vacation with my family in South Africa. On the 25th of April, I noticed that my mobile phone stopped communicating with my active sync email server. I soon realised that the problem affected the entire hosting environment, including www.virtualvcp.com and www.vi-pedia.com.

As I was almost 10,000km away from home, I was left with no other choice than to wait until I could get back to the UK to resolve the issue.If you are reading this article from www.virtualvcp.com, it's obvious that the problem has now been resolved. I will now have to go back to the drawing board to work on a redundant connection to my hosting environment. At this moment in time, my websites do not generate enough unique hits per day to justify me moving the sites to a dedicated hosting environment. Once I get 3000+ visits per day, then I may look into moving out.

I do apologise for the down time of this website. It is against my personal  beliefs to have an unreachable website, even for an hour, but my hands were tied in this case. Thank you again for visiting www.virtualvcp.com. Keep checking back for some content on vSphere. I am now well rested and ready for some good blog'n! 

 

Read more...
16 Apr 2009
Rate this item
(0 votes)

Those of us who use VCB (VMware Consolidated Backup) to perform backups of their SAN based virtual machines may know how time consuming and frustrating it can be to find and clean up stale snapshots on virtual machines that were left behind by failed VCB backups. This is even more time consuming if you have a large scale virtual environment with hundreds or even thousands of virtual machines than needs to be backup up on a daily basis.

Let me first give a brief explanation on how VCB goes about backing up virtual machines and why having stale snapshots on virtual machines prior to a VCB backup job will spell problems.

Every time a VCB backup job kicks off, a snapshot is created on the VM that is going to be backed up. Whilst this snapshot is in place, all changes that takes place in VM’s guest OS will be written to delta VMDK files, that is one delta file for every virtual disk on the VM. These files increment in 16MB chunks and on a busy VM, say for instance a VM that hosts a large database, these 16MB increments may result in several gigabytes per delta file. Whilst any changes are being written to these delta files, VCB can go ahead and mount the main VMDK files to the VCB proxy server in order to make the VMDK files or their contents available to your backup software, i.e. Netbackup. When the backup job completes, VCB will then remove the snapshot by merging the changes recorded in the delta files with the main VMDK files and delete the delta files from the SAN.

Now, in theory this sounds very neat, and in reality it is. That is, until it goes wrong. Sometimes when a VCB backup job fails (and they do fail from time to time), the snapshot on the VM doesn’t get removed. In this case, all changes to the guest OS will still continue to write to delta files. And to make things even worse, I’ve seen cases where the snapshot failed to be removed even though the VCB backup job completed successfully. In this case, Netbackup will show a successful backup, yet the snapshot still exists on the VM. You simply can’t assume that all virtual machine snapshots are cleared off just because Netbackup or whatever you use as your backup application reports successful backups.

So why are stale snapshots a problem you might ask? Well, not only do they grow to huge sizes which may actually cause the datastore to fill up and crash all other VMs on that datastore, but VCB will probably not be able to perform backup operations on a VM that already has snapshots. So yes, a stale snapshot on a VM will cause your next VCB job to fail. You also run the risk of your snapshot delta files to go out of sync with each other and that could cause a loss of data in the worst case. All of which I have first hand experience.

My advice is simple. Make sure you don’t have any snapshots on any virtual machines in scope of being backed up prior to the backup window opening. This is simple, but if you have hundreds of virtual machines, going though each VM to check for snapshots is insane! So, myself and colleague came up with a Perl script that will go and check for any delta files in all datastores seen by the ESX host and return a list of delta files via email.

You can download the script here.

Read more...
14 Apr 2009
Rate this item
(0 votes)

EMC has introduced a new line of Symmetrix products. The new Symmetrix products can start small and expand up to support the largest virtual datacenter infrastructures.

EMC Claims that the new Symmetrix V-Max and V-Max SE (Virtual Matrix Architecture) storage arrays can scale up to hundreds of thousands of terabytes of storage and is capable of supporting hundreds of thousands of virtual machines.

The Virtual Matrix Architecture is built on the V-Max engine, which contains all the necessary disk and I/O ports along with multiple Intel quad-core processors, up to 126GB of memory and the Engenuity operating system [by EMC].

EMC marketing vice president Barbara Robidoux said that the new V-Max architecture is "the single biggest innovation for the storage industry in years. Each Symmetrix Frame can fit up to eight V-Max engines. This gives a total of 1TGB of memory and twice the front-end and back-end connectors supported by EMC's current high-end DMX-4 systems. Also, an entry-level V-Max SE costs 10% less than a DMX-4, but due to Intel's quad-core processors, the V-Max offers significantly better performance.

Connectivity options include:

  • Fibre Channel
  • iSCSI
  • Gigabit Ethernet
  • Ficon for IBM mainframe systems.

 

Now, I'm off to get one for my home lab ;-)

Read more...
02 Apr 2009
Rate this item
(0 votes)

After patching some test ESX hosts with ESX 3.5 Update 4, the problem with the VMware tools being shown as "Not running" after a VCB backup operation seems to have been solved. This has cured some backup woes at least.

I will now run ESX 3.5 Update 4 in a test cluster (with virtual machines that will be backed up with VCB) for a few of weeks before updating production ESX hosts to Update 4.

Read more...
21 Mar 2009
Rate this item
(0 votes)

Last week we started having problems with VCB Backups. Normally while a VCB backup job is in progress the VI Client will report that the VM tools is not running on the VM that's being backed up. When the VCB backup job completes, the status of the VMware Tools changes from "Not running" to OK.

However, I've seen cases where even after the VCB job completes, the VMware Tools status fails to change from "Not running" to "OK". If you then try to run a VCB job on the same VM, the job will fail if the VCBMounter is set to look for the virtual machine IP rather than virtual machine name or UUID.

I first noticed this problem on Monday, 16 March, but a couple of days later I found a VMware KB article dated 18 March 2009 which describes the exact same issue. The problem seems to be occurring only on hosts with patch bundle ESX350-200901401-SG. However, instead of offering a fix to the issue, VMware is only offering a few workarounds. I hope they release a patch to fix this issue soon.

Some workarounds given by VMware are:

        1. Restart the mgmt-vmware service immediately after the backup job is done. This changes the Tools status to OK. You can write a cron job to do it periodically.

          OR
  1. Log in and log out, or log out if you are already logged in, from the virtual machine. This changes the Tools status to OK if it was showing as Not running.

    OR
  2. Use VCBMounter to look for virtual machine name or UUID rather than virtual machine IP. Virtual machine IP only works when the status of tools is OK, but virtual machine name and UUID works even if the Tools status shows as Not running.

 

My preferred workaround: 

I find that restarting the VMware Tools Service in the guest OS always gets by the problem, but loggin into every single VM that reports the wrong status for it's VMware Tools could be a bit of a drag. So I choose to do this remotely rather that logging on to each VM.

From any Windows workstation/server, open a command pompt and run:

sc \\{vm-name-or-ip-address} stop "VMTools"
sc \\{vm-name-or-ip-address} start "VMTools"

 

Information on this issue can be found on the VMware Knowledge Base article: KB1008709

Read more...