Comments 57
1. Выключить виртуальную машину
2. На гипервизоре увеличиваем размер файла (в моем случае на 200 гигабайт)
А бекап уже сделан?
Ежедневно делается.
Люди делятся на две категории:
1.те кто не делают бэкап
2. те, кто уже делают :)
3. Те, кто верифицируют корректность сделанного периодическим тестовым развертыванием.
Согласен! Предлагаю не проверенные бокалы считать не сделанными.
вьі сказали что
… В этом случае проверять и исправлять файловую систему нельзя, fsck -f '...' убьёт файловую систему

А почему? ( тут такая картинка с Боромиром)
Речь идет о примонтированном разделе… С очень высокой вероятностью, при исправлении активного системного диска с открытыми файлами цитирую "… fsck может в тяжёлых случаях залечить файловую систему насмерть, так что иногда, если это возможно, стоит предварительно смонтировать сбойную файловую систему в режиме только чтение и сделать резервную копию того, что ещё можно прочесть."
> А почему?

Потому что fsck редактирует ФС напрямую (открывает файл устройства и читает/пишет), а значит, любые механизмы взаимоисключения (блокировки и т.п.) не работают.

Чинит себе чего-то fsck в списке свободных блоков, а в этот момент какая-то другая программа что-то пишет на диск, и список свободных блоков меняется. Ну и всё, одна из двух записей привела к неконсистентности.
Смотря какая версия и откуда fsck.
Некоторые предупреждают «Filesystem is mounted. Continue? (y/N)».
Зачем используете
формат файла виртуалки qcow2

если
виртуальная машина использует lvm и ext4,

?
Почему не используете LVM гипервизора в качестве LVM виртуальной машины? Спрашиваю, потому что использую такое решение в продакшене, доволен производительностью, диск виртуалки доступен из гипервизора для снэпшота, бэкапа, ресайза и т.д., поэтому абстракцию qcow2 считаю лишней.
Перечитал, понял, что немного не то, что хотел спросить. Поправка: Почему не используете LVM гипервизора в качестве диска виртуальной машины? Просто не вижу причин использовать LVM внутри виртуалки, но не использовать на гипервизоре.
Вариантов организации много, система переделывалась много раз, иногда в спешке. Такое наследие. Вероятно, в момент создания показалось логичным получить наибольшую гибкость таким способом: LVM везде.
UFO landed and left these words here
Вручную создавал физический том и группу томов. Вот замечательная статья на эту тему: LVM — это просто! Дальнейшее прикручивание через virt-manager: добавлял хранилище типа logical (LVM Volume Group), названием которого указывал название группы томов, в нём создавал новый том. В настройках виртуальной машины этот том выбирал в качестве storage («Выберите управляемое или другое существующее хранилище»). С томом можно работать из гипервизора через /dev/mapper.

По поводу ESXi ничего сказать не могу, не работал с ним.
Можно в первом варианте не использовать сервисную машину, а подключить диск к хосту через qemu-nbd
Скажите, оно ПРАВДА не может ресайзить контейнер online?!
qcow же это sparse контейнер, он обязан ресайзиться онлайн без гвоздей O_O
обычно меняется всё онлайн, кроме системного, там нужен один ребут чтобы просто лялих поймал изменение размера диска.
Он там и есть системный. И да, как раз, чтобы поймать размер диска ребут и нужен…
дык это уже онлайн делается после ребута. ребут и тот нужен только в некоторых случаях, когда отказывается видеть изменения хардвары. я всё жду, когда это пофиксят, так как это багом давно висит
Нда. сложно найти стало его — загадили выдачу бесполезными вопросами и ответами на эту тему :(
Повторю попытку чуть позже
Системный тоже можно на лету отресайзить. Для этого в libvirt есть команда:

virsh qemu-monitor-command resized-virtual-machine --hmp "block_resize $DRIVENAME $NEWSIZE"
В Hyper-V с виндой в качестве гостя можно прям онлайн добавить диск, а в госте экспандить раздел на новый диск «без единого разрыва».

Наверняка ведь и здесь так можно.
В демке на TechEd такое делали и для Linux, но вроде без подробностей про настройки гостей.
UFO landed and left these words here
Все проблемы растут из-за использования таблицы разделов. Если её не использовать, всё это можно делать в онлайне.

А с таблицей разделов, для того, чтобы гостя не цеплять к хосту, я написал вот это: github.com/amarao/ptmax.

Получается рутинная операция, которая никакой не «в моменты наименьшей нагрузки».
Если внутри виртуалки обычный mbr или gpt, то еще проще. После ресайза диска в гипервизоре на виртуалке fdisk (или gdisk), дропаем раздел, создаем новый на том же месте но большего размера (с теми же флагами что и были у оригинала), пишем изменения и смотрим в /proc/partitions. Если не зацепило изменения размеров, то ребут виртуалки, если зацепило, resize2fs и все.
Я не знаю, прошло оно или нет, но раньше линуксы намертво отказывались перечитывать таблицу разделов для занятого диска. (а рутовый всегда занят...).
mbr всегда зло. Если в виртуалке голый диск с голым одиноким PV, то ресайз файловой системы можно сделать находу, без единого ребута.

pvresize
lvresize
resize2fs.
Штатная операция же. Увеличивать можно без отмонтирования.
Перед ресайзом надо сделать fsck. А делать его на активной ФС = прощай данные.
«Надо», но не «Необходимо».

При желании (LVM же), можно сделать снапшот, потом снапшот проверить fsck.

Приняв, что вероятность появления новых ошибок с момента снапшота мала, можем выполнить resize2s.

Если возникнет неприятность, есть резервная копия. Проверенная, разумеется.
Сloudinit от Openstack вообще ресайзит разделы из initramfs. А дальше идет штатная загрузка со штатным fsck.
Конечная цель этих действий — предоставить больше дискового пространства для гостевой OS? У вас же LVM.
Добавьте ещё одно блочное устройство и сделайте pvcreate; vgextend; lvextend -r;
Спасибо! «pvcreate; vgextend; lvextend -r;» этим просто раскрыли мне глаза! честно!
Можно вспомнить про интерфейс командной строки, т.е.

virsh shutdown vmname
<тут команда для создания архивной копии VM, как только 'virsh domstate vmname' вернёт 'shut off'>

и так далее.
Если у вас LVM, почему не добавить еще один диск в VM и добавить его в группу?
Как раз для бекапов делают отдельный диск под pagefile — меньше дельта для инкрементальных копий. Но составные группы только для расширения действительно плохая идея, некоторый софт для РК их вовсе не поддерживает.
Поэтому перед началом процесса, лучше отключить систему оповещения по СМС, чтобы не пугать коллег сообщениями типа «Server down» среди ночи.

Заметка на будущее: по-моему, лучше освоить «перевод в режим обслуживания» в вашей системе мониторинга (есть, например, в Zabbix). Вы указываете время и дату (с — по), когда будут проходить технические работы с сервером.

Во-первых, так вы точно не забудете включить мониторинг обратно (по истечении этого срока мониторинг включается автоматически);
Во-вторых, все сис. инженеры видят, что с сервером идут работы, а не мониторинг сломался;
В-третьих, это не затрагивает мониторинг других серверов (если для вас это актуально);
В-четвертых, всегда можно посмотреть, кто, что и во-сколько делал.
Пичаль. Делаю экстенд виртуальных дисков (за исключением содержащих файл подкачки) VMware5+ и Win2008+ почти ежедневно. Все в онлайне. Я ничего не хочу сказать про опенсорс… Ах да, это ж Хабр…
А в чём проблема с экстендом дисков с файлом подкачки? Винда его ровно так же на лету делает. Со времён, по крайней мере, ESXi 3.5…
Если один человек написал свой способ, это не значит, что все так делают и нет более оптимальных.
Ничего не хочу сказать про VMware, кроме того что у них хороший гуй. И производительность на уровне VirtualBox.
Чот вы прям меня даже в сомнения вогнали. Уже два года как увеличение томов в KVM работает онлайн без регистрации и СМС^W в смысле без перезагрузки и даже без LVM :-). Только что проверил, все работает ок.

На хосте — virsh vol-resize, virsh blockresize, на виртуалке — fdisk, resize2fs.

Вот, например, мануал — website-humblec.rhcloud.com/is-it-possible-to-do-online-resizing-of-guest-block-devices-or-without-shutdown/.
> Хотя при работе с highload-проектами адреналина всё равно выделяется достаточно, чтобы 10 раз подумать, перед тем, как что-либо делать.

Чо там думать — отключил сервак от балансера, поресайзил что надо, включил обратно. Не можешь отключить — к тебе по любому придет северный пушной зверек, можешь одевать белые тапочки и топать куда-нибудь, ресайз раздела тут не поможет.
И это, не юзайте костыль с подключением нескольких дисков в один PV. Или включайте NOOP scheduler хотя бы тогда…
В свете всех конструктивных комментариев зачесались руки сделать продолжение. С топиком вроде этого: «Плюсы и минусы возможных способов увеличения размеров дисков виртуальных машин»
Only those users with full accounts are able to leave comments. Log in, please.