Hi! whether this works or not depends on the backend. For example, on Fibre Channel, the VM would still see the same size, because it is still presented from the storage to the hypervisor with the same size. Changing it on the fly requires you to dig deep in Linux SCSI rescans and device mapper resizes, write some disk sizes manually.. Luckily, ext4 refuses to mount when the device is shorted than it should be. A live migrate afterwards tends to help, though. It will get presented correctly to the new hypervisor without manual magic.
To make it short: This use case is not automated on OpenStack side. Tomas -----Original Message----- From: Volodymyr Litovka [mailto:doka...@gmx.com] Sent: Monday, April 23, 2018 10:59 AM To: OpenStack Mailing List Subject: [Openstack] volume state (in-use/available) vs real work Hi colleagues, in order to change (increase) boot disk's size "on the fly", I can do the following sequense of commands without stopping VM: : openstack volume set --state available <volume-id> : openstack volume set --state in-use --size 32 <volume-id> and, if properly configured, disk will be automatically resized by cloud-init during next reboot. Is it dangerous to change volume state to "available" while VM is actively working? Which side-effects I can face while doing this? Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack