Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restoring unikernels #36

Open
PizieDust opened this issue Sep 5, 2024 · 3 comments
Open

Restoring unikernels #36

PizieDust opened this issue Sep 5, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@PizieDust
Copy link
Collaborator

Currently a unikernel could either be running or destroyed.
We should have functionality that let's us save the state of a running unikernel, gracefully shut it down, and this state can be at some point restored in a new unikernel, presenting no noticeable differences between the new unikernel and the previous unikernel. It may be sufficient to understand what's most important to preserve about a unikernel before it is destroyed, persisting this information and later using it.

@hannesm hannesm added the enhancement New feature or request label Sep 23, 2024
@hannesm hannesm changed the title Restarting/restoring unikernels Restoring unikernels Sep 23, 2024
@hannesm
Copy link
Contributor

hannesm commented Sep 23, 2024

This requires to store unikernel information into the mollymawk database. This is for sure useful in the future.

@hannesm hannesm added this to the Next year milestone Sep 23, 2024
@hannesm hannesm removed this from the Next year milestone Sep 23, 2024
@PizieDust
Copy link
Collaborator Author

Yes, the idea I have in mind is when a user destroys, we should store arguments of the unikernel in a record under the users data. I assume the binary of the unikernel should still exist on the albatross server and perhaps the block file should also still exist somewhere on the albatross server machine.
When a user performs a restoration, we should just launch the previous binary and previous block data with the stored arguments.
Or, we can ask the user if they will like a new instance of the block device.

@hannesm
Copy link
Contributor

hannesm commented Sep 23, 2024

The unikernel binary does not exist anymore on the server when the unikernel is not running.

Block devices persist - I suspect #32 will solve what we want :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

2 participants