In my last article, I started a discussion about automation and the tools of the trade for automation and orchestration. The post focused on Microsoft PowerShell as one side of the automation coin—one of the primary tools of the trade when working within Microsoft, VMware, and Citrix virtualization and orchestration solutions. Why PowerShell? Quite simply, it’s a powerful platform that has a robust community supporting it, and companies outside of Microsoft have invested a great deal of time and development to integrate PowerShell into their main administration and management platforms for working with VMware vSphere and Citrix Xen. So, if PowerShell is one side of the automation tools coin, what’s on the flip side?
Articles Tagged with PowerShell
In my last article, I spent a little time talking about the difference between automation, which is an automated task or scripted solution to perform a task, and orchestration, which is the complete process. I topped it all off with a discussion about how DevOps is a philosophy driving orchestration. For this article, I want to focus in on the some of the most common tools of the trade behind the automation and orchestration for different types of environments.
Strategy for cloud automation: there are a lot of articles about the cloud and cloud computing, but I have not seen too many that discuss different strategies to consider when it comes to the automation in your environment. I did come across a nice post called “Legacy Job Schedulers: 3 Effective Exit Strategies to Consider,”1 by Jim Manias from Advanced Systems Concepts, Inc., that had some interesting points and thought it would be a great topic for discussion.
Microsoft Windows Server 8 Beta has been open to the public and there is one feature that really caught my eye. With Windows Server 8 you can now have basic PowerShell console over HTTPS with Microsoft Windows PowerShell Web Access (PSWA). Think about the possibilities with that. You get an email that there is an issue and you could start PWSA on your phone, or other device, and resolve the problem or request.
In the past, virtualization architects and administrators were told the best way forward is to buy as much fast memory as they could afford as well as standardize on one set of boxes with as many CPUs as they dare use. With vRAM Pool licensing this type of open-ended RAM architecture will change as now I have to consider vRAM pools when I architect new cloud and virtual environments. So let’s look at this from existing virtual environments and then onto new virtual and cloud environments. How much a change will this be to how I architect things today, and how much of a change is there to my existing virtual environments? Is it a better decision to stay at vSphere 4? Or to switch hypervisors entirely?
Yesterday, Simon Bramfit vSphere 5 – Did VMware Misjudge its Licensing Changes? requested a VDI only version of vSphere and yesterday VMware responded with vSphere Desktop which for VDI removes the vRAM Entitlement barrier. I see this as progress and that VMware is listening. Unfortunately, this is for new purchases and you cannot convert existing vSphere licenses into vSphere Desktop licenses.
Existing Virtual Environments
Unless you have been on vacation or hiding under a rock then you have heard the latest buzz in the industry that vSphere 4.1 has been released. There have been a lot of blog posts on the topic already including one of our own. The thing I want to hit on for this post is the fact that this release will be the last release for full version of ESX. Moving forward on any new releases of ESX will be strictly ESXi. Anyone that knows me over the years knows that I have not really been a big fan of getting rid of the full version ESX. Call me old school and the fact that I have spent a great deal of time developing the automation used in the environments that I have supported over the years and have been really happy with what I was able to accomplish via kickstart and the command line.