-
Notifications
You must be signed in to change notification settings - Fork 30
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
Take image virtual size into account when creating VMs #976
Conversation
Apparently the tests need work... :-/ |
7d6ad90
to
b0bc468
Compare
Gotta be careful with those |
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. |
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test locally, LGTM.
Remember to backport to release-harvester-v1.4
after merge
@Mergifyio backport release-harvester-v1.4 |
✅ Backports have been created
|
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