OVF Template Failing To Deploy

When trying to deploy an exported OVF template into another vCenter and cluster, I was presented with a strange error which seemed to indicate that I’d not specified which datastore to deploy to, which was odd because I most certainly had. The error I saw is below;

Failed to deploy OVF package. ThrowableProxy.cause A specified parameter was not correct: Target datastore must be specified in order to deploy the OVF template to the vSphere DRS disabled cluster

A quick Google search for this gave nothing, which is usually a bad sign, but the fix for this was rather simple, when presented with the storage you want to deploy to and you pick the relevant datastore;

6

If you then go and click on advanced, you’ll find that only one of the disk groups has been allocated to the datastore you picked for some reason;

If you then click edit on the disk group that doesn’t have a datastore, you should then be able to pick a datastore for that and the OVF will then deploy. This was all seen on vCenter 6.5 Update 2 (build 6.5.0.20000) but it may affect other vCenter versions.

Quite Impressed With Microsoft’s Hyper-V

I realise I’ve not posted for a while, and I’ll try and atone for that going forward, I’ve been a busy server guy at work, but onto the good stuff.

I know Hyper-V, I’m not new to the existence of Hyper-V, but I’ve only ever briefly touched it in lab environments, until recently.

I had cause to do a number of small site deployments in the US on Hyper-V, my first choice being for a proper VMware setup with vCenter and a shared storage platform, but for one reason or another, my hand was forced and I had to go in guns blazing with Hyper-V, no shared storage and no Microsoft System Centre Virtual Machine Manager (SCVMM) either.
For those that haven’t looked at Server Core installs yet, firstly, why not? Secondly, please do, it’s a great feature of Windows Server for enterprise and business setups and something that Windows Server nerds everywhere should be doing more of.
I’m happy with PowerShell, so deployment wasn’t hard, that’s not to say I’m 100% au-fait with every set of cmdlets on offer and know the whole she-bang inside out, but it’s pretty easy to get going. Once the install was done and networking configured (loving the native NIC teaming since Server 2012), Hyper-V role installed and servers fully patched it was time to start actually configuring the thing. Again, Microsoft have made the whole thing fairly straightforward via the Hyper-V console and since I’m not a PowerShell martyr, I use it where things are easier but use the GUI where it makes sense for some things, I was happy to proceed in the GUI for some of the config.

So, onto what I liked, the live migration with shared nothing is great, although something I know ESXi also has. The replication of a VM between hosts, and the ability for one of those replicas to effectively be powered on in an unplanned failover scenario is great and failed back when things are working as planned again. Ok, I know it’s not a full HA setup in the sense that it requires intervention for it to work, but it’s a step up from what you get with just ESXi without vCenter.
Hot-add of memory is now available in Hyper-V since the Server 2016 version, as well as hot-add of network adapters, which brings it a lot of the way towards VMware’s offering in terms of hot-add features. PowerShell Direct is amazing, the ability to have a console-esq PowerShell session to a guest OS from the host regardless of networking or firewall is great.
Obviously there are some things missing from Hyper-V still, vCPU hot-add being one, but not one that I personally use too often. The HTML5 interface of the later iterations of VMware’s product are also great, no need for an installed application to manage the thing is always good news.

Hyper-V can easily suffice for small scale deployments and is well worth a look these days. In it’s current evolution it’s a big leap from where it was in it’s Server 2008 days. As time goes by, there really is getting less and less between Hyper-V and ESXi, and that can only be good. No one benefits from a monopoly position, with the exception of the monopoly holder, so it’s good to have some healthy competition in the market and I look forward to seeing what Microsoft can do with the platform in the future.

HP VMWare VIB Sources Not Connected – HP Killed The Old Pre-Rebrand URLS

I noticed today that when in the VMWare Update Manager in admin view, some of the custom VIBs I had in were showing as “Not Connected”. This was my custom location for HP VIBs of http://vibsdepot.hp.com/index.xml as I use the HP image on the hosts in this vCenter. When I forced VUM to check the URL again, it was coming back again as “Not Connected”. So I thought I would try loading the XML file in a browser, which presented me with this lovely little “notification”;

HP_VIB_Redirect

I say “notification” as what they’ve done is use a redirect to point you to a different URL, which then contains the message that you must use a different URL now.
The new HP VIB URL is https://vibsdepot.hpe.com/index.xml and note the https rather than http.

Adding the new updated URL to the XML file get’s us right back into a connected state;

HP_VIB_Connected

This has obviously been done following the HP and HPE split that was announced a few years ago, but which is obviously just starting to have consequences for things like this.

I hope this helps someone out.