Take image virtual size into account when creating VMs #976
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
|
Example display of the Virtual Size column:
|
|
Apparently the tests need work... :-/ |
7d6ad90
to
b0bc468
Compare
|
Gotta be careful with those |
torchiaf
reviewed
Mar 27, 2024
torchiaf
reviewed
Mar 27, 2024
b0bc468
to
14ddad5
Compare
14ddad5
to
56d8dcc
Compare
|
Rebased on latest master. Relies on harvester/harvester#5387 which is not yet merged, but otherwise ready for review. |
This was referenced May 24, 2024
56d8dcc
to
afe0631
Compare
|
Updated to add Virtual Size to the image detail page (thanks for the suggestion @bk201)
|
|
...and now that harvester/harvester#5387 is in, this is actually possible to test and good to review! |
The onImageChange() function in edit/kubevirt.io.virtualmachine/VirtualMachineVolume/type/vmImage.vue includes logic to set type="cd-rom" and bus="sata" when you select an ISO image as the source for a volume. This commit applies the same logic when initially creating a VM from a given image. Signed-off-by: Tim Serong <[email protected]>
The onImageChange() function sets the VM volume type="cd-rom" and bus="sata" when an ISO image is selected, but it only works for the first volume. This commit enables the automatic type and bus selection for all volumes attached to a VM. Related issue: harvester/harvester#5142 Signed-off-by: Tim Serong <[email protected]>
Prior to this, the default size for volumes attached to VMs was 10GiB, regardless of the size of the underlying image. This is fine if the image is smaller, but if the image is either physically larger (as in the case of a >10GiB ISO), or has a larger virtual size (as can be true with qcow2 images), the result is a corrupt volume. This commit fixes the problem by checking both the physical size and virtual size of the image, and using whichever is greater as the default size of the volume. Virtual size should always be >= physical size, but it is still theoretically possible for either value to be zero in case of error, so taking the greater of the two is the safest approach. There are two exceptions to the above rule: 1) For non-ISO images, if the image is < 10GiB, we still default to a size of 10GiB for consistency with the behaviour of earlier Harvester releases. The user can always lower this if they want/need to. 2) ISO images smaller than 1GiB will be given a size of 1GiB, simply because the size control in the UI is set to work in GiB units. It is actually possible to get a value of 0.2 GiB in there for a 200MiB ISO, but doing that is pretty ugly IMO, and there's no real harm in having the volume that backs a CD-ROM image be a bit larger than the source in this case. Related issue: harvester/harvester#4905 Related issue: harvester/harvester#2189 Signed-off-by: Tim Serong <[email protected]>
This commit adds Virtual Size as an additional column when listing images. I don't know whether or not this is the best way to present this information. Another alternative could be to make the existing Size column simply report the greater of Size and Virtual Size, on the assumption that what you really care about is the size that a volume needs to be when based on that image. I've also added Virtual Size to the Image Detail page. Related issue: harvester/harvester#4905 Signed-off-by: Tim Serong <[email protected]>
afe0631
to
a0cc74c
Compare
|
Rebased on latest master |
a110605
approved these changes
Aug 16, 2024
|
@Mergifyio backport release-harvester-v1.4 |
✅ Backports have been created
|
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.
Prior to this, the default size for volumes attached to VMs was 10GiB, regardless of the size of the underlying image. This is fine if the image is smaller, but if the image is either physically larger (as in the case of a >10GiB ISO), or has a larger virtual size (as can be true with qcow2 images), the result is a corrupt volume.
This PR fixes the problem by checking both the physical size and virtual size of the image, and using whichever is greater as the default size of the volume. Virtual size should always be >= physical size, but it is still theoretically possible for either value to be zero in case of error, so taking the greater of the two is the safest approach.
There are two exceptions to the above rule:
This PR also adds Virtual Size as an additional column when listing images. I don't know whether or not this is the best way to present this information. Another alternative could be to make the existing Size column simply report the greater of Size and Virtual Size, on the assumption that what you really care about is the size that a volume needs to be when based on that image.
I've included a couple other small tweaks as well relating to automatically setting disk type and bus for ISO images (see the commit messages for details).
Note that this PR depends on harvester/harvester#5387 which in turn depends on changes in Longhorn.
Related issue: harvester/harvester#5142
Related issue: harvester/harvester#4905
Related issue: harvester/harvester#2189