Difference between revisions of "Lab Manager"

Jump to navigation Jump to search

Lab Manager (view source)

Revision as of 09:30, 19 July 2012

12,033 bytes added ,  09:30, 19 July 2012
→‎Troubleshooting: Added "Unable to Export Configuration"
(→‎Troubleshooting: Added additional "Unable to Deploy Virtual Machine " causes)
(→‎Troubleshooting: Added "Unable to Export Configuration")
 
(22 intermediate revisions by the same user not shown)
Line 17: Line 17:
#* Owner
#* Owner
#* Published
#* Published
== Export a Machine from Lab Manager ==
Note that if you can't satisfy the [[Lab_Manager#Prerequisites|Prerequisites]] then you can always use [[VMware Converter]]...
# '''Unpublish''' the VM template
# '''Deploy''' a single VM from a template (powered off)
# Use Converter to create a clone in a new location
# '''Publish''' the VM tenplate
=== Prerequisites ===
* Your source ESX's need to have SMB access to the UNC path your going to copy to, from an ESX test the following...
*# SMB allowed through ESX firewall
*#* <code> esxcfg-firewall -q smbClient </code>
*# ESX can access server via SMB
*#* <code> smbmount <share> <mountpoint> -o username=<username> </code>
*#* EG <code> smbmount //Dest_Win_Server/D$ /tmp -o username=Administrator </code>
*# If successful, remove the mount
*#* <code> umount //Dest_Win_Server/D$ /tmp </code>
* Lab Manager server must not have [http://support.microsoft.com/kb/956572 MS KB 956572] installed
=== Procedure ===
# Locate the machine within the '''VM Template''' screen
# Right-click over the VM and select '''Export...'''
# Enter a UNC path
#* Must be accessible via SMB from the ESX's
#* Must be a sub-folder, not a root
# Enter user/pass with Write rights on UNC share
== Add ESX to Lab Manager ==
# Set up a new ESX as normal then within Lab Manager
# Go to '''Manage | Resources | Hosts''' and '''Prepare''' the hosts to install the Lab Manager agent on the ESX's
# Go to '''Manage | Resources | Physical Networks''' and add network bindings for each of the ESX's
# Go to '''Manage | Resources | Hosts''' and '''Enable''' the hosts
== Put Spanned ESX Host into Maintenance Mode ==
You can't put a Lab Manager enabled ESX directly into maintenance mode, if it's also enabled for host spanning.  The service VM (called something like <code>012345-VMwareLM-ServiceVM-I6-H78</code>) won't power-down or undeploy automatically (and it can't be migrated via vMotion as it needs to stay on its ESX to enable host-spanning).
# Deployed but powered off LM VM's can't be moved either, so any on the host have to be either powered on, or undeployed
# With DRS set to '''Fully Automated''', select '''Enter Maintenance Mode''' for your ESX host
# Once all deployed (non service) VM's have migrated off, put DRS to '''Partially Automated''' and '''''cancel'''''' the ''Enter Maintenance Mode'' task
# Then '''Disable''' the host in Lab Manager, and unselect the '''Enable host for Host Spanning''' to undeploy the service VM
#* In Lab Manager, go to Manage > Resources > Hosts tab to Disable, and go into the ESX's Properties to disable host spanning
# Finally, put the host in '''Maintenance Mode'''
Once your work is complete, take the host out of maintenance mode, enable for host spanning and as LM host, then put DRS back to Fully Automated.  Its worth manually vMotioning a Lab Manager deployed VM onto the host to double check everything is back in full working order.


== Change a Deployed VM's Resources ==
== Change a Deployed VM's Resources ==
In theory a deployed VM's config shouldn't be changed, in reality its bound to be required at some point as a one off, but its quite limited.  Obviously any changes will be lost when the template is redeployed, if this isn't wanted, or if its a regular occurrence the VM templates should probably be edited.
In theory a deployed VM's config shouldn't be changed, in reality its bound to be required at some point as a one off, but its quite limited on what can be achieved.   
 
Any changes will be lost when the template is undeployed and its state not saved.  If this isn't wanted, or if its a regular occurrence, the VM templates should be edited (CPU and memory can be edited with Lab Manager, the VM doesn't need to be re-imported).
* '''CPU''' - Update the deployed VM's config through vCentre
* '''CPU''' - Update the deployed VM's config through vCentre
* '''Memory''' - Update the deployed VM's config through vCentre
* '''Memory''' - Update the deployed VM's config through vCentre
* '''Network''' - Update the deployed VM's config through vCentre
* '''Network''' - Update the deployed VM's config through vCentre
* ''Disk - Can't be changed, a deployed template is a delta from the original template (think snapshotting), you must reconfigure the template''
* ''Disk - Can't be changed easily, a deployed template is a delta from the original template (think snapshotting), you must reconfigure the template.  Additional disks can be added to an undeployed machine''
 
=== Increasing Disk Size ===
# In the config, shutdown the VM
# Once shutdown, select '''Add to VM templates...'''
# Select '''Export...''' to copy the VM to a normal VM, then delete it
# Locate the VM in vCentre and modify as required
# Boot the VM up, extend the disk, and shutdown
# In Lab Manager, import the VM, and publish
# In the config, delete the VM, and then add the modified template in
 
== Move to a new Datastore ==
If you need to move off an old datastore, you need to get your templates (and so also the machines deployed from them) off it.  Therefore to do it in a nice, graceful (and gradual fashion).  Templates would need to be re-provisioned on new storage, and workspaces re-deployed using the new templates, which is likely to take time.  In order to get off old storage quickly (because its unstable maybe) you can...
* Migrate templates and their deployed child VM's using VMware SSMove tool - [http://kb.vmware.com/kb/1006694 VM KB 1006694] (not successfully tested)
* Clone deployed child VM's to new storage (you take a full fat copy, through the Lab Manager interface)
 
To clone child VM's to new storage
# Action '''Undeploy - Save State''' on the entire workspace
# Once completed, go to '''Clone...'''
#* In ''Clone to:'', select '''Existing Configuration''' and select the workspace you're currently in
#* In ''Create:'', select '''Full Clones...'''
#* In ''Clone:'', select '''Selected Virtual Machines:''', tick the VM's you want to clone and select the destination Datastore
#* Click '''OK'''
# Once completed, go into the workspace, and rename VM's so that...
#* Source VM's are given new names
#* Clone VM's are given names of the machines they were cloned from
# For the entire workspace, select '''Move...'''
# Move all the old source VM's into a new (temporary) workspace
# Redeploy the original workspace
# Assuming the original workspace spins up OK, the new temporary workspace can be deleted
 
 
== SOAP API ==
As of 2010, there is no [[:Category:PowerShell|PowerShell]] or [[:Category:PowerCLI|PowerCLI]] interface into Lab Manager, and there is unlikely to be one now that Lab Manager is going end of life.  There is an underlying SOAP interface (on which a PowerCLI interface would be built), which provides limited interaction.  This can be utilised via PowerShell scripts.
 
The functions below were taken from http://poshcode.org/753, note that whilst you can connect to the Lab manager web service without explicitly supplying a user/pass (assuming the logged in user has access), you do need credentials in order to be able to create the Authentication Header that's required for all API calls.  I tend to store a local copy of my user/pass (see [[Power_Shell#Store_Password_Securely|Store Password Securely]]) to make this less of a chore.
 
<source lang="powershell">
function Ignore-SslErrors {
# Create a compilation environment
$Provider=New-Object Microsoft.CSharp.CSharpCodeProvider
$Compiler=$Provider.CreateCompiler()
$Params=New-Object System.CodeDom.Compiler.CompilerParameters
$Params.GenerateExecutable=$False
$Params.GenerateInMemory=$True
$Params.IncludeDebugInformation=$False
$Params.ReferencedAssemblies.Add("System.DLL") > $null
$TASource=@'
  namespace Local.ToolkitExtensions.Net.CertificatePolicy {
    public class TrustAll : System.Net.ICertificatePolicy {
      public TrustAll() {
      }
      public bool CheckValidationResult(System.Net.ServicePoint sp,
        System.Security.Cryptography.X509Certificates.X509Certificate cert,
        System.Net.WebRequest req, int problem) {
        return true;
      }
    }
  }
'@
$TAResults=$Provider.CompileAssemblyFromSource($Params,$TASource)
$TAAssembly=$TAResults.CompiledAssembly
 
## We now create an instance of the TrustAll and attach it to the ServicePointManager
$TrustAll=$TAAssembly.CreateInstance("Local.ToolkitExtensions.Net.CertificatePolicy.TrustAll")
[System.Net.ServicePointManager]::CertificatePolicy=$TrustAll
}
 
function New-ObjectFromProxy {
param($proxy, $proxyAttributeName, $typeName)
 
# Locate the assembly for $proxy
$attribute = $proxy | gm | where { $_.Name -eq $proxyAttributeName }
$str = "`$assembly = [" + $attribute.TypeName + "].assembly"
invoke-expression $str
 
# Instantiate an AuthenticationHeaderValue object.
$type = $assembly.getTypes() | where { $_.Name -eq $typeName }
return $assembly.CreateInstance($type)
}
 
function Connect-LabManager {
param($server, $credential)
 
# Log in to Lab Manager's web service.
$server = "https://" + $server + "/"
$endpoint = $server + "LabManager/SOAP/LabManager.asmx"
$proxy = new-webserviceproxy -uri $endpoint -cred $credential
 
# Before continuing we need to add an Authentication Header to $proxy.
$authHeader = New-ObjectFromProxy -proxy $proxy -proxyAttributeName "AuthenticationHeaderValue" -typeName "AuthenticationHeader"
$authHeader.username = $credential.GetNetworkCredential().UserName
$authHeader.password = $credential.GetNetworkCredential().Password
$proxy.AuthenticationHeaderValue = $authHeader
return $proxy
}
</source>
 
=== Configuration IP's Lister ===
* '''[[Lab Manager Configuration IP List]]'''
The above script allows you to generate a email showing the external (NATed) addresses of a configuration.
 
=== Configuration IP's Lister and RDP Tester ===
* '''[[Lab Manager Config IP List and RDP Test]]'''
The above script is really a version 2 of [[#Configuration_IP.27s_Lister|Configuration IP's Lister]] which still allows you to generate a email showing the external (NATed) addresses of a configuration, but also allows you to test RDP access to all your VM's within the config.


== Troubleshooting ==
== Troubleshooting ==
Line 41: Line 191:
# Go to the VirtualCentre tab
# Go to the VirtualCentre tab
# Click on '''OK''' to re-apply the user/pass
# Click on '''OK''' to re-apply the user/pass
'''''ESX'' does not support virtual machine hardware version "0"'''<br>
Caused by config data corruption, potentially from the machine's VMX file
# Locate the VM's config and confirm the hardware version is set correctly (eg to v7 for ESX4)
#* <code> virtualHW.version = "7" </code>
# Go into the SQL database on the Lab Manager server, perform the following queries to confirm the VM's affected and correct
#* <code> SELECT dir_id, name, hw_version FROM VirtualServer WHERE hw_version=0 </code>
#* <code> UPDATE VirtualServer SET hw_version=7 WHERE hw_version=0 </code>
#* <code> UPDATE VirtualServer SET hw_version=<correctNumber> WHERE hw_version=0 AND name='VirtualMachineName' </code>
# The VM then needs to be cloned to template and then redeployed (clone required to prevent reoccurrance)
'''vCenter Lab Manager timed out trying to read the virtual machine's file on the remote host'''<br>
Caused by either of...
* The ESX experiencing problems reading the files of the VM (and its parents) on VMFS storage
*# Check out VMFS storage!
* The VM is still partially running on an ESX (so its files are locked)
*# Run the following command on the likely ESX(s) to running VM processes
*#* <code> ps auxwww | grep -i vmx </code>
*# Kill the relevant processes, eg
*#* <code> 7135117 7179577 mks:001876-VM-Server-A /bin/vmx </code>
*#* <code> 7180174 7179577 vcpu-0:001876-VM-Server-A /bin/vmx </code>
*#* <code> 7180175 7179577 vcpu-1:001876-VM-Server-A1 /bin/vmx </code>
*#* Run <code> kill 7179577 </code>


=== Lab Manager Disconnected from ESX ===
=== Lab Manager Disconnected from ESX ===
Check/restart the Lab Manager agent service that runs on the ESX...
Check/restart the Lab Manager agent service that runs on the ESX...
* <code> service vsla-agent status </code>
* '''ESX3'''
** <code> service vsla-agent status </code>
** <code> service vsla-agent restart </code>
* '''ESX4i'''
** <code> /etc/opt/init.d/vslad status </code>
** <code> /etc/opt/init.d/vslad restart </code>
 
If Lab Manager keeps dropping the connection to the ESX, check activity in the Virtual Centre.  If an ESX is continually being instructed to complete tasks that fail you need to consider restarting that ESX.
 
=== Unable to Export Configuration ===
Export of a configuration to full fat VM's fails...
* Lab Manager shows...
** '''VirtualMachine.clone task on CloneVM_Task failed'''...
* vCenter also shows...
** '''Incompatible device backing specified for device 'x'.''' for the affected VM's Clone virtual machine task
 
Suspect the problem is caused by a problem with the VM's config file (VMX) - to work around, create a clone of the configuration and then export from that clone.
 
=== Unable to Enable Datastore ===
'''This datastore has missing or invalid directories'''
 
The Lab Manager server knows which folders to expect under its own folder within a given datastore.  If what's recorded in its database doesn't match the file system, this error is thrown.
 
# Confirm which the (un)expected folders by looking at error message detail
# Create new (dummy/empty) folders for anything that's expected
# Delete/move folders that shouldn't be there, to confirm of they're safe to delete...
## Confirm the VM isn't visible via Virtual Centre
## Confirm the VM doesn't exist in the Lab Manager database
### From a command prompt open the SQL command line to get into the db
###* LM3: <code> osql -S localhost\vlm -E </code>
###* LM4: <code> osql -S localhost\labmanager -E </code>
#* To move a VM folder up a level use <code> mv 1234 ../ </code>


'''''INCOMPLETE !!'''''


[[Category:VMware]]
[[Category:VMware]]
[[Category:Lab Manager]]
Retrieved from ‘https://vwiki.co.uk/index.php?title=Special:MobileDiff/972...2068’

Navigation menu