Running Junos Olive from Virtual Box SNAPSHOTS in Ubuntu

[edubbya]

Its a complicated title, I know...

The purpose of doing this is to circumvent the time it takes to load the Junos OS from boot to CLI. I am able to create a snapshot in Virtual Box of the Junos Olive image once the CLI is present (I am then able to shut down the image in virtual box, turn it back on, and load into the CLI instantly). In any case, I am attempting to run imported Junos Olive snapshots from Virtual Box within GNS3. While I can get the Junos Image to load within Virtual Box from the saved snapshots, I get an error stating the VBOX is "not mutable (state is Saved)" when attempting to run the image from a snapshot in GNS3.

I believe this has something to do with the "state" of the VM within Virtual Box. When I close a Junos Olive image and indicate I want to load from a snapshot, the "state" is listed as "Saved" under the name of the VM, not "Powered Off". I believe it is a requirement of GNS3 to load Virtual Box images that are in a "Powered Off" state.


Has anyone had experience with this before?

AS a quick recap, as this is a copied thread from a GNS3 post, I am able to run the snapshot fine in VirtualBox, but when attempting to start a machine from GNS3, that is currently in a "saved" state in VirtualBox, it fails to load. The machines linked from VirtualBox to GNS3 only load when the state is "Powered Off" within Virtual Box. I guess what would be most ideal would be to change the state manually, so that a snapshot would still be loaded, but it says "Powered off" instead of "Saved". Or another option would be to create a clone that had the snapshot of the original machine as the base image.

[noteirak]

To give a more definitive answer: If you want your VM to start from a saved state so the CLI is present, then there is no choice: the state will always be saved.
It doesn't matter if you do a clone or what not, it will always reflect as "Saved State".
If GNS3 is expecting the state to be Powered Off, then it's up to them to fix that bit and allow saved state to be used.

[edubbya]

Thank you for your response. I understand telling GNS3 to accept machines in a Saved State to be a solution to this issue. As telling a open source company this bug, and the time it will take to fix (if they even decide it is worthy enough to change), is unrealistic, I wanted to try something else.

For this example, ignore the fact I mentioned Junos Olive. Assume it is any guest operating system you like...

One other thing I was going to try is "merge" a snapshot of the posted guest operating system and recreate/clone this merged snapshot into a new VM that would have no need to ever post for itself. The particular guest OS I am using takes almost 10 minutes to post given my current hardware, and I'd really like to speed that up. Is it possible to do this? In other words, is it possible to create a VM (that is not part of any series of snapshots) that will circumvent the time it takes to post (turn on)?

Thank you for your responses

[noteirak]

Let's simplify things here. There is only three possible states: off, saved or running. You can't have the VM state that it's off but still resume the VM after POST, since the only way to make the software resume the VM state is by knowing it's saved in the first place
You can of course run a modified version of VirtualBox and achieve this, but with the official version of VirtualBox, no it's not possible.
You would be better off changing the GNS3 code yourself and make it accept "Saved" state.