Take image virtual size into account when creating VMs (backport #976) #1104
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
![mergify[bot]](https://avatars.githubusercontent.com/in/10562?s=60&v=4){kind=small}
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 <tserong@suse.com> (cherry picked from commit db0a588)
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 <tserong@suse.com> (cherry picked from commit 90e6535)
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 <tserong@suse.com> (cherry picked from commit ec15f49)
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 <tserong@suse.com> (cherry picked from commit a0cc74c)
a110605
approved these changes
Aug 16, 2024
tserong
added a commit
to tserong/dashboard
that referenced
this pull request
Aug 27, 2024
This is a followup to harvester#1104 When creating new volumes from VM images on the Volume screen, the default size is empty, i.e. it's not pre-filled with anything at all. If the source is set to "VM image" we can now take the image virtual size and use that as the default size for the volume. Unlike when creating VMs (which always set the volume to a minimum of 10GiB regardless of virtual size, for consistency with earlier harvester versions), on this screen we just use the virtual size as-is. If the user wants to make it bigger, they can. Related issue: harvester/harvester#4905 Signed-off-by: Tim Serong <tserong@suse.com>
tserong
added a commit
to tserong/dashboard
that referenced
this pull request
Aug 27, 2024
This is a followup to harvester#1104 When creating new volumes on the Volume screen in Harvester, the default size is empty, i.e. it's not pre-filled with anything at all. If the source is set to "VM image" we can now take the image virtual size and use that as the default size for the volume. Unlike when creating VMs (which always set the volume to a minimum of 10GiB regardless of virtual size, for consistency with earlier harvester versions), on this screen we just use the virtual size as-is. If the user wants to make it bigger, they can. Related issue: harvester/harvester#4905 Signed-off-by: Tim Serong <tserong@suse.com>
tserong
added a commit
to tserong/dashboard
that referenced
this pull request
Aug 27, 2024
This is a followup to harvester#1104 When creating new volumes on the Volume screen in Harvester, the default size is empty, i.e. it's not pre-filled with anything at all. If the source is set to "VM image" we can now take the image virtual size and use that as the default size for the volume. Unlike when creating VMs (which always set the volume to a minimum of 10GiB regardless of virtual size, for consistency with earlier harvester versions), on this screen we just use the virtual size as-is. If the user wants to make it bigger, they can. Related issue: harvester/harvester#4905 Signed-off-by: Tim Serong <tserong@suse.com>
tserong
added a commit
to tserong/dashboard
that referenced
this pull request
Aug 29, 2024
This is a followup to harvester#1104 When creating new volumes on the Volume screen in Harvester, the default size is empty, i.e. it's not pre-filled with anything at all. If the source is set to "VM image" we can now take the image virtual size and use that as the default size for the volume. Unlike when creating VMs (which always set the volume to a minimum of 10GiB regardless of virtual size, for consistency with earlier harvester versions), on this screen we just use the virtual size as-is. If the user wants to make it bigger, they can. Related issue: harvester/harvester#4905 Signed-off-by: Tim Serong <tserong@suse.com> Co-authored-by: Volker Theile <vtheile@suse.com>
tserong
added a commit
to tserong/dashboard
that referenced
this pull request
Aug 29, 2024
This is a followup to harvester#1104 When creating new volumes on the Volume screen in Harvester, the default size is empty, i.e. it's not pre-filled with anything at all. If the source is set to "VM image" we can now take the image virtual size and use that as the default size for the volume. Unlike when creating VMs (which always set the volume to a minimum of 10GiB regardless of virtual size, for consistency with earlier harvester versions), on this screen we just use the virtual size as-is. If the user wants to make it bigger, they can. Related issue: harvester/harvester#4905 Signed-off-by: Tim Serong <tserong@suse.com> Co-authored-by: Volker Theile <vtheile@suse.com>
mergify bot
pushed a commit
that referenced
this pull request
Sep 12, 2024
This is a followup to #1104 When creating new volumes on the Volume screen in Harvester, the default size is empty, i.e. it's not pre-filled with anything at all. If the source is set to "VM image" we can now take the image virtual size and use that as the default size for the volume. Unlike when creating VMs (which always set the volume to a minimum of 10GiB regardless of virtual size, for consistency with earlier harvester versions), on this screen we just use the virtual size as-is. If the user wants to make it bigger, they can. Related issue: harvester/harvester#4905 Signed-off-by: Tim Serong <tserong@suse.com> Co-authored-by: Volker Theile <vtheile@suse.com> (cherry picked from commit 3778552)
a110605
pushed a commit
that referenced
this pull request
Sep 16, 2024
This is a followup to #1104 When creating new volumes on the Volume screen in Harvester, the default size is empty, i.e. it's not pre-filled with anything at all. If the source is set to "VM image" we can now take the image virtual size and use that as the default size for the volume. Unlike when creating VMs (which always set the volume to a minimum of 10GiB regardless of virtual size, for consistency with earlier harvester versions), on this screen we just use the virtual size as-is. If the user wants to make it bigger, they can. Related issue: harvester/harvester#4905 Signed-off-by: Tim Serong <tserong@suse.com> Co-authored-by: Volker Theile <vtheile@suse.com> (cherry picked from commit 3778552)
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
This is an automatic backport of pull request #976 done by Mergify.