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
: openstack volume set --state in-use --size 32
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
