Support for QEMU supervisor in Aleph-vm #78
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hoh
approved these changes
Nov 24, 2023
|
Looks good to me. |
|
@olethanh Would be ready to merge, you ok with that? It's still in draft. |
olethanh
added a commit
to aleph-im/aleph-vm
that referenced
this pull request
Dec 5, 2023
continuation of #487 Allow launching VM Instance via QEMU instead of firecracker. This works by adding a new Controller for Qemu alongside AlephFirecrackerProgram and AlephFirecrackerInstance and launch it if the message == Instance + hypervisor == qemu. I'm opening this so we can get the review and discussion started but from discussion I understand it won't be for the next release since we are focusing on bugfixes for now. I can clean it up the git history afterward if needed. Please play with it plenty to find any problem I might have missed. There is a corresponding PR in aleph-message: aleph-im/aleph-message#78 ## how to test See this pretty complete readme on how to test it https://github.com/aleph-im/aleph-vm/blob/qemu_support/src/aleph/vm/controllers/qemu/QEMU.md Necessary change in aleph-message were released in 0.4.1 ## Modification to the code I had to make a few change outside the Qemu controller itself to provide compatibility between all controller: - New abstract class: AlephControllerInterface which define the shared interface between Firecracker and Qemu controllers for sharing and typing. - Add field `support_snapshot` on controller so the controler can declare support to the SnapShotManager without the different guessing from the method we had till now. - a Mixin to manage the cloud init config, I intended to have it used between all the controllers that need it but at the moment I had to tweak the cloud init configuration so it's not done yet - `get_log_queue` and `unregister_queue` so the operator can register to the Log queues without knowing the internal logic of the VM (which is different since Qemu don't use MicroVM Refer to QEMU.md for a list of supported feature at the moment. IMHO the main thing missing is automated testing. moment I had to tweak the cloud init configuration so it's not done yet get_log_queue and unregister_queue so the operator can register to the Log queues without knowing the internal logic of the VM (which is different since Qemu don't use MicroVM Refer to QEMU.md for a list of supported feature at the moment. IMHO the main thing missing is automated testing.
hoh
pushed a commit
to aleph-im/aleph-vm
that referenced
this pull request
Mar 12, 2024
continuation of #487 Allow launching VM Instance via QEMU instead of firecracker. This works by adding a new Controller for Qemu alongside AlephFirecrackerProgram and AlephFirecrackerInstance and launch it if the message == Instance + hypervisor == qemu. I'm opening this so we can get the review and discussion started but from discussion I understand it won't be for the next release since we are focusing on bugfixes for now. I can clean it up the git history afterward if needed. Please play with it plenty to find any problem I might have missed. There is a corresponding PR in aleph-message: aleph-im/aleph-message#78 ## how to test See this pretty complete readme on how to test it https://github.com/aleph-im/aleph-vm/blob/qemu_support/src/aleph/vm/controllers/qemu/QEMU.md Necessary change in aleph-message were released in 0.4.1 ## Modification to the code I had to make a few change outside the Qemu controller itself to provide compatibility between all controller: - New abstract class: AlephControllerInterface which define the shared interface between Firecracker and Qemu controllers for sharing and typing. - Add field `support_snapshot` on controller so the controler can declare support to the SnapShotManager without the different guessing from the method we had till now. - a Mixin to manage the cloud init config, I intended to have it used between all the controllers that need it but at the moment I had to tweak the cloud init configuration so it's not done yet - `get_log_queue` and `unregister_queue` so the operator can register to the Log queues without knowing the internal logic of the VM (which is different since Qemu don't use MicroVM Refer to QEMU.md for a list of supported feature at the moment. IMHO the main thing missing is automated testing. moment I had to tweak the cloud init configuration so it's not done yet get_log_queue and unregister_queue so the operator can register to the Log queues without knowing the internal logic of the VM (which is different since Qemu don't use MicroVM Refer to QEMU.md for a list of supported feature at the moment. IMHO the main thing missing is automated testing.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.