Hi Eugen,
actually, I did some tests with making volume available without stopping
it. I'm using CEPH and these steps produce the following results:
1) openstack volume set --state available [UUID]
- nothing changed inside both VM (volume is still connected) and CEPH
2) openstack volume set --size [new size] --state in-use [UUID]
- nothing changed inside VM (volume is still connected and has an old size)
- size of CEPH volume changed to the new value
3) during these operations I was copying a lot of data from external
source and all md5 sums are the same on both VM and source
4) changes on VM happens upon any kind of power-cycle (e.g. reboot
(either soft or hard): openstack server reboot [--hard] [VM uuid] )
- note: NOT after 'reboot' from inside VM
I think, all these manipilations with cinder/ceph just update internal
parameters of these subsystems, without immediate effect for VMs. In
order to apply for the changes, you need to power-cycle it.
From practical point of view, it's useful when you, for example, update
project in batch mode, and will then manually reboot every VM, affected
by the update, with minimized downtime (it's just reboot, not manual
stop/update/start).
On 6/15/18 10:34 AM, Eugen Block wrote:
Hi,
did you find a solution yet?
If not, I tried to rebuild your situation with a test instance.
Although the environment and the storage backend are different, I
believe it still applies to your issue, at least in a general way.
I have an instance booted from volume (size 1 GB). Trying to resize
the instance via Horizon dashboard works (at least you would think
that), it shows a new flavor with a disk size 8 GB. But the volume has
not been resized, so the instance won't notice any changes.
To accomplish that, I had to shutdown the vm, set the volume state to
available (you can't detach a root disk volume), then resize the
volume to the size of the flavor, and then boot the vm again, now its
disk has the desired size.
control:~ # openstack server stop test1
control:~ # openstack volume set --state available
b832f798-e0de-4338-836a-07375f3ae3a0
control:~ # openstack volume set --size 8
b832f798-e0de-4338-836a-07375f3ae3a0
control:~ # openstack volume set --state in-use
b832f798-e0de-4338-836a-07375f3ae3a0
control:~ # openstack server start test1
I should mention that I use live-migration, so during resize of an
instance it migrates to another compute node.
Hope this helps!
Regards
Eugen
Zitat von Manuel Sopena Ballesteros :
Dear openstack community,
I have a packstack all-in-one environment and I would like to resize
one of the vms. It seems like the resize process fails due to an
issue with cinder
NOTE: the vm boots from volume and not from image
This is the vm I am trying to resize
[root@openstack ~(keystone_admin)]# openstack server show
7292a929-54d9-4ce6-a595-aaf93a2be320
+--++
| Field | Value
|
+--++
| OS-DCF:diskConfig | MANUAL
|
| OS-EXT-AZ:availability_zone | nova
|
| OS-EXT-SRV-ATTR:host | openstack.localdomain
|
| OS-EXT-SRV-ATTR:hypervisor_hostname | openstack.localdomain
|
| OS-EXT-SRV-ATTR:instance_name | instance-005f
|
| OS-EXT-STS:power_state | Shutdown
|
| OS-EXT-STS:task_state | None
|
| OS-EXT-STS:vm_state | error
|
| OS-SRV-USG:launched_at | 2018-05-14T07:24:00.00
|
| OS-SRV-USG:terminated_at | None
|
| accessIPv4 | |
| accessIPv6 | |
| addresses |
privatenetwork=192.168.1.106, 129.94.14.238 |
| config_drive | |
| created | 2018-05-14T07:23:52Z
|
| fault | {u'message': u'The server
has either erred or is incapabl
