Skip to content
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

Allow vm disks to be resized on update #178

Open
ddelnano opened this issue Dec 20, 2021 · 4 comments
Open

Allow vm disks to be resized on update #178

ddelnano opened this issue Dec 20, 2021 · 4 comments

Comments

@ddelnano
Copy link
Collaborator

When a user creates a VM from a template that contains a disk, the disk will be expanded to the size of the VM's specified size. For example, if you have a Ubuntu 20.04 template that has a 10 GB root volume. If you create a VM with a 5 0GB disk, the template's 10 GB disk will be resized to 50 GBs when copied.

Unfortunately this only works when a VM resource is created. We should allow this to work when a VM's disk size is changed (increased). Note: we cannot shrink a disk safely because we shouldn't know if that would corrupt any file systems on it.

@michaelkoetter
Copy link

This seems to be work now ... more or less?
When I apply with an increased disk size, the VDI is grown (or at least shows the updated disk size in XO). But my Ubuntu 20.04 VM immediately freezes and disk IO seems to be stuck. When I hard-reset it, the Hard disk is no longer bootable. I was able to reproduce this multiple times, so it wasn't just bad luck.

This is probably more an XO/XCP-ng issue (because the API lets us do it), or maybe even a guest issue, but maybe it's the reason why the XO UI won't let me change the disk size while the VM is running 😄

Bildschirmfoto 2022-04-10 um 11 41 08

Here's what happened after I changed disk size from 10 -> 20 GiB using terraform:

Bildschirmfoto 2022-04-10 um 11 48 31

Then after a while:

Bildschirmfoto 2022-04-10 um 11 51 53

VM is unbootable after this. DIdn't investigate further and for now just decided to add the following so it should never happen unintentionally:

...
    lifecycle {
        ignore_changes = [
            # changes to disk are risky, so we ignore them
            disk,
        ]
    }
...

@ddelnano
Copy link
Collaborator Author

ddelnano commented Apr 18, 2022

@michaelkoetter thanks for sharing your testing. I agree that it seems like an XCP-ng or guest issue.

I think terraform shouldn't allow a user to do something dangerous like this, so at a bare minimum this shouldn't be allowed when it will cause disk corruption. I'm curious if the resize would work if the VM was shutdown first. If that's the case, then terraform should shutdown the VM, perform the resize and restart it similar to what we do for some VM changes.

@deefdragon
Copy link

yeah, I think this should error out on a change. This Just nuked several disks that I was testing with. Had to reboot to get them to unfreeze, and when I did, they were not even recognized as existing. (VM self shut down after 30 seconds)

I had snapshots, but it was less than Ideal.

@kakopedreros
Copy link

kakopedreros commented Dec 17, 2023

Testing my self in a couple VM based in CentOS 7 and Rocky Linux, using Cloud-init. When i create de VM from a 10 GB template, i can resize without issues, but only when the VDI it's no partitioned in LVM. I try change the RAM and vCPU configuration in a hot-swap test and works!, but the change of the size of the VDI happen as just @michaelkoetter describe, freeze VM, a bunch of XFS errors and when i restart the VM, its not recognizable as a bootable device.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants