Start States
- 05 Sep 2024
- 7 Minutes to read
- Print
Start States
- Updated on 05 Sep 2024
- 7 Minutes to read
- Print
Article summary
Did you find this summary helpful?
Thank you for your feedback
Start States allow you to create a point-in-time capture of Virtual Machine Profiles (VMs) within a Lab Profile, that will be leveraged in subsequent launches of the Lab Profile. In many cases, Start States can significantly reduce lab startup duration, especially for large and complex labs.
Start States are limited to Hyper-V virtualization labs. Start States are not supported on ESX.
Overview of Start States
Hyper-V Start states allow a lab to be resumed from a point-in-time, instead of booting from the Virtual Machine's (VM) disk. When deciding to use a Start State vs a naturally booting VM in a lab, there are a few things to consider.
Launch time
Boot sequence dependencies
Software configuration
Minimizing Waste
Start States may not be an optimal solution for some lab scenarios. Start States come with some drawbacks, including restrictions on the ability to update the lab without additional steps. Some software does not work well being restored from a Start State. In addition, where systems replicate data between nodes (Active Directory being an example), a Start State can cause data consistency issues if a Start State is not captured on all VMs within the Lab Profile.
Best Practices
Lab Component Sequencing
For complex labs, the boot sequence must account for dependencies between lab components. This is important so that components that depend on other components are put into place at the proper time in the boot sequence.
In Skillable Studio, there are options to control how VMs start. These options can be found on the Virtual Machines tab of a lab profile.
Field | Description |
|---|---|
Start Automatically | This options controls if the VM starts when the lab launches. |
Startup Delay | This option adds a delay to the VM startup when a VM is set to start automatically. |
Resume Order | This option controls the resume order of VMs. Enter a numerical value to specify the order the VMs will resume. Each VM should have a value entered. If a value is not entered on a VM, the VM will resume when the lab is launched, unless there is a startup delay. |
VM RAM Consideration
When using Start States, sequencing can be important. VMs with a high amount of RAM will take longer to restore than VMs with a low amount of RAM, as Start States capture the data in the VM's RAM as well as the changes made to the VM's disk(s).
If your lab does not require a high amount of RAM, use only the amount needed.
Software Configuration
If your lab uses specific software as part of the curriculum, Start States allow you to configure the software in the lab so that the lab user starts the lab with the software configured.
Preconfiguring software is beneficial because the lab user can focus on the techniques used within the software, rather than configuring the software.
Some software does not work well when it is restored. Fully test that all software in the lab functions as expected after being restored.
Validate and Test
Do not implement Start States until you have fully validated your lab is working and you anticipate no changes.
After a Start State is captured, you should fully test the lab to confirm all software restores as expected and lab component sequencing works as expected.
Launch Times
Depending on the complexity of the lab and the lab components used, the launch times for your lab may vary. Creating a Start State at a point in the lab after lab components and services are started and running in the desired state will allow future lab launches to resume at that point-in-time, resulting in a quicker lab launch.
Boot Sequence Dependencies
If you have a complex lab, your boot sequence must account for dependencies between lab components. For example, if your lab has a server VM and a client VM, the server VM may need to boot first so that the client VM can properly connect and interact with the server VM.
Software Configuration
If the lab uses any software that requires any configuration after booting a VM, it is helpful to configure the software and then capture a Start State. This allows the lab user to launch the lab and start using the software as it is intended to be used, instead of readying the software first.
Minimize Start State Scope
It is highly recommended that Start States be leveraged as an 'end-cap' solutions to a Lab, doing little Lab Development work beyond what would be otherwise necessary for the students to complete, or wait for, after lab launch. Capturing extensive Lab Development work in a Start State may be counter-productive, as removing the Start State may become necessary to complete additional Lab Development work.
Creating a Start State
Start States can only be created on Hyper-V VMs. Start States are not supported on ESX VMs.
Validate your lab
Do not implement Start States until you have fully validated your lab is working and you anticipate no changes.
To create a Start State:
Navigate to the Hyper-V lab profile you wish to configure a Start State on.
Launch the lab.
Configure the VMs and any software in the VMs.
Click the menu in the upper right corner of the lab.
Click Save.
Select Commit my changes and update the lab profile, then click Next.
On the next screen, select Capture start state.
If your lab contains a NAT Web access network that uses DHCP, it is not a recommended configuration for a lab starting from a saved state. Because the DHCP leases will likely have expired when the lab starts, it could take several minutes for the virtual machines to regain network access. You should consider editing the lab profile and disabling DHCP in all NAT Web access networks, as well as assigning static IP addresses within your virtual machines.
Enter a note describing the changes that will be captured in the Start State.
Select the VM(s) that will be captured.
If any of the VMs used in the lab have time-limited software, check the box to Disable Host Time Synchronization.
If you have internet access enabled on the Lab Profile, depending on the configuration of your VMs, they can automatically update to the actual date/time.
Click OK.
The changes will now be committed to the lab profile. This process may take a few minutes to complete, depending on the amount of changes and number of VMs.
After the changes are committed, a screen will be shown to indicate success.
If additional changes need to be made that should be captured in the Start State, repeat the previous steps. If no additional changes need to be made, click the menu in the upper right corner of the lab and choose End to close the lab.
Due to the nature of the data being captured, Start States are more volatile than differencing disks, so additional updates to a Start State can introduce data corruption. If that occurs, removing and re-capturing the Start State will be necessary.
Subsequent lab launches will launch in the state the lab was in when the Start State was captured.
Updating VMs in a Lab That has a Start State Configured
To update VM in a lab that has a Start State configured, you must remove the Start State.
When you remove the Start State, all configuration will be removed and the lab will start as it did before a Start State was configured. This includes removing any software configuration made in the lab.
To Remove a Start State:
Navigate to the lab profile.
Click Clear Start State at the top of the screen.
Click OK on the confirmation dialog.
The Start State will be removed and the lab will return to the state it was in before the Start State was captured.
Was this article helpful?