Increasing the disk size of vmguest without shuting down

olivierlambert

Hi,

You can't grow a VDI size while it's used.

ashinobi

Thanks for the response, would it be possible to add this as an additional feature of xen orchestra in the future?

olivierlambert

It's due to the current storage stack (SMAPIv1). So it's not a Xen Orchestra feature.

However, in SMAPIv3, that would be likely possible, depending on the specific storage driver (ZFS, LVM or other). So let's say "likely" in the future

Read this for an overview: https://xcp-ng.org/blog/2022/06/02/understanding-the-storage-stack-in-xcp-ng/

ashinobi

@olivierlambert

Thank you for the info and congrats as well to you and your team. I read Vates has new office. I hope Vates and XCP-NG grows more bigger in the near future.

KPS

Hi!

As this is something, I have to do quite often: Would it be possible to have a feature: resize on next reboot?

olivierlambert

Resize on next reboot is probably doable via XO itself That's an interesting feature, I wonder how hard to develop it

Any opinion @MathieuRA ?

tjkreidl

@KPS You could put in a task list in the local startup script. See various options here: https://www.baeldung.com/linux/run-script-on-startup

MathieuRA

Hi,
Since XO is a client, I don't think it's a good idea to have this kind of feature. In this case, a VM could be restarted from sources other than XO, and would not apply the new VDI size.

However, I believe we can handle this situation by implementing a modal that appears when editing the VDI size of a running VM. This modal can offer the option to restart the VM immediately and apply the changes. In my opinion, removing the "pending" state will prevent confusion

olivierlambert

@MathieuRA Indeed, that's the right way to do it, I think

odmsys

@olivierlambert I love xcp-ng and the work that you do, and apologize in advance for reviving this old thread, and I'm sure this question has been asked many times, which would probably be a bit frustrating to have repeated if it's something that needs to be implemented upstream or in the storage stack.

I try to steer as many of our clients as possible towards xcp-ng in my work as an MSP, and constructively, I thought it worthwhile to bump this thread to revive interest in this feature, and communicate the feedback that this specific feature (or lack thereof) has on a few occasions been the "deal breaker" leading clients to choose a different hypervisor.

The scenario that comes to mind is one where there's an unexpected surge in storage demand that leads to critically-low disk space on a VM - with xen/xcp-ng this scenario forces an administrator to consider either shutting down a VM to add capacity outside of a planned outage window (potentially creating a brief outage/reducing availability), or else face the consequences of the volume running out of space while the VM is in operation (potentially degrading availability and integrity of data) if the remaining capacity runs out.

As a result, in the interest of uptime we find ourselves feeling the need to allocate more space to virtual disks in xcp-ng to feel we have a "safe" amount of breathing room compared to some of the other hypervisors with similar workloads.

Being able to quickly increase the size of virtual disks without downtime means not only better usage of resources in the long run: it also means reduced downtime for these changes.

It would be great to hear whether this might be on the roadmap with SMAPIv3.

It's also really an excellent suggestion made above regarding the ability to "queue" the disk resize for the next time the VM reboots! This is a flow I've gotten used to in other hypervisors for similar resource changes (such as resizing allocated memory) that cannot happen while the VM is running. If it's faster/more realistic for a feature like this to be implemented in the meantime, it definitely would help with some of the anxieties around managing VM storage capacity. +1 for this if it's more straightforward to schedule a resize upon the next reboot.