Using SmartCloud Orchestrator to Provide Your Lab Virtualization Needs
crosen 060001U4XN Visits (1642)
Like most other companies, IBM has faced a lab (asset) transformation initiative to replace physical servers with virtual resources over the past few years. This initiative has affected every development, test, and support engineer and this blog outlines how one L2 support member leveraged the SmartCloud Orchestrator (SCO) environment.
If you were anything like me, you may have been a little protective of the physical lab boxes you had acquired over the years. The idea of surrendering those machines in favor of virtual machines didn't seem like a good idea at the time, at least not to someone who had very little exposure to virtualized environments.
Admittedly I starting venturing into the virtual world out of necessity as my physical lab boxes started failing one by one. I started to realize how convenient they could be, especially given how many times I had needed to rebuild some of my past physical boxes from the OS up.
Eventually I found I could do everything with virtual machines (VM) that I had done with physical assets. In fact I could do more because of the conveniences that virtualization offered.
By now, many of you are likely using the virtual environments for your lab needs and immersed in the virtual world. In most cases, this has improved our lab management efficiency and it has saved IBM money. However, even these virtual infrastructures have their limits from the perspective of how many individual VMs can be provided. We are constantly being asked to justify our need to hold onto VMs. So like the good old days of physical assets, we've once again started hoarding the virtual assets we have been assigned, even when they are under-utilized.
Well now there is a new cloud based virtualization infrastructure available to us that offers to provide VMs on-demand. Internally the C&SI (Cloud and Smarter Infrastructure) IT team provides a SmartCloud Orchestrator cloud. However it differs from the previous enterprise virtualization, in that these VMs are supposed to be short lived; you use them and then hand them back when done. For example, say you need a recreate environment for a particular PMR (Problem Management Request), once you're done with the PMR, you would delete the VM.
I know what you're thinking...why would I put so much effort into deploying and customizing a VM, for example, installing the product I support, only to delete the VM shortly after? This is where SCO can offer you more than you think. You would use SCO to deploy new VMs on-demand from a list of available OS patterns. But in addition, you can create new patterns that go beyond just providing a base OS. Let me explain what I have managed to do with "patterns" and "script packages" within SCO.
Gareth Holl is a Senior Software Engineer at IBM in the Cloud & Smarter Infrastructure support organization.