Backing-up to AWS: Basics of Storage Gateways Types

AWS ‘s Storage Gateway solutions are designed to be used as a backup destinations for your infrastructure. There are 3 types of Storage Gateway solutions offered by AWS:  File, Volume, and Tape Gateway.

Overall process is, you either deploy a local on-premises VM ( Hyper-V/Vmware VM), or a cloud based one which is in turn of course runs on AWS EC2 instance. You need to add an additional virtual disk to the  Storage Gateway,  to cache the data before it uploads it. The disk size has to be a minimum of 150GB, and you can add several drives for a total of 16 TB in size across all drives. You can’t allocate the drive with 150GB to begin with, and then increase its size down the road, you will have to add a new disk, if you want to increase the cache size.

There is an additional requirement for Volume and Tape Storage gateways; you will need to have an “Upload Buffer” drive(s) along with caching drives.  Upload buffer drive has to be a minimum of  150GB and a maximum of 2TB in size.
As name suggests, Upload buffer’s purpose is straight forward; backup data from the cache drives are transferred to the  upload buffer drive, and afterwards it gets copied to AWS’s storage, then buffer gets re-filled from the cache drive with more data, and so on.
Cache drives purposes is on the other hand is twofold;  besides pumping more data into Upload Buffer, it keeps the  cache of your most recent backup data, depending on the cache drive size. It will check the cache drive to see if the data is still available on the cache drive, if that is the case,  then  you don’t have to  pull data down from AWS storage, and of course not incurring  data transfer (charged per GB of data retrieved) charges from  AWS.

Data Storage:Compression, de-duplication or deltas ?

File based Storage gateway (NFS) doesn’t make use of any compression or de-duplication mechanisms. But as per FAQ ” uses multipart uploads and copy put, so only changed data is uploaded to S3 which can reduce data transfer”. Basically, it will compare your current file with the one that was already uploaded, and upload only changed bits, which is still good, and should reduce Continue reading →

Please follow and like us:

VCDX workshop notes

Below are the notes I have taken during the NJ/NY VCDX workshop at @iamAntonZ  ‘s place. We had a great opportunity to have 2 VCDX panelists giving the VCDX workshop, Niran Even-Chen ( @NiranEC) and Agustin Malanco (@agmalanco).  You could find more info on this at 

 These notes are by no means to be used or relied on as primary source for your VCDX preparation.

Your design must include all the VCDX blueprint points.

Don’t use any kind of blogs as an official source for your references . Official VMWARE docs are the only sources that you can quote or reference to in your VCDX design.

One of the main changes to VCDX is removal of the “Troubleshooting” scenarios from the defense.

One design can be submitted 2 more times, if it did not get accepted the 1st time around. This means that you will need to make some modifications to your design, before resubmitting it again. You won’t get any detailed information on why it failed the submission, but you might get a generic response such as ” Storage or Networking needs more info”.

Same design could potentially be submitted by 3 different people, and they must submit it at the same time for the same VCDX track. Also, each and every applicant must know the design inside out, not just the portion he or she design.

It takes an average of 4-7 month to prepare the design and validate it. Once you got accepted for defense, get yourself an official VCDX mentor. The mentor will not be fixing your design for you, but rather guide you and advise you on proper documentation. Lookup the directory, and work with him to help you out on this. Just keep in mind that they are ( VCDX mentors) are not being paid for it and do it rather on their own time.

Continue reading →

Please follow and like us:

Recovering VMs after a vmware’s Purple Screen of Death (PSOD)

I had an interesting case a while ago. One of our test ESXI hosts running ESXi version 5.5 has crashed taking down number of test environments with it.

All the attempts to bring the host back to life was in vain, as each reboot was giving us a Purple screen of Death.  We needed these test environments up and running ASAP, and due to time limit on hands, it was decided to :

  1. keep the current VMFS datastore and install partition intact,
  2. Install ESXI 5.5 from scratch onto a USB flash drive, and
  3. Re-create the vSwitches
  4. Re-import the VMs into inventory
  5. Re-import and start up the vCenter
  6. Login to vCenter and bring up the test environment back online

Luckily this test server- a Cisco UCS C220- had its CIMC enabled, and IP configured for remote access.  So, I was able to connect to the hosts’s remote management panel (CIMC) and install the new Esxi via Continue reading →

Please follow and like us:

Some useful UNIX shell commands for VMware admins

These are the esxi host log files one needs to be quite familiar with. These logs should be checked depending on the issue you facing, and trying to troubleshoot.

  1. /var/log/auth.log: ESXi Shell authentication success and failure.
  2. /var/log/lacp.log: Link Aggregation Control Protocol logs.
  3. /var/log/hostd.log: Host management service logs, including virtual machine and host Task and Events, communication with the vSphere Client and vCenter Server vpxa agent, and SDK connections. Continue reading →
Please follow and like us:

Error while upgrading from VMware vCenter 5.1 to vCenter 6.0


I have not seen any special feature improvements in 5.5 over 5.1 that would have benefited our environment, and as with any other major new releases  was patiently waiting for VMware to come out with Update 1 for vSphere 6. Originally I had the SSO, VMware Update Manager, and vCenter each running on its own server. Databases for SSO and vCenter are separated to a standalone SQL 2008 R2 server.   I ended up combining the VUM and vCenter on one single server, and upgrading the SSO to PSC (Platform Services Controller) and kept it separate, in case if we go with 2nd vCenter in the future.

Upgrading vCenter from 5.1.x to 6.0 is quite straight forward process, mount the vCenter 6 VMware-VIMSetup iso image to the vCenter server, and run the installer. It will recognize that there is a previous version installed and offer you to upgrade it.But first, make a backup of working production servers, before the upgrade. Shutdown the VMs, and copy the SSO and vCenter vmdks to a separate folder – in case if snapshots decide to take a break from work. Take the SSO, vCenter snapshots, and of course backup the SQL databases, if you have them running separately.

Don’t despair, if you receive the below error during vCenter upgrade: Continue reading →

Please follow and like us: