Posted on

vCloud Automation Center – vCAC 5.1 – Connecting to vCenter

In my last post I covered how to connect vCAC to Amazon EC2 which I hope was useful for many it appears to have received a lot of attention.  In this post I’m going to walk you through how to connect vCAC to vCenter.  Be sure that you have completed the steps in the below posts before you connect to vCenter:

What were going to configure

In order to configure vSphere integration we are going to setup some additional components of vCAC as outlined below:

  1. Credentials -Credentials will be utilized by out endpoints to authenticate us to the infrastructure element managers that we are going to communicate with.
  2. End Point – Endpoints are how we manage connections from vCAC to other infrastructure elements in the environment. There are endpoints that allow us to communicate with EC2, vCenter, vCloud Director, vCenter Orchestrator, Hyper-V, NetApp Filers, as well as Physical Servers such as HP iLO, Dell iDrac, and Cisco UCS.
  3. Install the vSphere Proxy Agent – The vSphere proxy agent is like a DEM, only it has pre-programmed workflows that perform a specific function. In this case the function will be to communicate with vCenter. Proxy agents are a bit legacy and will hopefully be ported to the new DEM architecture in the future.
  4. Enterprise Group – Although we already created an Enterprise Group we are going to add vSphere Compute Resources to the group in this exercise. For more information on what Enterprise Groups are see my earlier article “vCloud Automation Center – Laying the foundation“.
  5. Reservations – A resource reservation is how we provide available resources to our provisioning groups. Resource Reservation are a one to one mapping to provisioning groups. Resource reservation will get created for any type of resources you want to make available to your groups. In this exercise we will be creating a virtual vSphere reservation.
  6. Global Blueprints – A Blueprint is really a service definition that details what the consumer can request and all the policies and configuration of that service. We will create a virtual blueprint that a consumer can request through the service catalog in this example. I will cover Blueprints in greater detail in another article.

Continue reading “vCloud Automation Center – vCAC 5.1 – Connecting to vCenter”

Posted on

vCloud Automation Center – vCAC 5.1 – Amazon EC2 Configuration

Usually most people go straight for connecting vCAC to vCenter, but I have decided to connect to Amazon EC2 first. I’m doing this for a few reasons, but mainly because anyone reading this has access to EC2. All you really need is any computer with a Desktop Virtualization tool like VMware workstation and you can test vCAC with Amazon EC2. If you don’t have an Amazon AWWS account go to http://aws.amazon.com and sign-up.

Signing up for Amazon AWS is free and what’s even better is you can also provision “Micro.Instances” for free for an entire year as long as you stay within these guidelines. The basics are this:

  • 750 Hours of Linux/Windows Micro Instance Usage per month. (613Mb Memory). This is enough to run a single micro instance for the whole month.
  • 750 Hours of Elastic Load Balancing plus 15GB of data processing
  • 30GB of Elastic Block Storage
  • 5GB of S3 Storage with 20,000 Get requests and 2,000 Put requests
  • And some other goodies…..

You can run more than one micro instance at a time as long as the consecutive run time of your machines doesn’t go over 750 hours a month. Once you provision an instance it automatically counts as 15 minutes used. I don’t bother trying to calculate by the 15 minutes so the way I look at it is I can perform 750 provisioning tests per month if each test is less than an hour.

Continue reading “vCloud Automation Center – vCAC 5.1 – Amazon EC2 Configuration”

Posted on

vCloud Automation Center – vCAC 5.1 – Laying the foundation

Before we really start to dig into the fun stuff we need to dig a footing and lay a foundation to build on. In this article I’m going to create an “Enterprise Group“, a few “Machine Prefixes“, and create a “Provisioning Group“. For those not familiar with these let me explain:

Enterprise Groups

Enterprise Groups contain “Enterprise Administrators” and “Compute Resources”. When you create an “Enterprise Group” you will give it a name, assign those that will be the “Enterprise Administrators” and select the “Compute Resources” that they manage. The general concept of the “Enterprise Groups” is let’s say you have a group of administrators that is responsible for managing infrastructure in North America, but you also have a separate group of administrators that is responsible for managing infrastructure in Europe. You can create (2) “Enterprise Groups” one for NA and one for EMEA and in the groups you can map the appropriate administrators to the “Compute Resources” they manage. This allows you to separate access to the infrastructure to the appropriate admins.

Provisioning Groups

Provisioning groups contain your users of the infrastructure. These are the users that will make requests for servers or applications and consume resources that are provided by the ‘Enterprise Groups” Provisioning Groups have a few roles that make them up. The roles are:

  • Group Manager Role – The PGMs oversea the group, can access all the machines in the group, can publish blueprints to the groups, can work on behalf of the group users, approve requests made by their users and other groups based administration functions.
  • Support User Role- This role is intended for your help desk organization. The role allows the assigned user(s) to work on behalf of the groups users to aid in troubleshooting machine issues.
  • User Role – These are the consumers. The users are the consumers of the servers, applications, and resources in your environment. They can only gain access to what has been provided to the group(s) that they belong to.

Continue reading “vCloud Automation Center – vCAC 5.1 – Laying the foundation”

Posted on

vCloud Automation Cetner – vCAC 5.1 – DEM Installation

In this article we are going to walk through the installation of both the Orchestrator DEM and the Worker DEM. Once vCAC is installed in order for it to process workflows it needs at least one of each. There are a few gotchas during the installation so play close attention.
  

Watch the video tutorial!

Running the Installer

1. Locate the “DCAC-Dem-Setup” file, “right click” and select “Run as administrator”

VCAVDEM-1

Continue reading “vCloud Automation Cetner – vCAC 5.1 – DEM Installation”

Posted on

vCloud Automation Center- vCAC 5.1 – DEMs Demystified

There are two types of DEMs that are used within vCAC.  Those are:

  • Orchestrator DEM
  • Worker DEM

 

DEMs in General

You have to have at least one Orchestrator DEM and Worker DEM, but depending on the size of your environment you may have more than one of each. You may have more than one of each for redundancy purposes as well. DEMs can be installed in active-active pairs providing full resiliency for each other. DEM’s communicate with the vCAC Model Manager to receive work items that need processing. The really nice part is they pull from the Model Manager, the Model manager doesn’t push items to them. This is very helpful if you need ti utilize a DEM in a fire-walled environment.
Continue reading “vCloud Automation Center- vCAC 5.1 – DEMs Demystified”

Posted on

vCloud Automation Center- vCAC 5.1 – vCAC Manager Installation

Before starting the installation you should login to the server using the account that you have setup with permissions to your SQL database server. If you are using a local SQL Express instance you can login with an account that has permission to the local SQL Express. The account should be a domain account in the domain that you joined the server to. If you intend to use the same account as the service account for the installation make sure the account has the “Run as Service” privilege on the local server. If you haven’t already done so you should read “VMware Cloud Automation Center – What to know before you install.“

Watch the video tutorial!

Installation Overview

The vCAC 5.1 Manager Installation includes a few components you should be familiar with. The components are:
Continue reading “vCloud Automation Center- vCAC 5.1 – vCAC Manager Installation”

Posted on

DynamicOps Delivers Automated, Space-Efficient Virtual Desktop Solution

“The desktop deployment productivity tools that NetApp and DynamicOps offer significantly increase the value of virtual infrastructures by improving performance, providing essential data management resources, and reducing costs,” said Patrick Rogers, vice president of Solutions and Alliances, NetApp. “Enterprises and service providers can now offer multiple, cost-effective service level options for virtual desktop deployments by leveraging the unique orchestration of virtual storage capabilities that are part of the new DynamicOps solution.”

The full release can be found at http://www.dynmaicops.com/news/

Posted on

Creating an Automated ESXi Installer

Back in the summer, I saw Stu’s Post about automating the installation of ESXi. I was reminded again by Duncan’s Post. Then, I found myself in a situation when a customer bought 160 blades for VMware ESXi. With this many systems, it would be almost impossible to do this without mistakes. I took the ideas from Stu and Duncan and created an ESXi automated installer that works from a PXE deployment server, like the Ultimate Deployment Appliance. I took it a step further and added the ability to use a USB stick or a CD for those times when PXE is not allowed. The document below is a result of it.

This is a little different than the idea of a stateless ESXi server, where the hypervisor actually boots from PXE. This is the installer booting from PXE so that the hypervisor can be installed on local disk, an internal USB stick or SD card. You could also use it for a “boot from SAN” situation, but extreme care should be taken so you don’t accidentally format a VMFS disk.

As always, if anyone has comments, corrections, etc., please feel free to post a comment below.

Continue reading “Creating an Automated ESXi Installer”

Posted on

Keep it simple stupid – registering unregistered vm’s

Last week my boss came to me and asked if I could write a script for a customer to register VM’s after being replicated from once VI environment to another.  I agreed to take on the project and go for it.

Like everything I do these days I decided to use powershell to write the script.  I have taken a liking to it and the fact that I can run the scripts on both ESX and ESXi hosts saves me from having to re-create scripts all the time.  So I plugged away to 3am wrote the script, tested it inside out and sideways in my lab.  I was confident in the scripts ability to register all vm’s form all datastores I went ahead and sent it off to the customer.

A few days later I was on a conference call with the customer.  They were having problems with the script.  It wasn’t registering all the vm’s.  After a few hours of troubleshooting I realized that I needed to go back and try to recreate the problem’s in my lab to fix the script, but the customer didn’t have that kind of time.

A short while after getting off the meeting with the customer I received an email from them stating not to worry they had gotten a shell script that worked.  Then I started to think…….  I went in to my lab and created a shell script that would do the job.  The shell script was 5 lines long as oppose to powershell script that is about 40 lines.

The shell script if anyone needs it looks like this:

for v in ‘find /vmfs/volumes/ -name “*.vmx” `
do
echo “Registering $v” >> /log/registeredvms.log
vmware-cmd -s register $v
done

So the short of the story is sometimes it is best to keep it simple stupid.  Utilizing powershell for this problem was just too much overkill and in the end there were issues that were overlooked that I still can’t reproduce in my lab.  A simple shell script is all that was required and what I should have originally decided on.

So in the end this is a lesson learned and hopefully it will prevent someone else from making the same mistake.

Posted on

vSphere Service Console and Disk Partitioning

Everyone at this point should be aware that the Service Console is now located in a vmdk on a VMFS partition.  The Service Console vmdk must be stored on a vmfs datastore and the datastore must either be local stoage or SAN storage that is only presented to the one host.  So I guess no shared vmfs datastores to house all the Service Consoles…….  The next question I had about the new service console was the /boot partition.  Where is it and how is the server bootstrapping?  Well I can’t say I have totally gotten to the bottom of this yet but I have discovered a few things.  When digging into scripting installations of vSphere I first looked at the disk partitioning which sheds a little light on the boot process.  Here is what the disk partitioning portion of the script looks like:

part /boot –fstype=ext3 –size= –onfirstdisk
part storage1 –fstype=vmfs3 –size=30000 –grow –onfirstdisk
part None –fstype=vmkcore –size=100 –onfirstdisk
# Create the vmdk on the cos vmfs partition.
virtualdisk cos –size=8000 –onvmfs=storage1
# Partition the virtual disk.
part / –fstype=ext3 –size=0 –grow –onvirtualdisk=cos
part swap –fstype=swap –size=1600 –onvirtualdisk=cos

Notice the “onfirstdisk” switch at the end of the first three partitions.  The /boot, a vmfs partition, and a vmkcore partition are all on the physical disk.  Notice the swap for the service console is located inside the vmdk.  Notice the creation of the service console vmdk disk.  “virtualdisk cos –size=5000 –onvmfs=storage1”.  To account for this change VMware has added some new configuration option for scripting the installation of the COS.  Next you’ll notice the  the creation of the / and swap partitions fort the COS utilizing the “onvirtualdisk=cos” switch.

I’m still working on and discovering some of the new ways to do scripted installation with vSphere 4.0.  I though this little tid bit would be helpful to those of you wondering how the COS ties in to the whole mix.  A few interesting things about this new method.

No need to specify the actual device, however I would be very cautious about the –onfirstdisk switch if SAN LUNs are present on the server.  I would take extra precautions to ensure that no SAN LUNs are connected.  There really are not any best practices around this configuration yet so there are a few things that I think need to be determined.  If you were planning on running VM’s from the local VMFS should you create multiple VMFS partitions and have one solely for the COS.  I almost think it would be beneficial just for the logical separation.  Well I will be digging a bit deeper into this but would love to hear others views on the COS and how they plan to deploy and why.  So please comment and let me know what you think.