Showing posts with label Lab Manager. Show all posts
Showing posts with label Lab Manager. Show all posts

Thursday, March 4, 2010

VMware Lab Manager Install Notes and LDAP Import

Setting up Lab Manager can be a little complex.  It isn't as straight forward as some of the other VMware products so I wanted to provide some tips and tricks to get it all up and running.

Things you will need prior to Lab Manager Installation
  • In vCenter, create the datastores, virtual switches, and Resource Pools that you will need.  The Lab Manager (LM) install will detect them at install and this will make configuration MUCH easier
  • Create all groups and users that you will need in either Active Directory or LDAP
  • If you will be using ip pools, define a block of static ip's ahead of time!
  • The Lab Manager server is currently a Windows 2003 based server. It can be virtual and on the same ESX hosts that it will be controlling.  If you do this, DON'T name it lab-manager.  If you do, you will get an error during installation because the install tries to create a folder in vCenter called lab-manger.  You will have to rename your virtual machine to proceed.  Also, you will need to change the speed of the vmxnet3 NIC per Jason's article here.
  • Make sure both forward and reverse DNS lookup work between the vCenter server, LM server, and all vSphere servers
  • The LM Server requires IIS 6.0 and .NET 2.0 to be installed.  IIS MUST be installed before .NET 2.0
  • DON'T put the LM Server into the AD Domain.  VMware recommends against this even if you are importing users and groups from AD into the LM Server.  I asked why at Partner Exchange and I was told because it isn't needed and changes to AD could mess up the LM server.
LDAP/AD Integration

Integration with Active Directory or LDAP is the key to Lab Manager.  Lab Manager allows you to create single users on the box but NOT groups.  This makes security and configuration VERY difficult.  At the same time, the LDAP integration leaves a little to be desired in the implementation.  Here's how to do it:

  • From the Lab Manager Interface, On the left hand side choose Settings and click the LDAP tab:
 
  •  Once that is complete, you are ready to import groups.  Click the Import Groups Button.
 
  •  Here's the magic.  Because the group and users have already been created in Active Directory, you can choose the group and assign it to the users role (the default role is read only so be sure to change it).  All users in this group are now Lab Manager Users

A few interesting notes about this import process.  If you look at the group once it is imported and no one in the group has logged in yet, the group appears blank!  This threw me for a little bit.  I expected it to populate with the users at creation time.  Instead the list populates at each USER's FIRST LOGIN!  My group has three users in it total.  As users log in, they will populate the group and also appear on the Lab Manager's Users list.  Here are a few screenshots as I logged in my test users.

Lab Manager Group with only first test user logged in:


Lab Manager Users Pane with two users created from login:


 Look for more articles as I get everything set up!

Thursday, February 11, 2010

VMware PEX: Lab Manager Design and Implementation

VMware PEX: Lab Manager Design and Implementation (TECHMGT0922).  This is written as I sit in the session so it could be messy.

Architecture
  • Lab Manager Server (Windows based)
  • vCenter Server
  • One or more ESX 3.5 or 4.0 servers, ESXi 4 servers
  • TCP port 902/903 for virtual machine console access
  • Brower client to Lab Manager (LM) server is tcp443 
  • TCP 5212 from LM Server to ESX servers and TCP 443 from lm to vCetner
  • Read the manual for all the requirments (installer checks for them and spits out errors)
  • Install a service account on lm server - page 14-15 of user guide as details on permissions needed
  • Pre-crreate resource pools if you want to use them so that it will pick them up at install time
  • Pre-create all virtual switches, distributed switches, etc.
  • Don't join it to the domain so nothing from AD would get pushed to it as a member server
Storage Design
  • LM uses Linked Clones to save disk space
  • Make sure the I/O can support your environment (just because you have the space doesn't mean you have enough I/O!)
  • LUN locking and limit of 8 nodes if using vmfs (NFS doesn't have this limit)
  • Understand the concept of disk chains and how they work (this isn't well documented)
Network Design
  • When Setting up LM server, create the default Physical network  
  • Design Considerations for Networking: Physical Network vs. Virtual, Fenced vs. Non-Fenced - Will IP's be from an IP Pool, DHCP, or Static?
  • Physical network is nothing more than a connection out to a physical network
  • Virtual network - a network that is may or may not be connected to a physical network (could be on a different ip, vlan, etc) - A virtual network can be connected to a physical network if needed upon deployment
  • Fencing - The ability to create a fence around a configuration (group of vm's) so they are isolated from the rest of the network.  If the fenced configuration needs to get out, it will do so through a NAT router (small Linux vm).  In this case it would have an internal ip inside the fence and an external ip address outside the fence using the NAT router.  This is great for machines and applications that all have the same ip.  This way there will not be ip conflicts on the network.
  • Host spanning - fencing isolation was limited to one host in version 3, the ability to cross servers with vMotion is called host spanning.  Host Spanning needs the Distributed Switch (and Enterprise Plus license to get Distributed Switch)
  • IP Pools - Takes a lot of ip addresses - if using fencing remember the the NAT router needs ip's as well
Fencing Considerations
  • Fancing can't use DHCP (DHCP can't cross the fencing to provide the address)
  • IP Static Pool must be used
  • At least one virtual machine needs to conntect to physical network (otherwise virtual network with no outside connection)
  • Fence policy is traffic In and Out, All Blocked, or Out Only.  There is no In Only policy. 
  • Be careful with outside communications if using fencing (many machines with same name but different ip's all hitting an outside source!)
    •  Domain COntroller - member servers can be in a configuration with the same name as others as long as the machine pasword with AD doesn't expire (30 days by default).  Otherwise, put a clone of the DC in the configuration and run it private to the configuration group
    • Domain Controller Clone - be careful - a cloned dc will come up with a .169 address because it detects one with the same ip address already out there.  Best way to do this is clone the DC and completely isolate it from the production network.
    • SQL server - if outside the fence, what happens when multiple configurations hit it??  Maybe different instances of the same database on the same server - adds a little bit of a manual intervention to the process
    • Can create a workstation that is inlcuded in the configuration for the user to use as a workstation "in the fence"

Good Article: VMware KB1000023 - How to Backup the VLM Database

Monday, October 5, 2009