I have been using the free version of Veeam Endpoint Backup (VEB) product since it was first released and it works wonders. Really good software that just keeps getting better and better. You can not only backup desktop and laptops but also VMware virtual machines with PCI pass-through devices which Veeam Backup & Replication 9 cannot properly backup since snapshots are not allowed when PCI-e devices are in use. Another good use case for VEB is the ability to backup Hyper-V hosts themselves. I have a large number of Hyper-V boxes dotted around and although I use Veeam Backup & Replication to backup the virtual machines I still need some sort of backup for the hosts. VEB fills this gap perfectly and in the unlikely event of a disaster, I would use VEB to restore the host (C drive i.e. the OS) and Veeam B&R to get my virtual machines back (D drive where the VMs sit). This setup works really well and I already had to use it once!
One thing however that didn’t quite make to the GUI yet is the slightly annoying fact when you point the backups to SMB share and change the hostname of the source machine the backup name doesn’t reflect the new hostname within the share. In my example my Core i3 test bench used to be called DESKTOP-9H9LL2J but now I have changed its name to SPN-TESTB-01 to comply with my standard naming convention. In an ideal world the backup folder should also change its name but that’s not the case. Here are some examples, hostname has been clearly changed to DESKTOP-9H9LL2J:
More SSLv3 (Poodle vulnerability) woes as this time NetApp VSC 5.0 is broken!
So my vCenter 5.5 update 2a got updated to update 3e without much of a problem but SRM and VSC are busted now. Great. Virtual Storage Console sort of works but the backup jobs tab hasn’t got any entries and you cannot re-create them due to the following errors:
Unable to connect to Virtual Storage Console server. Please make sure that the Virtual Storage Console server is running.
To cut this long story short – if you have vCenter Server 5.5 update 2 you will have issues if you patch your hosts to the latest available patch level for ESXi. VMware disabled SSLv3 (POODLE and all that..) in update 3b for ESXi meaning if your vCenter Server is running update 2 you won’t be able to connect until the vCenter is patched to update 3b as well. Running ESXi hosts on update 3b and having vCenter Server on update 2 is normally a perfectly valid configuration but because SSLv3 got disabled as part of this process the connectivity is broken.
Example error messages in vpxd log file when patched host in being added to vCenter Server include:
2016-02-26T15:47:12.729Z [07448 error 'HttpConnectionPool-000001'] [ConnectComplete] Connect failed to <cs p:0000000017ddfdf0, TCP:spn-esx-04.alex.com:443>; cnx: (null), error: class Vmacore::Ssl::SSLException(SSL Exception: error:140000DB:SSL routines:SSL routines:short read)
2016-02-26T15:47:12.729Z [07400 error 'httphttpUtil' opID=30D532A7-00000053-90] [HttpUtil::ExecuteRequest] Error in sending request - SSL Exception: error:140000DB:SSL routines:SSL routines:short read
2016-02-26T15:47:12.730Z [07400 error 'vpxdvpxdHostAccess' opID=30D532A7-00000053-90] [VpxdHostAccess::Connect] Failed to discover version: vim.fault.HttpFault
Pretty silly thing to do really – I have left the default site name when installing SRM 5.8 so it has FQDN of my vCenter box instead of a proper name:
From vSphere Web Client point of view having FQDN in there is not ideal as well as introducing confusion which site is which (live vs. recovery):
To get the site name changed we need to edit vmware-dr.xml which lives (by default) in the following location:
I have been struggling to fix this rather weird disk space issue for quite some time now. Basically, underlying thin provisioned disk on vSphere 5.5 was extended by additional 5GB (from 125 to 130GB) and extended using Disk Management from withing the OS as per the normal routine. No problems thus far BUT Explorer in Windows Server 2012 R2 was not reporting the increased space and was still showing the 125GB total size! How odd. Here is the screenshot for illustration purposes showing Disk Management and Windows Explorer both reporting different values!
I must have done the disk space increase from vSphere and extension from the guest OS hundreds of times and never had any real issues. There are tons of potential solutions to this problem, quite a few posted here:
CrashPlan woes continue!
This error is from an earlier version of the CrashPlan software i.e. 4.3.0 which one of my customers is still running. So here it is – fully appreciate you won’t be able to read native Polish language but the error reads as:
“Unable to connect to backup engine, retry?”
Monday mooning eh? It surely is!
Trying to install CrashPlan 4.4.1 (CrashPlan-x64_4.4.1_Win.exe) is proving to be a lot more hassle than it should..
Error messages shortly after kicking off the .msi installation:
The CrashPlan Setup Wizard ended prematurely
CrashPlan setup eneded prematurely because of an error. Your system has not been modified. To install this program at a later time, please run the installation again.
Click the “Finish” button to exit the Setup Wizard.
Cleaning up NetApp SnapManager for Virtual Infrastructure snapshots in VMware vSphere can be a pain if you have large number of VMs being backed up by SMVI. In my case there are snapshots that are consistently left behind like so:
which just pile up as the days go on. I think this is some sort of bug in either vSphere API or the way NetApp handles snapshotting during the backup window.
To have these snapshots cleared up after the backup jobs run I have written the following PowerShell script to deal with the situation:
Lenovo ThinkServer System Manager default username and password are as follows:
Both username and a password are case sensitive. Please notice there is a zero ‘0’ and letter O in word len0vO..
Took me a while to work it out but there you have it!
I thought that it would be a good idea to finally install vCenter Multi-Hypervisor Manager to manage my 3rd party hosts i.e. Hyper-V – at least that was the initial idea anyway since I don’t have enough time to mess around with SCVMM for now. Multi-Hypervisor Manager server installation was pretty straight forward and so was the client. With plugin enabled in vSphere C# client I was able to see the relevant icon in my client:
but the next screen was not so pretty:
Basically ‘NoPermission’ but I can access vCenter server just fine since I have all the relevant rights! It turns out Multi-Hypervisor Manager assigns the default ‘Admin’ role only to the user specified during the installation of MHM and no one else. During the installation of MHM you have to specify the account that will be made administrator of the third-party hosts inventory: