Monthly Archives: August 2012

First Impressions of PHD Virtual Backup 6 @ VMworld

Wow!  As always VMworld is crazy, nuts, busy, sleep deprived and full of great information.  Throughout the crazy hustle I had a chance to stop by the PHD Virtual booth and have a look at the new release of their flagship product and award winning PHD Virtual Backup.  6.0 marks this release of their software and let me tell you it looks pretty sweet!

First off let me say that this is truly a feature release.  They have added a ton of new functionality, some of my favorites are highlighted below.but for a full list be sure to check out the release notes.

PHD Instant Recovery

Probably the biggest feature in the bundle if you ask me.  When disaster occurs or a failure happens the most important factor in your recovery is time.  PHD has certainly addressed this with Instant Recovery.  No more lengthy restore process, no more restoring individual virtual disks, just simply power on your VM directly from the backup storage/files.  That’s right, it runs directly from the compressed and encrypted (i’ll get to that later) files located on your backup storage for an immediate recovery.  Once up and going you can simply use VMware’s Storage vMotion to move this VM back to your production or whatever storage you would like to for that matter.  No storage vMotion licensing, no worries!  PHD has also included a technology called PHD Motion which will help you get that recovered VM back into production by basically beginning a restore process at the same time as performing an Instant Restore.  When you are ready to switch back to the restored VM, a syncing process will commit all changes from your Instant Restore VM back to your production VM.

Application Aware Backups

Having the ability to quiesce a file system before a backup is great.  That way you are sure that there is no I/O at all occurring within your OS and you can be sure that you have whats called a ‘Crash Consistent’ backup.  Having the ability to quiesce the applications running within the OS is even better.  PHD Virtual Backup now includes that ability.  Now you can be sure that not just the OS but the applications as well are completely aware that a backup is taking place, thus allowing them to quiesce and to truncate logs, perform shrinking operations, or do anything you want really as you can completely run custom scripts both pre and post snapshot.

Encryption

We all worry about encryption right?  We take measures to protect and ensure that our production data is safe and secure but often the backup data is completely ignored.  Well, PHD Virtual Backup v6 can now encrypt and secure not only the data residing on your backup storage, but they also perform and encryption on the data as it is ‘in transit’ to its’ final destination.  This gives you complete piece of mind that your precious data is completely protected and encrypted from source to target while backing up with PHD Virtual.  Also, the security certificates and firewalls on their virtual appliances are fully customizable, something you don’t normally see when deploying third-parties locked down Virtual Appliances.

Full/Incremental Backup Mode

PHD Virtual provides users with the ability to have a ready to go full backup at all times.  This is fabulous for recovery time and makes the restore process very easy.  That being said this does cause a burden on certain situations where businesses like to completely duplicate their backups to either the cloud or some sort of off-site storage.  With PHD Virtual Backup v6 you can now implement (if you chose to) a more traditional Full/Incremental backup strategy, which will cut down on the size of those incremental backups as well as not always ‘tickle’ your full backup causing it to be copied off-site every-time.  Now users will have less data to move resulting in savings in time, bandwidth, and storage costs.

These are just a few of the new features within PHD Virtual Backup 6.0, there’s many many more including Email Report Enhancements, File Level Recovery enhancements, etc.  If you are at VMworld go and check them out for yourself at Booth 314.   If you were unable to make the show (ugh!  I’m sorry) they have a ton of resources/videos over on their website outlining everything that is new.

 

Generating a Remote Console URL in vSphere 5

I’ve ran into a “real-world” situation where I actually needed to grant one person access to one VM within our organization.  This normally wouldn’t be a big deal right, just let them RDP into the app and do what they need to do, however in this case the applications that were being tested had a major impact on the network.  That being said, the VM was not connected to any production network at all, so right off the hop the RDP solutions is a no go.  So then I thought about providing this user access via View, but it only supports a ‘desktop’ operating system.  Then I remembered the Remote Console URL  Now normally prior to vSphere 5 you could just go and click the  ‘Generate Remote Console URL’ option that was available within the vSphere client.   I’ve actually posted a how-to here.  That being said, with the introduction of vSphere 5 that option has completely disappeared.  Why?  I have no idea!  Maybe with the introduction of the Web Client they expect users to go that route instead – Either way, I hit the googles to see what was available…

Enter Mr. William Lam (blog/twitter)!  Honestly every time I hit the web looking for a script or an answer to something virtuallyGhetto seems to be one of the firsts hits in the results; just as it was this time.  William has a pretty nifty script called generateVMRemoteConsoleURL.pl which does just as the name states and has even been updated for vSphere 5.  Head on over to his post here to get the script and more in-depth instructions on how to use it – it’s pretty simple and I’ve outlined the command I used below.  I ran this from my vMA server but you could technically run it anywhere the vSphere CLI for perl  is installed.

At a bare minimum all you need to pass is the vCenter IP/Name, authentication properties, and the VM name.  Yup, it’s that simple.

./generateVMRemoteConsoleURL.pl --server vcenter.lab.local --username administrator --vmname MYVM

This will in turn produce output similar to that below….

After your done simply copy the URL into a browser and you are golden!

This workaround does differ from the older way a bit.  The biggest difference is that of authentication.  Whomever opens up this URL will have to authenticate into vCenter which means you will have to grant access to the person you sharing this with to the VM you are targeting.  Not a huge deal, just give them VM User or Power User perms wherever they need it depending on the level of access you want them to have.  The other catch to that is once they have permissions setup inside of vCenter, they will be able to log in using the either the client or webclient – so make sure you set them up proper and be sure they only apply to inventory items you want them to have access to.

PXE booting a scripted ESXi 5.x Install

As of late I’ve been working on an automated deployment solution for ESXi.  Seeing as I will be deploying 50 + identical installations in the near future one thing I don’t want to have to do is follow documentation and screenshots telling me where and when to click.  So, enter the scripted install…and hey, why not throw PXE into the mix as well.

The official VMware documentation does have section dealing with PXE booting a scripted install, but it seems to assume that the VMware installation is going to be the only application included in your PXE boot and TFTP directories.  Now I don’t know about you, but the VMware installation is not the only thing that I want to boot from my PXE server.  Most people will have a menu built with various installation and utilities….so this is a few things I’ve learned over the past week that are not in the documentation…

So first off is the actual menu item in the the pxelinux config file.  Below is the actual KERNEL and APPEND items from the VMware documentation (which won’t work unless you have extracted everything into the root of your TFTP server.  As you can see there is no path preceding mboot, thus assuming it’s in the root.

LABEL install KERNEL mboot.c32 
APPEND -c location of boot.cfg MENU LABEL ESXi-5.0.0-XXXXXX-full ^Installer

Since we are placing our install files inside a utils folder, we need to change this to read as follows.

LABEL ESXi 5 Installation
 MENU LABEL ^11.VMware ESXi 5 Installation
 KERNEL utils/ESXi5/mboot.c32
 APPEND -c utils/ESXi5/boot.cfg ks=http://myKSWebserver/ks/ks.cfg

Also you can see that I have added the ks=location of ks.cfg command to boot.cfg as well.  This is what allows us to do the scripted installation.  I’m not going to delve into all of the ks options that are out there, if you want to you can go to the documentation and check it out for yourself.  The point of this post is just to get you up and running with a scripted pxe install when not residing in the root directory.

We are almost done now, just one more step.  The problem of pointing to the install outside of the root directory is solved, however the actual boot.cfg (located in the root of the install files) also assumes it is in the root directory, so we now have to go and tweak that a bit.  Again, the boot.cfg in its unmodified state is below…

bootstate=0
 title=Loading ESXi installer
 kernel=/tboot.b00
 kernelopt=runweasel
 modules=/b.b00 --- /useropts.gz --- /k.b00 --- /a.b00 --- /ata-pata.v00 --- /ata-pata.v01 --- /ata-pata.v02 --- /ata-pata.v03 --- /ata-pata.v04 --- /ata-pata.v05 --- /ata-pata.v06 --- /ata-pata.v07 --- /block-cc.v00 --- /ehci-ehc.v00 --- /s.v00 --- /weaselin.i00 --- /ima-qla4.v00 --- /ipmi-ipm.v00 --- /ipmi-ipm.v01 --- /ipmi-ipm.v02 --- /misc-cni.v00 --- /misc-dri.v00 --- /net-be2n.v00 --- /net-bnx2.v00 --- /net-bnx2.v01 --- /net-cnic.v00 --- /net-e100.v00 --- /net-e100.v01 --- /net-enic.v00 --- /net-forc.v00 --- /net-igb.v00 --- /net-ixgb.v00 --- /net-nx-n.v00 --- /net-r816.v00 --- /net-r816.v01 --- /net-s2io.v00 --- /net-sky2.v00 --- /net-tg3.v00 --- /ohci-usb.v00 --- /sata-ahc.v00 --- /sata-ata.v00 --- /sata-sat.v00 --- /sata-sat.v01 --- /sata-sat.v02 --- /sata-sat.v03 --- /scsi-aac.v00 --- /scsi-adp.v00 --- /scsi-aic.v00 --- /scsi-bnx.v00 --- /scsi-fni.v00 --- /scsi-hps.v00 --- /scsi-ips.v00 --- /scsi-lpf.v00 --- /scsi-meg.v00 --- /scsi-meg.v01 --- /scsi-meg.v02 --- /scsi-mpt.v00 --- /scsi-mpt.v01 --- /scsi-mpt.v02 --- /scsi-qla.v00 --- /scsi-qla.v01 --- /scsi-rst.v00 --- /uhci-usb.v00 --- /tools.t00 --- /imgdb.tgz --- /imgpayld.tgz
 build=
 updated=0

So there are a few minor tweaks we need to do with this.  First off, we need to add the prefix label and define where our installation files are actually sitting.  Secondly, we need to remove every single slash that is preceding every module.  This will allow our installation to load and boot as directed from a subfolder within the root directory of our TFTP server.  The modified boot.cfg is shown below…

bootstate=0
 title=Loading ESXi installer
 prefix=utils/ESXi5/
 kernel=tboot.b00
 kernelopt=runweasel
 modules=b.b00 --- useropts.gz --- k.b00 --- a.b00 --- ata-pata.v00 --- ata-pata.v01 --- ata-pata.v02 --- ata-pata.v03 --- ata-pata.v04 --- ata-pata.v05 --- ata-pata.v06 --- ata-pata.v07 --- block-cc.v00 --- ehci-ehc.v00 --- s.v00 --- weaselin.i00 --- ima-qla4.v00 --- ipmi-ipm.v00 --- ipmi-ipm.v01 --- ipmi-ipm.v02 --- misc-cni.v00 --- misc-dri.v00 --- net-be2n.v00 --- net-bnx2.v00 --- net-bnx2.v01 --- net-cnic.v00 --- net-e100.v00 --- net-e100.v01 --- net-enic.v00 --- net-forc.v00 --- net-igb.v00 --- net-ixgb.v00 --- net-nx-n.v00 --- net-r816.v00 --- net-r816.v01 --- net-s2io.v00 --- net-sky2.v00 --- net-tg3.v00 --- ohci-usb.v00 --- sata-ahc.v00 --- sata-ata.v00 --- sata-sat.v00 --- sata-sat.v01 --- sata-sat.v02 --- sata-sat.v03 --- scsi-aac.v00 --- scsi-adp.v00 --- scsi-aic.v00 --- scsi-bnx.v00 --- scsi-fni.v00 --- scsi-hps.v00 --- scsi-ips.v00 --- scsi-lpf.v00 --- scsi-meg.v00 --- scsi-meg.v01 --- scsi-meg.v02 --- scsi-mpt.v00 --- scsi-mpt.v01 --- scsi-mpt.v02 --- scsi-qla.v00 --- scsi-qla.v01 --- scsi-rst.v00 --- uhci-usb.v00 --- tools.t00 --- lsiprovi.v00 --- imgdb.tgz --- imgpayld.tgz
 build=
 updated=0

So there you go, as long as your pxe environment is set up properly you should be able to just boot into the pxe menu, select your ESXi installation label and install ESXi as normal or if you have added the directive for a kickstart installation the scripted install will begin.  If you have any thoughts, questions, comments, concerns or even suggestions on how to do this a better way please let me know in the comments below 😉

Practise makes perfect! More PowerCLI APC Powerchute Network Shutdown Goodness (Now with Power On!)

Picture this, a quaint little city in Eastern Ontario. It’s been at least a couple of months since we have really had any rain. My tomato plants are dying, my lawn is completely brown, but the datacentre, it’s chugging along nicely…Then it hits us, the first rainfall (of any real value) of the summer. Finally maybe things will start to grow again. Chatter around the office turns to the weather yet again, people are smiling, happy, can’t wait to get home see if maybe there was a chance that their grass might have turned a slight shade of green…and then, nothing but darkness and the faint sound of our neighbouring businesses generator kicking on…!

Are you kidding me? It rains once this summer and it knocks the power out? Wow! No big deal though right? We have our Powerchute Network Shutdown all configured to peel through and shut-down all of our physical hardware, and a while back I wrote this nifty little script to shutdown the virtual infrastructure, no problem!

And thus the title for this blog post – Practise makes Perfect! Turns out that I could have been a little more efficient in my script. Initially I was looping through hosts one by one shutting off VMs, then waiting, then checking, then going through for another pass, and then moving on to the next host… Well, with 10 minutes left on battery I don’t have the time to complete this process on our 8 production hosts, let alone an environment of any type of size. Needless to say the VMs and hosts that didn’t get the time of the day with the script fell hard. Thankfully, there was no corruption or issues resulting from it, but still, I don’t like things not going as planned . When I’m standing in the datacenter I like to see all of the blinky lights shut off before those air conditioners stop pumping out coolness.. So out of my failures I give you the new and improved shutdown script (now with Power ON). You can head straight here to pull down both the power off and power on scripts, but they are explained in a bit more detail below as there is a little bit of configuration to get the power on functionality to work….  As well a big thanks goes out to a fellow Toronto VMUGer (VMUGite ??) Eric Wright (blog / twitter ) and his ‘The Art of Shutdown‘ post a couple of months back.  Eric wrote a great script to shut things down and even has a great little ‘test’ mode in his version.  I got a few lines of code and ideas from Eric’s script so go check it out as well

Power Off the VMs

So first off is the shutdown script – you can get the complete version here.

Just a few notes regarding my updates to the script.

if ($keyword -ne $mysecret) 
{ 
    Write-Host "You haven't passed the proper detonation sequence...ABORTING THE SCRIPT" -ForegroundColor red
    exit
}

So first off you see here that if you call the script without a parameter or with a parameter that doesn’t match our secret keyword inside the script the whole thing aborts.  This is to stop us from simply double clicking this or accidenttally unleashing a disaster amongst ourselves.

Get-VM -Location $cluster | where-object {$_.PowerState -eq "PoweredOn" } | Select Name | Export-CSV c:\Scripts\Shutdown\PowereredOnVMGuests.csv

Another important addition to the script.  Basically this dumps a list of the powered on VMs to a csv file.  This will be used in the partner power on script once power has been restored.

The rest of the script is pretty straight forward.  Basically sets DRS to manual mode, disables HA, gracefully shuts down the VMs (any without VMware Tools installed get a hard shutdown), waits a couple of minutes and does another pass, then procedes to shutdown the hosts.  Again, the complete poweroff script can be downloaded here.

Power On the VMs

So all is good, VMs got powered off, but what happens when power comes back up.  Even if you do get your hosts powered back on they aren’t going to turn on your VMs automatically.  Now I know there is a start and stop with host setting but when you are in a DRS cluster this doesn’t do you much good as it is a host setting and VMs move between hosts.  Thus the power on script!  So this script will sit on the same box as your shutdown script.  It needs to be outside of your virtual infrastructure.  My vCenter Server is a physical box so I have placed both the shutdown and the power on scripts there.  Also, you will need to have this script be triggered on start-up for this machine.  This is simply do to the fact that I don’t want to be running any scripts in the middle of the night if power is restored…I’d rather walk in to a fully functional datacenter the next morning 🙂

The full script can be downloaded here but below are a few explanations of what happens….

if (Test-Path $filename)

The complete script is wrapped in this if statement.  Meaning if the power off dump file doesn’t exist then the script will not execute.

    while ((Get-Service vpxd).Status -ne "Running")
    {
        Write-Host "." -nonewline
        Sleep 2
        Write-Host "." -nonewline
        Sleep 2
        Write-Host "." -nonewline
        Sleep 2 
    }

This repeating loop basically waits for the vCenter Service to be started before the script can continue.  Since this script should be executed during startup we may have to spend some time here waiting for vCenter to get all its ducks in a row 🙂

    foreach ($iVM in $myImportantVMs)
    {
        Write-Host "Powering on $iVM ..." -nonewline
        Start-VM $iVM
        Sleep 5
        Write-Host "DONE" -Foregroundcolor Green   
    }

Before reading the dump file and getting into the thick of everything we have the option to power on some of the more important VMs first.  So if you have any mail servers, dhcp servers, dns servers, it would be a good idea to put them into $myImportantVMs to have them started first. Once these VMs are on a similar type function will power on the rest of the VMs in the csv file, one by one, every 5 seconds.  You can set the sleep command to whatever you want but 5 seems good for me.

    rename-item "$fileName" "$nameOnly-$DateStamp$extOnly"

This is nearing the end of the script and basically appends the date to the csv file.  This prevents the script from running on next startup – unless you have another power outage of course.

So there you have it – a complete power off script and a complete power on script.  I know I’ve rambled a little bit in the post but I’m just in that sort of mood.  If you need a hand setting things up or have any questions, concerns, improvements, criticism don’t hesitate to leave them in the comments.  I’ll get back to you….  And yes, my tomato plants are all dead!