For VMs deployed with Orka 1.5.0 or later, you can save their state - disk and memory. Once you save a VM state, it is used when you deploy new VMs from the same VM configuration. All new VMs use the state to boot up.
Quick command/API summary
orka vm create
orka vm save-state -v <VM_ID> -y
orka vm deploy
orka vm delete-state -v <NAME> -y
VM state is the VM's disk and memory at a certain moment. After saving the VM state, the VM will boot using the newly created saved state instead of the base image.
When a VM boots up from a saved state the time in the VM is relevant to the time when the state is saved.
When your VM boots up from a VM saved state, the SSH, VNC, and Screenshare connectivity are already established as part of the saved state. Тhus making it immediately available after deploying. When compared to booting from the base image, boot time is substantially decreased.
VM deployment with and without a saved state
According to our tests, when a VM is deployed from a VM configuration with a saved state for the first time on a node, it can be accessed via SSH, VNC, or Screen sharing in 30% less time than if it were deployed from a configuration without a saved state.
In case of a consecutive deployment from a VM configuration with a saved state, accessing the VM via SSH, VNC, or Screen sharing is more than two times faster compared to deployment from a VM configuration without a saved state.
Once you save the VM state, it is associated with the relevant VM configuration. All the further VMs deployed from this VM configuration will use the saved state to boot up. To deploy a VM using the VM configuration base image, you need to delete the VM saved state first.
When you save a VM state, you won't be allowed to commit changes to the VM configuration base image. To commit to the base image, you need to ensure no other VMs or VM saved states are using it.
You can save VM state only for VMs which have GPU passthrough disabled.
You may observe delays in the deployment times the first time you deploy a VM configuration with a saved state on a node. Nevertheless, deploying with a saved state gives you access to the VM via SSH, VNC, or Screen sharing faster than when you deploy without a saved state.
To save a VM state you need at least one deployed VM.
Updated 9 months ago