Patch for one.image.resize to resize image
|Category:||Core & System|
This patch (against 3.8.1) adds a one.image.resize call to resize image.
The call takes 2 parameters: The image ID and the new size.
- It works for image that are in READY state (with some more work, it could be extended to USED state to allow non-persistent sources to be resized, and USED_PERS to allow online resizing).
- It requires the MANAGE IMAGE permission on an image to issue a resize action.
- It checks the image owner quota before accepting the resize.
- It sets the image in LOCKED state and calls a new datastore driver action, RESIZE.
- If the driver returns SUCCESS, it sets the image back to READY state, otherwise the image is set to ERROR.
This patch doesn't implement the RESIZE action in any of the datastore drivers shipped with OpenNebula. It only implements the resize at the OpenNebula Core level. The datastore drivers needs to be updated to handle the RESIZE action.
Beware that issuing a one.image.resize call to a datastore that wasn't updated to support the RESIZE action will leave the image in LOCKED (or ERROR) state.
Feedbacks are more than welcome!
Feature #1727: Do not allow disk resize for persistent images, and for a smaller size
Feature #1727: Fix system_disk quotas
Add DS disk attributes; add disk-snapshots to total
Feature #1727: Generic system to allow to resize
on onetemplate instantiate from the CLI
Feature #1727: Document adding extra attributes to disk and nic
on onetemplate instantiate
#5 Updated by Ruben S. Montero over 7 years ago
Given the comments, I think this is better to be moved to the TM's. Images keep their potentially minimal size in the datastore. The TM then resizes the disk once the image is copied to the host, as described by #179.
In this case the interface would be:
DISK = [ IMAGE="Server CentOS", size="10GB" ]
The TM will then resize the image. Other considerations:
1.- Live resize of disk images won't be supported by all the TM's.
2.- It will only work for non-persistent images.
#7 Updated by Simon Boulet over 7 years ago
Why not do both? Allow non-persistent image size to be specified at VM / template instantiation (independent of the initial data store image), and also have a method for updating persistent image size?
Currently all my images are persistent. I use the method in #1865 to tell my driver what final size the image is to be. My VM CREATE hooks picks up the new template and calls the one.image.resize (above patches) to set the size of the persistent image.
#10 Updated by Vladislav Gorbunov almost 7 years ago
I myself understood. Files with patches for resize image from command line (with oneimage) is in attachment. In datastore must be the script "resize" that do image resizing in datastore or return 0 exit code. Simon's path for OpenNebula 4.2 worked for OpenNebula 4.4.
#24 Updated by Stefan Kooman over 5 years ago
When resizing RAW images and or LVM backed virtual machines the following virsh command allows to update the new disk size to the live running VM:
virsh qemu-monitor-command one-ID --hmp "block_resize drive-virtio-disk0 size B". Where "drive-virtio-disk0" is the first disk of the virtual machine. To obtain a list of disks this command can be used "virsh qemu-monitor-command ONE-ID –hmp “info block”.
As these are "virsh" commands I guess there are equivalent libvirt API calls. It would be incredibly helpfull if this could be incorporated in "one.image.resize". It would make online resizing a breaze. If a image has (external) snapshots it should not be allowed to resize the disk in this manner, since the backing file is (expected to be) read-only.
#25 Updated by Stefan Kooman over 5 years ago
For some reason the "info block" command only works when I'm already in virsh shell:
virsh # qemu-monitor-command one-103 --hmp "info block"
drive-virtio-disk0: /var/lib/one//datastores/100/103/disk.0 (qcow2)
drive-ide0-0-0: /var/lib/one//datastores/100/103/disk.1 (raw, read-only)
Removable device: locked, tray closed
- virsh qemu-monitor-command one-103 --hmp “info block”
unknown command: '“info'
#26 Updated by Stefan Kooman over 5 years ago
Resizing can be done more easily with "virsh blockresize" command or libvirt API call "virDomainBlockResize": https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainBlockResize
#27 Updated by Ruben S. Montero about 5 years ago
- Tracker changed from Feature to Backlog
- Status changed from New to Pending
- Assignee deleted (
- Target version changed from Release 4.14 to Release 5.0
4.14 implements the ability to expand (resize) disk images on hypervisors at VM deployment. This issue is kept for resizing images in the datastore.