End of Availability of vSphere Data Protection

Wow…. ok….. so this was an interested announcement to receive. Whilst I kind of understand that VDP wasn’t really deployed by the masses, it was still nice to be able to have a free backup solution if you were deploying a small VMware environment.

The EoA of vSphere Data Protection pretty much means anyone wanting to backup their VMs will now need to pay for a 3rd party product! That kinda sucks!

VMware vSphere 6.5 is the last release which includes the VDP product!

You can read more about the announcement here: http://www.vmware.com/products/vsphere/data-protection.html

Also worth checking out the VMware KB article for more info: https://kb.vmware.com/kb/2149614

And if you have VDP deployed then don’t worry, any installations where you have an active Support and Subscription (SnS) will continue to be supported until the End of General Support (EOGS) date – the EOGS date can be found on the VMware Lifecycle Product Matrix.

It’s worth noting that this does not affect the vSphere Storage APIs – Data Protection (VADP) which most 3rd party vendors utilise.

It’s also worth noting that Dell EMC are helping those who have VDP deployed by offering them 3 years of free Avamar Virtual Edition (AVE) licensing to protect the first 4TB of protected data – although Maintenance costs will continue to apply during this 3-year period. Offer valid through October 15, 2017.

The offer can be found here: http://dellemc.com/vdpeoa

 

Finally, the FAQ released will assist with any questions you may have: http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vsphere/vmw-vdp-eoa-faqs.pdf

Advertisements

Upgrading vCenter Server from 5.5 to 6.0u1

Now that VMworld Europe is over I’ve had more time to sit down and look at MTI‘s Solution Centre and decided that I’d take the opportunity to upgrade my company’s primary demo environment to vSphere 6.0. Previously I had held off doing an upgrade because we run a PernixData demo environment on our main ESXi cluster and were waiting for the new FVP to be released. Now that it has (FVP 3.0), there was no reason to stick to an outdated environment!

So like most guys who don’t RTFM….. I delved straight in and mounted the vCenter ISO to kick off the upgrade – the first thing it does is run a pre-upgrade check.
vc1

Unfortunately for my environment, the pre-upgrade check flagged up an unsupported database version…..
vc2

Turns out the lowest version of Microsoft SQL Server supported is 2008 R2 SP1 and the version I deployed years ago was 2008 R2 RTM (no SPs).

To verify the SQL Server version, compatibility level, and edition you can execute a simple SQL query:

  1. Open the SQL Server Management Studio and connect to the SQL Server that vCenter Server database resides on.
  2. Run the this query on the vCenter Server database to verify the version, level and edition:
    SELECT SERVERPROPERTY(‘productversion’), SERVERPROPERTY (‘productlevel’), SERVERPROPERTY (‘edition’)
    vc2a

To find out what SQL server build you have, pop along to this great website: http://www.sqlsecurity.com/faqs-1/sql-server-versions/2008-r2

The Database Interoperability Matrix for VMware can be found here: http://www.vmware.com/resources/compatibility/sim/interop_matrix.php

So if you’re in the same position as me, you pretty much have one of two options:

  1. Do a fresh install and lose all your historical data and other configurations from vCenter.
  2. Do a database migration to a supported DB.

Fortunately for me, you can easily migrate from SQL Server 2008 to 2012 – and again you have two options on how to do this:

  1. Do an in-place upgrade where the SQL Server is upgraded where it’s currently installed
  2. Do a database migration where the old SQL DB is migrated onto a new SQL Server environment.

In my case I decided the second option would be the best option as I also wanted to upgrade the OS to Windows Server 2012. There are a number of migration options available to you, but for me the easiest option was to do a backup of the old database and restore it onto the new database!

I won’t go into how to deploy SQL Server 2012, as there are loads of tutorials online so here’s the process I did to backup and restore my DB:

Note: In order to transfer the backed up database file from the old SQL Server 2008 R2 VM to the new SQL Server 2012 R2 VM I simply added a new vDisk to the 2008 VM, backed up the DB onto that vDisk, then attached it to the 2012 VM.
You will also need to know the user account assigned to the VCDB.

  1. Before backing up the vCenter Database, ensure the vCenter Server Services are stopped.
  2. Backup the vCenter Database from within SQL Server Management Studios: Right-click the DB, select Tasks and Back Up.
    vc3
  3. Create a Full Backup and choose the destination (in my case a new disk which I will disconnect and add to the new SQL VM).
    vc4
  4. Once backup is complete, remove the vDisk from the VM, ensuring you choose the “Remove from virtual machine” option, DO NOT CHOOSE THE “… and delete files from disk”.
    vc5
  5. On the new SQL VM, create a new vDisk and select “Use an existing virtual disk”.
    vc5a
  6. Browse to the datastore containing the old SQL VM and select the vmdk file relating to the vDisk with the database backups.
    vc6
  7. Once mounted, open a console to the new SQL VM and check the DB backup files are there. Open up SQL Server Management Studio and right-click Database and select Restore Database.
    vc6a
  8. Verify options are correct and restore.
    Restoring a database automatically creates the database files that are needed by the restoring database. By default, the files that are created by SQL Server during the restoration process use the same names and paths as the backup files from the original database on the source computer.
    Optionally, when restoring the database, you can specify the device mapping, file names, or path for the restoring database.
    vc7 vc8
    vc9
  9. When a database is restored on another system, the SQL Server login or Microsoft Windows user who initiates the restore operation becomes the owner of the new database automatically.
    Once the DB has been restored, there are a number of additional configurations required, one of which is to recreate the DB security users and SQL Agent Jobs.
  10. Create a new Login to SQL Server 2012 making sure the new login matches the old one from SQL Server 2008. Assign the VCDB as the default DB and ensure the new user is the VCDB owner.
    vc10vc12vc11
  11. Finally change the DB compatibility level from 2008 to 2012. This allows the usage of the new SQL Server 2012 features. The following script can be used to automate the change (rather than going into each database property):
    USE [master]
    GO
    ALTER DATABASE [mydatabase] SET COMPATIBILITY_LEVEL = 110
    where [mydatabase] is the database to change the compatibility level
  12. Re-create all the SQL Server Agent jobs, for a complete list of the jobs that should be present, see:
    http://kb.vmware.com/kb/2033096
  13. Configure Microsoft SQL Server TCP/IP for JDBC and create a 64bit ODBC DSN.
    vc13vc14
  14. Once the DB has been restored, you can remove the vDisk that was attached with the backup files.
  15. Complete the vCenter Server 6.0 installation (I won’t go through the process here). For the demo environment, we used an Embedded PSC Deployment and when prompted we chose the DSN to the migrated VCDB and chose to use the data on this DB rather than re-initialising the DB.
    vc15

ESXi bug – backing up 128GB vdisks and CBT

So I read about this issue a week or so ago when this bug started doing the rounds in the VMware communities and The Register picked up on the issue…. I was planning to blog about it but it slipped my mind due to a busy end of month! >_<”

Anyways, VMware have sheepishly recognised the bug and produced a KB article about it: http://kb.vmware.com/kb/2090639

The bug affects VMs with Changed Block Tracking (CBT) turned on, specifically those VMs that have had its storage (so a single vdisk) increased in size by more than 128GB.
The problem only presents itself when it comes to the execution of the command QueryChangedDiskAreas(). This API call is commonly used by backup softwares to determine what part of a VMs vmdk file has been changed since the last backup in order to execute an Incremental Backup.

It seems that once the vmdk is increased to more than 128GB, you get an inaccurate list of allocated VM disk sectors returned by the API call, and so any sort of incremental backup could be erroneous and some changed blocks may not be captured during backup. Obviously this means that in the case of you restoring from the erroneous backup, you may experience data loss!

This is a known issue affecting VMware ESXi 4.x and ESXi 5.x and currently, there is NO resolution.

To work around this issue, VMware recommends that you disable and then re-enable CBT on the VM. The next backup after toggling CBT will be a full backup of the virtual machine.

The issue here is in order to disable CBT, you need to power off your VM and ensure there are no snapshots attached to the VM…… quite a pain in the rear end!
Info on how to disable and enable CBT can be found here: http://kb.vmware.com/kb/1031873

Also I’m not too sure whether it fixes CBT or whether it will keep generating the same inaccurate info every time the vdisk blocks change and you try to run an Incremental…. unfortunately there isn’t enough information out there yet!
I pity the admin who has to run daily fulls in order to combat this bug….. 128GB backups… ouch!

Fortunately none of my customers have a vdisk of that monstrous size so this shouldn’t affect many of them!

Link

VMworld 2013: Next-Gen Backup

So during my searches online for all things VMworld related, I stumbled across this interesting blog entry by VirtualGeek regarding backups….. always a bane of any VMware admin!

It seems that EMC and VMware have shacked up once again and the new features on Avamar 7 shows a tighter integration with vCenter…. it even looks like it’s using a vCenter web-client extension that we saw with VDP (not surprising since VMware took Avamar’s algorithms, so why shouldn’t EMC take stuff from VDP?).
The self-service recovery portal looks surprisingly similar to the VDP version (albeit with more functionality).

The demo showing Avamar working together with Data Domain to fire up a VM from within the DD storage was pretty impressive – EMC call this “VM Instant Access”!
Basically DD will be used as a backup target for Avamar (with Avamar itself determining whether to push the data to DD or to an Avamar grid – usually high changing data is sent to the DD), the VM will be restored via a NFS datastore mount from within DD itself.
Looks very simple and very effective…. especially since after firing up the VM in the mounted datastore, you can just simply Storage vMotion it back into your production environment!
Simple, Instant Access! =)

The Backup-as-a-Service demo was pretty interesting regarding how they use the vCHS and Avamar for BaaS…. whilst not fully released yet for production, it gives a good insight into what’s possible and the direction both VMware and EMC are taking.

Finally the Avamar and vCOPs/LogInsight integration demo was very cool……. vCOPs is a great management tool which I try to encourage all my VMware customers to buy and use…… having the Avamar integration would be very beneficial as you get a single dashboard which will show not only the health of your VMware environment, but also the health of your backups!
And with the integration you will also get to see all the metrics for Avamar (GB protected, dedupe, VM backup related information, etc) alongside all the usual VM metrics that comes as standard with vCOPs.

 

BTW, no keynote session on Day 3 of VMworld….. so pretty much most blogs are re-enforcing what was talked about during the first 2 days….. Seems day 3 was pretty much vendor related with a lot of people checking out what NetApp and EMC had to offer. A lot of blog entries about VNX 2 and MCx…..!