To use place the netconfig.js file in the c:\scripts directory from the system you are running the set_vmnic.ps1 from. Any questions on arguments just launch the set_vmnic.ps1 from vmware powershell.

Also working on a “remove program” powershell script as well as a “rename/join domain” powershell script.

This blog for security reasons will not allow a script to be uploaded.
So please rename set_vmnic.ps1.doc to set_vmnic.ps1 and netconfig.js.doc to netconfig.js once downloaded. set_vmnic.ps1

The design we have been working with consists of stretched clusters, NetApp metro clusters, with Overlay Transport Virtualization (OTV) for site failure. With all of this in place, the site failures should be seamless, but security constraints mentioned before coupled with all of these technologies presents some challenges as well as benefits:

-  The multi tier design mandated by the security group gives physical separation to each tier, along with limited communication. The communication is also done on an IP to IP basis; as opposed to a range being allowed.

-  There is no common management network between the tiers giving a constraint on host communication.

Once we understood the design limitations and constraints of the customer environment, attention was focused on the primary customer requirement: the self- and post-provisioning of virtual machines to all tiers in a single request.  Additionally, the customer wanted a simple user interface that did not require advanced knowledge of the customer’s multi-tier cloud architecture.

One of the proposed solutions we have designed is a vCO (VMware Orchestrator) and vCD implementation using the new Notifications (callouts) feature of vCD 1.5. In this solution, we leveraged some of the existing scripts that had been written for post provisioning tasks at the client. The process design on a high level:

            – The first problem we had with this approach was that a single request could not comprise multiple-tiers in vCD.  We were going to use a VCO front end to actually make 3 vApp requests from a single interface.  

This addressed the design issue we were faced with, but added some complexities to the environment as well. Since we cannot layer post provisioning tasks onto the service catalogue entries, we needed to have a small script call on other scripts in order to complete the tasks. To meet all of the different types of deployment tasks, we need to have some sort of custom attribute or description for each vApp request in a CMDB which VCD could consume, growing it exponentially. Having those attributes in vCO causes a need for a different service catalogue entry for each type of deployment as well. In a nutshell, a single template may need dozens of different service catalogue entries. based on this logic we would be looking at: 4 Source VMs * number of deployments.  Even if you use the same base images for 8 more SCatalog entries, before deployment, you’ll have 9 catalog entries * 4 VMs ( 9 * 4 = 36 VM templates in the catalog).  Now imagine you have to apply critical patches to your 4 source VMs….you’ll have to patch every one, or recreate the service catalog. 

I think vCD is the approach we would like to take, but to get there I think there might be some obstacles to overcome and make it much easier to adopt:

1. A more customizable UI, perhaps with hooks for vCO into the service catalogue, instead of the individual VM’s. There can be a custom UI for the users (not in this client….), but I think being able to modify the current UI to meet the requirements may be a better option.

2. A way to link multiple physically separate tiers with a single vCD cell. Perhaps unifying the provider vDC’s, (very challenging considering the compute resources defined by provider vDC’s). vShield is not an option for the client currently.

3. I would also like to see a way to choose the data store/provider vDC/Org vDC we go to during deployment for certain cases. During the deployment process, I if I could make these selections; I could potentially place two VM’s in a vApp in tier 2, and 3 in tier 3, for example. This would allow for one vApp request spanning all of the tiers.

In a future post, I will discuss some other options we have been looking at, vSM, vCM, etc… ; along with further defining the requirements we have had to meet.

“Enhanced passive server management capabilities — A new deployment option allows the passive server to be managed and monitored remotely, this includes receiving file level antivirus updates…”

THIS IS A BIG DEAL!   This allows us to finally use a third IP to manage the vCenter instance while providing both HA nodes their own (unique) primary host IP.  What a relief.  I am very happy to report that this has been the best release of vCSHB I have seen yet and with this feature, it is finally something I would consider putting into production when the time is right.

I included a high level overview below that may help explain:

What may not be entirely obvious here is what to do with the Neverfail IP filter driver. Why do we still need a filter driver controlling ingress and egress traffic on primary interfaces for the vCenter hosts if we now have the VIP?  VMware ensures me it still plays a part but I can tell you we have it turned off and haven’t noticed a problem yet!  :-)

Enjoy!

A few thoughts on the post:

Attrition is a beautiful thing.

I say this because I believe without a doubt it is the easiest and most likely approach to cloud architecture, wether it be public, private or a hybrid cloud model, applications and infrastructure running in our data centers today are not built to take advantage of cloud architectures leaving us with attrition as the most likely method businesses will implement cloud infrastructure.

I could not agree more that companies need to think more about how they will embrace cloud and what it means to their specific business rather than how a given tool chooses to deliver cloud services. A blank sheet of paper or in many cases the infamous white board is exactly where one should start.

The “greenfield” notion is one that many of us dream of, thankfully it is one my organization gave us a chance to take head on this year. We chose the name “Clean Room” rather than “Greenfield” since we essentially carved out existing data center space into a clean room to implement a private cloud model that spans multiple data centers and redesigned infrastructure from the ground up. Many organizations will be faced with similar projects and need to ensure they check any previous infrastructure management methods at the door.

Implementing clouds is one thing, designing and hosting applications that are built for them is something entirely different. I honestly think it will be application integration with clouds that we all struggle with and it is not until we integrate applications that we reap the true benefit of cloud.

Thanks as always for sharing your thoughts Ben!

There have been plenty of posts on this years VMworld so I won’t bore anyone with another one but but this VMworld is shaping up to be one heck of a week. Have a great week everyone!

Charlie

I would encourage you to take advantage of this opportunity and begin posting questions or discussing topics of interest.

Here is the link: http://communities.vmware.com/community/cto/

Enjoy!

In this simple example the diagram shows how anyone can begin developing deep integration into their application deployment process using vCenter and vCO, saving significant time and moving closer to the push button infrastructure everyone strives for.

Providing an input file that contains the critical data such as server names, tcServer configuration, F5 load balancer virtual IP and policy information and running this through vCO to deploy within your private cloud you can enable the push button build and configure capability you are looking for.  This holds true for any application really.  Let’s face it – Lab Manager and Redwood combined can’t do this since their extensibility is somewhat limited.  The key here is vCO.  It’s ability to integrate with almost anything and extensible management framework is what brings the power to this equation.

You may be asking – “it can’t be that easy?”  Well – you are somewhat right.  You do need someone who knows the SDK inside and out and a little JavaScript to write custom logic like I outlined.  There are however many out of the box plugins available for vCO.

What is confusing to me is why more ecosystem partners, and companies for that matter, are not writing plugins for vCO.  I don’t know if this is VMware’s fault for not engaging with more partners on vCO or the partners don’t see the value. It could also be that everyone is counting on vCenter integration providing the integration but let’s face it, customization specifications haven’t changed much since they were introduced.

Whatever the case may be it is time for this to change! It’s time for vCO to find it’s place it the world!

I have recently been working with some smart folks on beginning to use vCO for deep automation within vSphere and extending that automation into the application stack for vApp deployment and am very impressed and confused all at the same time.  I am impressed at the extensibility of Orchestrator and seemingly limitless possibilities of the framework but also perplexed at what seems to be only a few companies actually using the product.  Nevertheless I encourage everyone to explore what vCenter Orchestrator can do.

In thinking about “how the pieces fit together” I came up with a simple drawing below. Please beware this is simply how I see the world of integration from a high level…  :-)

A couple good links by the vCO Team…
vCO Team Site (a rather new but excellent site by the vCO team)
VMware’s Official Orchestrator Community:

Mike DiPetrillo Speaking on vCloud

While I am sure there is plenty to discuss on this topic (much of which would surely get me in trouble – gotta love NDA’s)  I can say that this is something I think about constantly and have discussed with many of you s0 for now, enjoy Mike’s video if you haven’t already!

- Charlie