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

Remove sleep calls in Start and Launch processes #93

Merged
merged 2 commits into from
Mar 8, 2023
Merged

Remove sleep calls in Start and Launch processes #93

merged 2 commits into from
Mar 8, 2023

Conversation

maxzinkus
Copy link
Collaborator

A number of internals cleanups and changes to remove the need for Retry in Start and Launch. Calls which were previously handled in Retry loops now either block until success, or exit with an error. Therefore, either the function succeeds, or does not need to retry as an error must first be resolved. Closes #79.

Overall summary of edits in qemu/ops.go:

  • in Stop(): simplify and add output
  • in getHostArchitecture(): fix logging format bug
  • changes in Start() and Launch() (below)

in Start():

  • use -daemonize and cmd.Run(..)
  • cmd.Run(...) blocks until qemu-system succeeds and forks to background
  • clarify output (awaiting ssh, etc)
  • Add PID file cleanup on errors
  • Remove unneeded Retry calls (calls now block or error rather than
    failing silently)
  • Mount mount directories in /mnt per standard Linux practices

in Launch():

  • Remove unneeded Retry (calls now block or error)
  • Document sfdisk calls

* `Stop()`: simplify and add output
* `getHostArchitecture()`: fix logging format bug
* changes in `Start()` and `Launch()` (below)

`Start()`:
* use `-daemonize` and `cmd.Run(..)`
* `Run()` blocks until `qemu-system` succeeds and backgrounds
* clarify output
* Add PID file cleanup on errors
* Remove unneeded `Retry` calls (calls now block or error rather than
  failing silently)
* Mount `mount` directories in `/mnt` per standard Linux practices

`Launch()`:
* Remove unneeded `Retry` (calls now block or error)
* Document `sfdisk` calls
@maxzinkus maxzinkus mentioned this pull request Mar 7, 2023
@idroz
Copy link
Collaborator

idroz commented Mar 8, 2023

On my 2020 M1 this is about 14% faster.

Before PR: start time 23.6s
This PR: start time 20s

@maxzinkus
Copy link
Collaborator Author

Yeah, just about same. However, I still like this PR as it ensures start only ever blocks while QEMU is working, rather than sleeping.

@idroz idroz merged commit 43e9004 into beringresearch:main Mar 8, 2023
@maxzinkus maxzinkus deleted the faster-start branch March 8, 2023 07:01
@idroz
Copy link
Collaborator

idroz commented Mar 8, 2023

One possibility for faster startups could be launching a vm from a snapshot (https://wiki.qemu.org/Documentation/CreateSnapshot).

On stop -> create snapshot
On start -> if snapshot exists, launch from it, otherwise use default launch mechanism.

I'll explore this a bit more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Start is very slow
2 participants