Skip to content

Cannot reuse a Firecracker VM from multiple containers without specifying Container Count #230

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

Closed
kzys opened this issue Jul 23, 2019 · 3 comments · Fixed by #240
Closed

Comments

@kzys
Copy link
Contributor

kzys commented Jul 23, 2019

(From #225)

Probably due to the way we handle stub drives, re-using a Firecracker VM from multiple containers doesn't work due to a mysterious

Drive "root_drive" could not be found

error.

@sipsma
Copy link
Contributor

sipsma commented Jul 24, 2019

This specifically happens in situations like the following:

  1. Call CreateVM with ContainerCount set to 1
  2. Start a container, let it exit and then Delete it.
  3. Try to start another container

Besides the extremely unclear error message @kzys mentioned, we should in theory be able to run the second container as the stub drive is no longer being used after the first container is deleted. We could add a feature to support "freeing" stub drives when containers are deleted.

kzys added a commit to kzys/firecracker-containerd that referenced this issue Aug 6, 2019
Before this change, a stub drive handler knew non-stub drives, including
the root drive. However patching non-stub drives is not supported and
must be prevented.

Related: firecracker-microvm#230

Signed-off-by: Kazuyoshi Kato <[email protected]>
@kzys kzys closed this as completed in #240 Aug 6, 2019
@kzys
Copy link
Contributor Author

kzys commented Aug 7, 2019

Oh, but may need more changes to actually fix #230 closes the issue since it has "fix #230"...

But, well, I think #243 is actually better than this one. So I'm not going to reopen this issue.

@sipsma
Copy link
Contributor

sipsma commented Aug 7, 2019

Oh, but may need more changes to actually fix #230 closes the issue since it has "fix #230"...

But, well, I think #243 is actually better than this one. So I'm not going to reopen this issue.

Ah okay, I had thought that closing it was intentional :-) I think it's better to handle that as a separate issue anyways as it's more of a feature enhancement whereas what you did here was a bug fix.

fangn2 pushed a commit to fangn2/firecracker-containerd that referenced this issue Mar 23, 2023
machine config is not available at this time
fangn2 pushed a commit to fangn2/firecracker-containerd that referenced this issue Mar 23, 2023
* Since firecracker-microvm/firecracker#2125, `cargo build` doesn't build jailer by default. (firecracker-microvm#263)
* Fix Benchmark Goroutine (firecracker-microvm#259)
* Jailer configuration API cleanup and improved logging with Debug log level (firecracker-microvm#255)
* Firecracker is internally has an instance ID, but the SDK didn't have the way to configure the ID. This change connects Config.VMID to the instance ID. (firecracker-microvm#253)
* Fixed error that was not being test against in `TestWait` (firecracker-microvm#251)
* Fixes issue where socket path may not be defined since the config file has yet to be loaded (firecracker-microvm#230)
* Fixed error that was not being test against in `TestNewPlugin` (firecracker-microvm#225)
* Download Firecracker 0.21.1 and its jailer from Makefile (firecracker-microvm#218)

Signed-off-by: xibz <[email protected]>
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 a pull request may close this issue.

2 participants