Move first boot to new service #215
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
Moving the snippet disabling the services to a function. Signed-off-by: Ram Lavi <[email protected]>
Moving the snippet setting hugepages to a function. Signed-off-by: Ram Lavi <[email protected]>
RamLavi
force-pushed
the
move_first_boot_to_new_service
branch
2 times, most recently
from
d274be6
to
3357895
Compare
|
passes e2e on CNV 4.15 cluster: logs show the correct linux cmdline for both VMs: |
orelmisan
approved these changes
Jan 10, 2024
vms/traffic-gen/scripts/customize-vm
Outdated
Comment on lines
32
to
35
| TREX_URL=https://trex-tgn.cisco.com/trex/release | ||
| TREX_VERSION=v3.03 | ||
| TREX_ARCHIVE_NAME=${TREX_VERSION}.tar.gz | ||
| TREX_DIR=/opt/trex |
There was a problem hiding this comment.
These variables are considered global, since they are not prefixed with local.
Moving trex setup to a function Signed-off-by: Ram Lavi <[email protected]>
Moving setting nsafe_no_io_mmu_mode to a function. Signed-off-by: Ram Lavi <[email protected]>
The first-boot script running by the virt-builder command is run on a service created by virt-builder. This service is guaranteed to run in the final stages of the boot process [0]. This may create a race with the checkup, that is waiting on the agentConnected condition [1] being added in order to run the checkup's executor package. The race is happening since the guest-agent service also runs during the final stages of the boot process. In order to eliminate this race, removing the first-boot script in favor of the new service, and moving the first boot script content into a new service. This service is - manually created on the customize-vm script. - explicitly scheduled to run before the guest-agent service runs. - running the content of the former first-boot script. - running the tuned-adm command formerly set on the customize-vm script. The reason is that this command needs to run on a running guest. Moreover, since this command needs to only run on the first boot of the image, the script is checking the existence of a marker file, then only creating the file after the first run of the snippet. [0] https://www.libguestfs.org/virt-builder.1.html [1] https://github.com/kiagnose/kubevirt-dpdk-checkup/blob/b9b6a472fe92583a0db46361289239e0e8d06284/pkg/internal/checkup/checkup.go#L237 [2] https://www.freedesktop.org/software/systemd/man/latest systemd.unit.html#ConditionPathExists= Signed-off-by: Ram Lavi <[email protected]>
Signed-off-by: Ram Lavi <[email protected]>
Moving the snippet disabling the services to a function. Signed-off-by: Ram Lavi <[email protected]>
Moving the snippet setting hugepages to a function. Signed-off-by: Ram Lavi <[email protected]>
Moving setting nsafe_no_io_mmu_mode to a function. Signed-off-by: Ram Lavi <[email protected]>
The first-boot script running by the virt-builder command is run on a service created by virt-builder. This service is guaranteed to run in the final stages of the boot process [0]. This may create a race with the checkup, that is waiting on the agentConnected condition [1] being added in order to run the checkup's executor package. The race is happening since the guest-agent service also runs during the final stages of the boot process. In order to eliminate this race, removing the first-boot script in favor of the new service, and moving the first boot script content into a new service. This service is - manually created on the customize-vm script. - explicitly scheduled to run before the guest-agent service runs. - running the content of the former first-boot script. - running the tuned-adm command formerly set on the customize-vm script. The reason is that this command needs to run on a running guest. Moreover, since this command needs to only run on the first boot of the image, the script is checking the existence of a marker file, then only creating the file after the first run of the snippet. [0] https://www.libguestfs.org/virt-builder.1.html [1] https://github.com/kiagnose/kubevirt-dpdk-checkup/blob/b9b6a472fe92583a0db46361289239e0e8d06284/pkg/internal/checkup/checkup.go#L237 [2] https://www.freedesktop.org/software/systemd/man/latest systemd.unit.html#ConditionPathExists= Signed-off-by: Ram Lavi <[email protected]>
It makes sense to log the guest's kernel args of both VMIs for debugging purposes. Signed-off-by: Ram Lavi <[email protected]>
RamLavi
force-pushed
the
move_first_boot_to_new_service
branch
from
3357895
to
a7fbd81
Compare
|
Change: Review fixes |
orelmisan
approved these changes
Jan 10, 2024
|
passed e2e with CNV 4.15 cluster: kernel Args are correctly updated in the log: |
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.
When creating the vm-under-test and traffic-gen container-disk images, the first-boot script running by the virt-builder command is run on a service created by virt-builder.
This service is guaranteed to run in the final stages of the boot process [0].
This behavior may create a race with the checkup, that is waiting on the
agentConnected condition [1] being added in order to run the checkup's
executor package.
The race is happening since the guest-agent service also runs during the final stages of the boot process.
This PR is solving this race by moving the content of the first-boot script of both VMs to a new service that is guaranteed to run before the guest-agent service.
Fixes #210
[0] https://www.libguestfs.org/virt-builder.1.html
[1]
kubevirt-dpdk-checkup/pkg/internal/checkup/checkup.go
Line 237 in b9b6a47