This site has been formed to contain my ramblings about things on my mind related to technology I work with.
I would call myself a techie guy who has lucked out and had a great career doing what i love, working with new emerging, innovative solutions. As an engineering guy I hope to provide good insight into the technologies and challenges faced working with new tech and a personal view into what they are and the problems they solve.

Thursday, 27 February 2014

Damn, SCVMM Not Supported

Funny, but sometimes changes occur with very little warning and SCVMM 2012R2 has had some that I keep tripping over. Within the fantastic EMC Solution Center in Sydney, Australia which I am fortunate to have a great collection of toys (oops, I meant IT equipment) to play with (again... I meant to say develop and test against) I have come across this issue a few times but find it very difficult to dig up information related back to it.

It relates to the extensive and must say, fantastic set of PowerShell cmdlets that come with System Center Virtual Machine Manager. Firstly the initial changes were very obvious, 2008->2012 the cmdlets started to prefix the command with 'SC', An example of this is that Get-VMMServer became Get-SCVMMServer.

This in itself makes absolute sense, you need a unique identifier when your environment could have multiple libraries that may provide the same cmdlet such as happens with a cmdlet like Get-VM which is supported by vSphere, SCVMM and Hyper-V Powershell libraries so no problem there. What did happen though is Microsoft, I assume to soften the impact, did support the old cmdlets via aliases. These aliases were retired with the release for 2012R2 which I also fully understand as you need to move on eventually, so whats the problem?

The issue is that not everyone has moved onto the cmdlets even though they have had a good chunk of time. My guess this may be because they didn't need to change so why bother, until now. Anyway I have been caught out with this issue with products from both Microsoft (e.g. Team Found Server's Lab Center) and VMware (vCloud Automation Center).

So if you find something is not supporting SCVMM 2012R2 but did 2012SP1, this is not a bad place to start looking at when trying to determine why.

So It Is Not Just Fluff!

Funny, for years now I have been I have been talking, presenting and building Cloud based services, in the early days I just did not realise it. It was at VMworld in 2009 that the term Cloud first got passed around in a way that every vendor seemed to be jumping on it and attaching it their product lines. The reality is though was that there was no clear definition of what was a Cloud.

So what is a Cloud Service, firstly it needs the following

Automation: delivery and lifecycle management needs to be automated which in turn, done properly, reduces risk and increases agility. Delivering a Virtual Machine to a client in 7 days (or even a day) does not represent what a Cloud is meant to provide the customers. This has a preceding activity, processes need to be well defined, no use automating something to be delivered as-a-Service without knowing all the speeds and feeds that relate to it. Lifecycle is also critical, need to ensure that you don't end up with VM sprawl.

Assurance: There needs to be a way that the administrators and customers are aware of the integrity and performance of the service. This directly feeds into operational health and performance monitoring, chargeback/showback facility and service assignment states. A customer and administrator need to know how well a service is run, how much is consumed and how compliant it is to the SLAs assigned to it.

Self Service: There needs to be an electronic shop front to the services on offer. A cloud is consumed on demand as is the norm now for the general tablet and smart phone community as provided by Google Play, Apple and Microsoft Stores. This in turn leverages automation to provide the requested service. Can you imaging grabbing an app from your iphones stores and then waiting a month for it to be available :)

So interestingly there have been a number of products available that were either the good friend of the consultants who then were charged with the implementation of them, or just not good enough to be taken seriously when looking at your Data Center, really just pimped up provisioning engines.

This is where the Software Defined Data Center comes in and all the related services. The SDDC to me is providing two critical functions

The enablement of automation

The extensibility of the capabilities of existing physical assets, think what VMware has done to your servers with ESX but across the rest of your DC assets including networking and storage

Looking at Infrastructure-as-a-Service, the two primary go to solutions are vCloud Automation Center (VCAC) from VMware and the new kid on the block, the Windows Azure Pack (WAP) from Microsoft. Both of which are positioned as platform neutral and providing the shop front to your DC services. The each have good and bad points, I will look to cover them in future posts.

You also the SDDC enabling solutions coming in thick and fast, think VMware with NSX for networking, EMC with ViPR for storage, Microsofts all Infrastructure embracing System Center supporting automation of bare metal hosts, virtual machines, networks through the virtual networking stack and storage management.

The point is, in the past 1000s of hours in scripting and coding was required to enable a cloud (it kept me busy so I didn't mind myself), now it is becoming reachable with the push towards the SDDC and the maturing and simplification of the service management solutions.

What makes me think this, well it use to take months to get a service up and running for POC following the fundamentals of the Cloud as listed above. I would also spend a fair bit of time deep in some form of IDE cutting code.

Now I find myself complaining when it takes me a few days to build one up from scratch or POC in a few days.

Blogging is an interesting activity, with stars in my eyes I committed to starting this blog as a place to record my activities in the world of virtualisation. What I did find though as I spent so much time focused internally within EMC and on our customers that the blog was initially postponed and eventually, forgotten.

Now here we are 3 years after the first entry and I am committed to starting it again. In the interim I did have my friend Scott Drummonds post a few of my activities within his blog vPivot but even he has now re-focused on new exciting streams an has also left EMC so back to doing this myself :)

Anyway as one of the early vSpecialists (VMware) and now an mSpecialist (Microsoft) I work day in, day out within EMCs cloud based solutions covering both VMware and Microsoft platforms. As a consequence I get my hands dirty with both which allows me to get to know the good, the bad and the ugly of both.