Add Qemu support for instances #487
Closed
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
This command is necessary to spawn up instance
This use qmp protocol to connect to the running qemu to send a shutdown signal. Add a new dependency 'qmp'
this remove a root requirement
since the autodected is disabled in newer qemu version
This include what would be printed to the main console. IE the bootsequence A lot useful for debugging
and tested it manually
|
Failed to retrieve llama text: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')) |
olethanh
added a commit
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
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.
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
You will need the corresponding branch in AlephMessage which allow to choose if an instance is run via firecracker or qemu aleph-im/aleph-message#78
Modification to the code
I had to make a few change outside the Qemu controller itself to provide compatibility between all controller:
support_snapshoton controller so the controler can declare support to the SnapShotManager without the different guessing from the method we had till now.get_log_queueandunregister_queueso the operator can register to the Log queues without knowing the internal logic of the VM (which is different since Qemu don't use MicroVMRefer to QEMU.md for a list of supported feature at the moment.
IMHO the main thing missing is automated testing.