т.е. останавливаю виртуалку, деатач и увеличиваю

отключаешь от инстанса диск (detach), затем деалешь extend и снова подключаешь. Если же это корневой диск созданный nova или эфемерный диск, то тут надо будет сделать вот как: Сделать снапшот диска, преобразовав его в образ Сделать ребилд инстанса выбрав нужный flavor и указав в качестве источника твой свежесозданный образ. Вроде ничо не напутал и глупостей не написал)

Ну смотри, при создании виртаулки диск может создаваться либо сразу через cinder либо средствами nova (тогда этот диск жестко привязан к виртуалке и живет только пока она существует. Его размер нельзя менять и много чо еще нельзя с ним делать). Но такой диск удобен чисто чтоб держать н анем систему, например.

Ситуация точно такая же...вмка создана с флевором м1.медиум...

Ну смотри, при создании виртаулки диск может создаваться либо сразу через cinder либо средствами nova (тогда этот диск жестко привязан к виртуалке и живет только пока она существует. Его размер нельзя менять и много чо еще нельзя с ним делать). Но такой диск удобен чисто чтоб держать н анем систему, например.

Что за гон, только что проверил, диски созданные новой ресайзятся на новый флавор с автоматическим екстендом (grow-part cloud-init)

Ну такой мягкий наезд ага, имеет место быть )

Наезд?) Я что-то действительно протупил, при обычном переходе с одного флейвора на другой все и так сработает, диск увеличится без потери данных.

Т.е. достаточно сменить флавор, и диск увеличится без всяких манипуляций?

Подскажите, может кто сталкивался - в галера кластере постоянно вижу варнинги : 018-05-07 13:35:09 140259501693696 [Warning] Aborted connection 773 to db: 'keystone' user: 'keystone' host: 'openstack-controller1' (Got an error reading communication packets) 2018-05-07 13:36:15 140259501693696 [Warning] Aborted connection 807 to db: 'keystone' user: 'keystone' host: 'openstack-controller1' (Got an error reading communication packets) кластер поднят с нуля, ваонинги вижу как только запускаю инициализацию keystone su -s /bin/sh -c "keystone-manage db_sync" keystone Вроде ни на что не влиеят, но непряяно ( Смотрел tcpdump - обрывов соединения не видно, внутри команды проходят без ошибок, на сетевых интерфейсах ошибок нет. Все что в инете нагуглил не помогло ((

Если бы диск был не рутовый, то надо было бы детач делать и расширять.

Тоже гон ))) достаточно сделать резет стейт на аваилабл, заекстендить, резет стейт - ин юз, партедом расширить

Не нужно детачить

Он отцепляется, это так, но он отцепляется от ВМ, это даунтайм, а резет-стейт просто меняет значение в базе, без детача

Т.е. можно и ядра и оперативу на горячую добавить?

Наезд?) Когда важен sla это не проблема поменять статус, вместо детача

Т.е. можно и ядра и оперативу на горячую добавить?

Тут не, тут придется перезагружать. Точнее, выключить и включить.

Наезд?) Когда важен sla это не проблема поменять статус, вместо детача

Но ты не прав в том что говоришь про даунтайм) Прицеплять и отцеплять можно ж на горячую.

Ну это ж не вмваре тебе)

Жаль (

В вмваре тоже с ребутом насколько я знаю

другой вопрос, что гость должен это замечать автомагически. windows замечает. linux нужно пинать.

Сиквел перестанет работать на время детача

Тож от правил udev зависит и от ядра.

в моей практике el честно сам не замечал докидывание cpu/ram

сиквел?

А ебунта?

СУБД, mysql например, но не принципиально

С ебунтой норм, пока не было геморроя.

Под какие задачи нужно столько vm, капец

Тоже гон ))) достаточно сделать резет стейт на аваилабл, заекстендить, резет стейт - ин юз, партедом расширить

Четкий хак! Только потом каши не будет....если там бд внутри?

не будет если бакэендом ceph