Subtitle: And How I Rolled It Out
The company I work for is an IT consulting firm that does all sorts from infrastructure, application (BI) consulting, and business solution development. My team (infrastructure) provides client services and manages our internal IT.
Up to now, it pains me to say, it’s been all ESXi. It was free and it just works. But that free came with a price: no centralised management, and it was completely IT driven.
A business requirement came along that I knew I could sort out with VMM 2008 R2. We also had a requirement for more virtualisation capacity. Hyper-V to the rescue – and I also saw how I could introduce a private cloud using SCVMM SSP 2.0:
- It would allow the various IT consumers in the business to deploy their own VMs without waiting for availability in my team.
- We would spend less time doing repetitive lab deployments.
- We could control VM sprawl with quotas based on real GB figures (we aren’t cross charging).
So Hyper-V, VMM, and SCVMM SSP 2.0 were all installed. The VMM is a physical server with lots of SATA disk because I live in the library. Generalised VHDs for various required OSs were created. I created 3 hardware profiles. From those I have 3 templates for each OS version/edition VHD. For example, there’s a W2008 R2 VHD with 1GB RAM, 4 GB RAM, and 8 GB RAM templates.
SCVMM SSP 2.0 was installed in a VM. I wanted to separate it from VMM to give me more modularity and flexibility. Each team has a business unit and an infrastructure. I’m creating those for the teams because … well … the forms are a little complicated and I’ll catch heat if I ask the team leaders to complete them (requiring billable time to figure them out first). It’s just easier if I do that stuff. All that remains for them is to manage their VMs.
All the templates are imported and available to all of the infrastructures. Each business unit is capped by RAM and disk GB.
For each BU, I deployed a VM based on the team’s current requirements. That gave me (1) a chance to test and (2) something to demonstrate with when showing them the SSP 2.0 portal.
Deployed VMs get static IPs from an SSP 2.0 managed pool. BGInfo displays that info on the console. They can “KVM” into the VMs using the portal or they can RDP in.
BTW, I am using a signle AD group for the membership of each BU. Tradtional security is best. I temporarily use a non-admin domain user to provision each new BU and infrastructure.
A document is on the way but these are technical people. I sat down with a rep from the first team earlier this afternoon and walked through the process of deploying, accessing, and destroying VMs. After 5 minutes of a walk through, the first consultant was rocking and rolling.
Lessons learned?
- I’m having some trouble with static IPs and W2003 R2. That requires more investigation and work. I’m thinking it’s an IC issue.
- There’s no way to mount ISO files from the library in the SSP. The solution I am thinking of is to reveal the original SSP from VMM. It’s ready and the self-service user roles are created (without VM create rights). That can be used to mount ISOs. Twice the admin work required.
- There is no way to change the spec of a deployed VM in SSP 2.0. That is badly needed. We’re making changes in VMM but SSP doesn’t see those changes, leading to …
- I find myself diving into SQL to edit stuff that is not revealed in the portal. For example – renaming a BU. Or changing the spec of a VM isn’t reflected in SSP and therefore not in the quota usage. That sucks.
- If SSP and VMM lose contact with each other during a VM deployment then SSP considers the job failed, even if VMM continues with it without any issues. SSP 2.0 needs an import feature (see next).
- SCVMM SSP 2.0 SP 1.0 is needed badly.
- I did consider using the original SSP instead of SSP 2.0. But the crude quota mechanism and the inability to assign static IPs was too much of a step down.