I have been working with Lab manager for quite a few years now and I have to admit that I found the documentation a little light in some places. Over the years I have been making notes on some of the tasks that I have seen other get wrong or keep asking me how to do. So I thought why not compile all of these thoughts into one giant LM post.
Working with configurations and Libray’s
To create a new configuration you are required to do the following (these are high level steps)
- Create a new template or use an existing one
- Create a new configuration in your workspace
- Add machines to your configuration and select the template that the machine should be built from. This stage is also where you select the network and name the system
- Once you have your configuration you have two choices, if it will only be temporary then you can just deploy it. If you plan to re-use it then go to step 5
- At this stage to we need to re-use the template so we should capture it to a library
- Once captured you should go and delete the configuration that you created. This saves on disk space and ensures that our linked clone chain remains low and manageable for a given template.
At this point it’s worth discussing how Lab Manager uses Linked Clones. A linked clone is a rather neat way of saving disk space. However major draw back is that they can also become very complex and converse to saving disk space they can also eat it up silently in the background.
Let’s try and expand on this. Let’s say that you have a template and that template spawns a configuration made up of three machines. You would have something that looks like this;
Each new VM would be a linked clone, as you can see this is a 10th of the disk space that the template was. In this example each linked clone is currently 1GB. Disk space is used by the clones Copy On Write disk (COW) The COW captures the writes that are specific to that instance it also reads from the parent disk as well. So at the moment we have saved a lot of disk space, instead of having 40GB of disk space used we have only used 13GB. Seems pretty simple.
BUT… This is where it gets interesting as our configuration can be cloned, lets just say because someone else wants and exact copy of what we have in their work space or someone wants to create a clone to backup a current state of a configuration. This is where our chain becomes slightly more interesting.
We have now ended up with a new configuration which in Lab manger looks to be standalone but the underlying effect is that we now have another level in our chain. So VM 6 now has a COW of 1GB (it could be more of less depending on its use. I am just using simple numbers for illustration) this COW relies on the COW of VM3 and the Template. This also means that even if the configuration that contains VM3 and co is deleted it will still remain as it’s required as part of the chain. It won’t be until the configuration that VM6 is deleted that the chain would go.
Lab manager leases and clean up
So it’s at this point where another twist should be introduced, lease maximums. A lease protects the storage from situations that arise where an expired VM is deleted if it has not been used with in the period defined for a lease. We currently have a lease set globally to 30 days for workspace configurations only. A template or a library should be a confirmed point in the chain that is not removed.
In our case an expired VM is one that has not been used in 30 days. If on day 28 it gets deployed the timer is restarted. Expired VMs are managed by the resource clean up in Lab Manager, also known as “Garbage Removal”.
24 hours before garbage collection occurs a notification is sent out to the owner to warn of the deletion. Our settings are pictured below. Flagged removes the configuration but leaves it on the data store. This is not what we wanted. So we delete automatically.
Let’s just look at one more example of how the chain can become even more complex.
As you can see this time not only have configurations been cloned but templates have been cloned as well. Without expired VMs being deleted we have ended up with a long chain taking up a lot of space. Ideally in this situation you would only want to be one or two levels in the chain to achieve the same result.
Each group of VMs is a configuration that is either running or just there to provide a link in the chain. To undo all of these chains you have to consolidate the templates and remove inactive configurations. The quickest method of doing that is this
- Clone the VM template (must be full clone) to a new data store. This will consolidate all of the chain back to one file. This may increase the size of the template.
- Un-deploy all machines
- Turn off host spanning in LM to remove the service VM from the data store.
- Delete the data store from VC. This will delete all files and folders
- Delete the data store from LM
- Add the data store back into the VC
- Add the data store back into LM
- Turn host spanning back on
So how can we manage this situation? The first step is to ensure that workspace leases are enforced globally. The next piece of the puzzle is to utilise libraries.
A library can contain a large number of different configurations. These can be selected by individuals and cloned to their work space. Each clone is then subject to the lease set.
Some good guidelines to get you started
To fill a library with configurations you first have to create your configuration. To ensure that disk space used is minimal don’t deploy your configuration. Instead you should capture it to a library. Below are some screen shots of the context view
This is our lone template. As you can see it has no clones.
Now you can see that we have created a configuration for training that contains 30 virtual machines.
Let’s see what happens when we capture that configuration to a library. You will also note that this configuration has not been deployed at this stage.
The context view above is actually of a VM that is now in the library. What has happened is that the capture has made the library copy the first link in the chain and not the last. This is the key reason why a library is important as now any clones from library will expire and can be deleted. The library will never expire and will always be the safe point that can be deleted back to in the chain.
When the configuration is deleted we will just end up with the guys on the furthest right disappearing. After the library capture has occurred the first configuration should be deleted just to keep things nice and tidy.
So now we have a library how should we now create configurations and manage them.
The first step is to go to the library and clone it to a work space.
The on going management at this point should be pretty straight forward, as if the configuration is idle for 30 days the garbage clean up will remove it from the data store and the owner can just deploy a new one from the library.
Adding and deleting machines when using a library.
When you just work with configurations this is actually quite straight forward. A library changes this.
Deleting a machine from a configuration
Let’s assume that one VM has an issue and the owner decides its quicker to just delete it and re-deploy a new one. Here is how we do it.
- Power off the VM
- Select to un-deploy
- Delete the machine
- Go to the Library and select to clone to work space
- Select and existing work space
- Select the individual machine
- That’s it!
Below is a screen shot of the options to select. Also shown are how the contexts of the chain change.
As you can see when the machine is deleted is becomes a different icon and will be deleted automatically after 30 days or it can be manually deleted. For the sake of this document the machine was manually deleted using “Delete Expired VMs” option. The context view would just show no icon after the top VM in the library.
Once its added it just shows as another link from that top VM again.
Adding a new VM to a library
Lets assume that you now need 35 machines in your configuration and you only have 30. There is no way of doing this without deleting the library and making a new configuration with the correct number.
Although it would not be the best way going forward you can go and add a machine to the configuration that has been cloned to the work space. This has been done and as you would expect the newly added VM appears at the same level as the library but is now separate to the library. Its our standard procedure to delete these after use and then create a new configuration and capture that to the library.
Lab manager can very quickly run away with out its administrators if it’s not managed. Linked clones provide substantial disk space savings and should be used wisely with library configurations. Training will be shown how to work with a library moving forward, as well as how configurations can expire.
MIS will remain the gate keepers managing the templates and libraries. This will ensure a stable point in the chain that can be safely reached in the future without fear of deleting a part of the chain that is critical.