OpenNebula

Hello all,

I'm not a Ruby programmer, but I think that this piece of this code can help in this task.

https://github.com/bpaquet/rvc-ext/blob/master/modules/disk.rb#L7-L17
and
https://github.com/Identified/rbvsphere/blob/master/lib/rbvsphere/vm/configure.rb#L26-L34

-Carlos

This looks great! Will this also provide the ability to resize persistent images? (Will this make it possible to resize images that are not attached to vms, such as via Sunstone -> storage -> images or via the oneimage command?)

Needs to update the following Section:

https://github.com/OpenNebula/docs/blob/master/source/operation/vm_management/vm_instances.rst#resizing-vm-disks

John Noss wrote:

This looks great! Will this also provide the ability to resize persistent images? (Will this make it possible to resize images that are not attached to vms, such as via Sunstone -> storage -> images or via the oneimage command?)

Just tested this in the 5.4 beta (5.3.80) from the CLI (onevm disk-resize) and it works for non-persistent disks, but not for persistent disks. I added a fix to the ceph tm_mad to allow it to work for persistent disks too, see https://github.com/OpenNebula/one/pull/330 - can that be included in this for 5.4?

Hi John Noss,

Which version of libvirt and qemu-kvm you are using?

On libvirt 2.0.0/qemu-kvm 2.6.0 the VM is not notified for the disk size change and there is no error raised.

I am preparing a pull request to propose the use of the native libvirt interface to notify the VMs which is working on my setups. Butt it'll need extended testing on the different OS-es

BR,
Anton Todorov

Hi,

There is one more bug but I am exploiting it as a feature so I kindly ask the resolution to have the option to use it.

There is a block in the use of disk-resize when there are disk snapshots.
For qcow2 it is mandatory but it is not an issue for storpool and most probably for other SDS too.
Beside that As there is no option to flatten/delete the last(active) snapshot the disk-resize is blocked for such disks.
Actually this sounds as separate bug?

That said, here is the actual bug I have in mind whe I've started writing the report:

I believe it is a bug that there is not blocking of disk-resize when there are VM snapshots too.

The problem is that I use the feature that uses the VM snapshot interface to do atomic disk snapshots(backups) on all VM disks at once by hooking the VM snapshot_* scripts to local ones (in the VMM_MAD configuration the '-l' argument) . And if you fix the bug by just blocking the disk-resize it will break this "feature" also.

I've not dig in the internals so my blind proposal for resolution is to add an argument to the TM_MAD definition for the given datastore to mark that the given TM_MAD is capable of handling the snapshots case.

Best Regards,
Anton Todorov

John, your PR seems good. We will test it further for inclusion.

Anton:

• About virsh blockresize: We are using qemu-monitor-command as we support some old versions of libvirt (Ubuntu 14.04).
• About resize in Sunstone: There was a misunderstanding and the resize button is only enabled when the VM is in POWEROFF state. We are correcting that. Thanks for the heads up!
• About the bug with snapshots: I don't fully understand the problem here. Maybe as you say it's a separate bug. Are you saying that after a resize you can not take snapshots of a VM?

There's also a bug in Sunstone that enables resize button for context disk that should be taken care.

I'm handing over the issue to Vlastimil Holer but I'll check it if needed.

Ceph disks ... OK¶

The PR https://github.com/OpenNebula/one/pull/330 fixes the resizing of Ceph persistent disks, checked both disk types are working fine.

QCOW2¶

QCOW2 resize is correctly blocked by SUnstone/core if there are disk snapshot(s) present. But, if there are VM snapshots, the resize operation fails after a try. Maybe this is what Anton meant.

Hi,

I'll try to clarify. There are most-probably different issues though:
1. even with ALLOW_ORPHANS="yes" in TM_MAD conf it is not possible to delete any disk snapshot
1.1 Sunstone don't allow deleting "current" snapshot with reason "[one.vm.disksnapshotdelete] Cannot delete the active snapshot"
1.2 Sunstone don't allow deleting "parent" snapshot with reason "[one.vm.disksnapshotdelete] Cannot delete snapshot with children"
1.3 it is not allowed to resize a disk if it has snapshots with reason "[one.vm.diskresize] Cannot resize a disk with snapshots"

(1.4 [new feture?] there is no option to do (atomic)snapshots on all VM disks at once in a single transaction)

All of the above constraints are not issue in StorPool. The snapshots in StorPool are exactly how the snapshot tree is drawn. And the active disk volume is the final leaf to a snapshot then. Each snapshot keeps only the changes against its parent. When a snapshot is deleted its changes are merged to its leaf(s) - either snapshot or the active volume. I'll try to explain with a simple drawing

a VM has one disk named DISK_0, when you do a snapshot it will have

SNAPSHOT_A
     \
      DISK_0

SNAPSHOT_A
     \
      SNAPSHOT_B
           \
            DISK_0

The only thing I can think of is that when a disk snapshot is created the actual disk size should be saved as an attribute to the snapshot and when a snapshot is restored - to alter the value in the VM tample with the value saved in the snapshot.
For example if we have a disk with size 10GB, take a snapshot and then resize the disk to 15 GB. When you revert the disk to the snapshot the resulting disk size will be reverted back to 10GB.

I am almost sure same is with CEPH too.

Regarding the VM snapshots.
When managed by libvirt they are locked to the current KVM host and for qcow2 images only. OpenNebula correctly delete the VM snapshots on migrate with KEEP_SNAPSHOTS=no in VMM_MAD. StorPool has no integration with libvirt so the VM snapshot interface is re-purposed to do (1.4 from above) - atomic snapshots on all disks with a single transaction. I achieve this by defining custom local snapshot scripts and setting KEEP_SNAPSHOTS=yes in the VMM_MAD configuration vector for KVM. Again the VM disk resize is in not limited in any way. The only issue is again the disk sizes in the internal VM_TEMPLATE for the cases when there are disk resizes involved after a snapshot is taken. Currently I am stopping oned and altering the database. An API interface to alter only the value would be greatly appreciate :)

There are some more features I am working on:
+ option to limit the number of snapshots per VM (disk and/or "modified" VM snapshots). Configurable per VM or a global attribute in the SYSTEM datastore template.
+ option to export a VM disk from given VM snapshot as a new image - there is a customer with this feature request(to fight ransomware somehow...)

As I am awful in the big explanations you are welcome to ask any questions to clarify :)

Best Regards,
Anton Todorov

Hi Anton,

Anton Todorov wrote:

I'll try to clarify. There are most-probably different issues though:
1. even with ALLOW_ORPHANS="yes" in TM_MAD conf it is not possible to delete any disk snapshot
1.1 Sunstone don't allow deleting "current" snapshot with reason "[one.vm.disksnapshotdelete] Cannot delete the active snapshot"
1.2 Sunstone don't allow deleting "parent" snapshot with reason "[one.vm.disksnapshotdelete] Cannot delete snapshot with children"
(1.4 [new feture?] there is no option to do (atomic)snapshots on all VM disks at once in a single transaction)

I have made a separate feature request for these points
https://dev.opennebula.org/issues/5223
as they aren't much related to the core resize feature. Please, subscribe to the ticket to keep updated.

1.3 it is not allowed to resize a disk if it has snapshots with reason "[one.vm.diskresize] Cannot resize a disk with snapshots"

Yes, this is a known issue I have mentioned above.

I'm going to close this issue now, as the intended resize functionality targeting the release 5.4 is working. We will try to improve the resize and snapshots management in the next release.

Best regards,
Vlastimil Holer