LVM. Увеличить размер.

pvresize не увеличит размер раздела под ним, man fdisk. Вообще gdsik, конечно, но тут уже наговнякана DOS-разметка 😂

Ну я смотрю можно fdisk’ом эти 512мб разметить и в вольюмгруппу добавить, но я бы хотел обойтись одним физическим диском в виртуалке

Совет на будущее: добавь еще один диск vdb

его vdb полностью (без разделов) добавь в lvm

когда надо будет его увеличить: увеличить со стороны хоста, а в госте:

echo 1 > /sys/block/vdb/device/rescan

pvresize /dev/vdb

lvextend …

РАЗМЕР. РАЗДЕЛА. УВЕЛИЧЬ.

fdisk’ом можно, но это не для слабонервных. Возьми parted какой, что ли. А уже потом увеличивай том через pvresize, он с таблицей разделов не работает.

Удали vda5, создай заново с полным размером, потом уже pvresize. Или parted какой-нибудь, если боишься напортачить.

man growpart

Enlarge your LVM.

если я правильно понял задачу. то ничего не получится пока не удалить раздел «лету» и не создать новый, но с точкой старта именно в том же месте где был старый…

это потому что LVM не на всём диске. Потренируйся на виртуалке:

1. добавляешь место
2. потом заходишь через fdisk/cfdisk и удаляешь раздел (sic!) запоминаешь Start
3. сразу не выходя добавляешь новый. он то как раз и будет больше
4. а потом уже pvresize / lvextend и т.д.

советую потренироваться :)

ну либо да добавить просто еще один диск к ВМ. но это не красиво

З.Ы. если весь диск под LVM это делать ненадо

ничего не получится пока не удалить раздел

При установке ОСи был выбран LVM. То есть debian (в моём случае) гибкость при использовании LVM предоставляет только крутить туда<->сюда вольюм группу и логические диски, считая, что я если я физический диск воткнул один, то увеличить я его не могу. Я правильно понимаю?

С одной стороны это верно. Размер физического диска в теории увеличить невозможно.
С другой стороны, как в моём случае, физический диск виртуалки - это логический диск на гипервизоре, который я без труда увеличил.

Интересно, разрабам писал кто-нибудь по этому поводу?

Нет никакой проблемы увеличить раздел. Вообще. Это стандартная операция.

Если страшно/не хочется лезть в fdisk, по выше уже советовали команду growpart - она все сделает сама.

Кроме виртуальных дисков у гипервизоров на физические сервера диски могут прилетать с СХД по SAN, и они также прекрасно увеличиваются.

Совет на будущее: добавь еще один диск vdb

книга вредных советов, том. 65314…

Если страшно/не хочется лезть в fdisk

Как раз-таки наоборот мой минимализм призывает юзать то, что предустановлено и не обращаться к стороннему софту.

Погуглил, понял, что можно fdisk’ом грохнуть и создать раздел заново. Пишут что данные не удалятся, но что-то как-то мало верится в это

Это просто шелловский скрипт. В первый раз всегда страшно :)

В первый раз всегда страшно :)

Вот так было

Device     Boot   Start     End Sectors  Size Id Type
/dev/vda1  *       2048  999423  997376  487M 83 Linux
/dev/vda2       1001470 8386559 7385090  3.5G  5 Extended
/dev/vda5       1001472 8386559 7385088  3.5G 8e Linux LVM

Вот так сейчас делаю

Device     Boot   Start     End Sectors  Size Id Type
/dev/vda1  *       2048  999423  997376  487M 83 Linux
/dev/vda2        999424 9437183 8437760    4G  5 Extended
/dev/vda5       1001472 9437183 8435712    4G 8e Linux LVM

Меня смущает откуда начинает стартовать vda2. Почему дебиан при разметке оставил сектора между vda1 и vda2?
Я ничего не форматирую, просто удалил и создал раздел заново.
Осталось нажать клавишу w.
Я всё правильно делаю? Клавишу жму?

Очевидно, выравнивал на границу 2048 сектора. Пофиг, жми.

Пофиг, жми.

Затёр походу всё к х*** жукам майским. В принципе это реверспрокси и нужные конфиги я стянул от туда. Заново всё установить - 15 минут с перекурами, но хотелось бы попробовать восстановиться. lvmdiskscan показывает

  /dev/live-base [    <511.24 MiB] 
  /dev/vda1      [     487.00 MiB] 
  /dev/vda5      [       4.02 GiB] 
  1 disk
  2 partitions
  0 LVM physical volume whole disks
  0 LVM physical volumes

0 физических волюмов. Как-то можно что-то сделать?

Конечно. Все, что изменилось - 32 байта в первом секторе диска.
Попробуй создать разделы по старым смещениям.

Решил взглянуть как дебиан по дефолту размечает диск
-> сорян за скрин <-
При такой схеме можно без гемора добавить vdb и втулить его в в группу томов, расширив её при этом, но я не понимаю почему такой гемор при физическом увеличении диска…?!?

В таком случае мне кажется проще создавать для виртуалки 2 диска. 512мб под /boot, а второй уже под lvm, который можно уже без проблем тянуть как захочешь. Но так будет некрасиво

Затереться что-то там могло, если ты не заметил и подтвердил удаление fdisk’ом сигнатуры lvm при пересоздании раздела. А так согласно второму выхлопу fdisk начало увеличенного vda5 там же, где и было, следовательно, если ничего не затирать, данные должны быть на месте. Можно hexdump -C поглядеть sda3, там по смещению 0x200 сигнатура «LABELONE» и данные о PV должны лежать (размер, uuid и ещё что-то)

Моя подсказка как я делал ранее: Как расширить диск lvm иерархическая структура: lv — логический vg — виртуальные группы pv — физический

смотрим и делаем

vgdisplay
lvextend -l +100%FREE /dev/ubuntu-vg-1/ubuntu-lv
resize2fs /dev/ubuntu-vg-1/ubuntu-lv

lsblk
df -h
fdisk -l

обоснуй

З.Ы. как показал опыт ТС игры с разделами это «вредные советы»

В таком случае мне кажется проще создавать для виртуалки 2 диска. 512мб под /boot, а второй уже под lvm, который можно уже без проблем тянуть как захочешь.

Один диск под систему (vgroot), он скорее всего рости не будет

Второй диск без разделов (vgdata) под данные

Но так будет некрасиво

Ты идиот?

А почему у тебя тут End одинаковый? Вот из-за этого наверное и не получилось. Надо чтобы он был такой же как и до удаления. И тип тоже

В целом это не вредные советы, а чуть ли не единственный верный способ увеличения LVM если на диске не только он.

Потренируйся на виртуалке и у тебя все получится в следующий раз. Потом будет не так страшно :) хотя мне до сих пор иногда страшно)

А для чего там вообще vda2?

обоснуй

Чего тут обосновывать, рассыпается это всё на раз. LVM - не замена mdadm.

А у ТС типичный skill issue, там делов на две команды.

рассыпается это всё на раз. LVM - не замена mdadm.

Еще один идиот?

Мы о виртуалке говорим. С хоста диск может и с mdadm/btrfs/zfs идти со всеми резервами. Что у тебя в вирте развалится? И откуда вообще разговор о резервировании?

fdisk’ом можно, но это не для слабонервных. Возьми parted какой, что ли.

НЕТ, только не это. parted - недоразумения кусок. Он пытается ещё и ФС ресайзить, но не очень умеет это делать. Вроде бы в последних версиях отучили страдать фигнёй, но не проверял

Лучше уж через fdisk/gdisk, но осторожно и внимательно

почему такой гемор при физическом увеличении диска…?!?

потому что в реальном мире диски не меняются. потому что надо отделять системный диск, который почти не растет, от данных

и тогда все будет безгеморно

Он говорит о том, что PV лучше создавать непосредственно на всем диске, без прослоек в виде партиций, пусть даже и gpt

Про склейку ты додумал сам. Возможно, он предложил бы мигрировать данные на второй диск и оставить на первом чисто загрузчик с /boot. Ну может ещё старый раздел удалить и создать в новой группе со свопом

И к тому же, для ВМ, которая лежит на уже надёжном хранилице, при необходимости можно и склеить диски, без проблем.

не понимаю почему такой гемор при физическом увеличении диска…?!?

Ни mbr, ни gpt не позволят увеличить раздел на лету. Ну, скорее код ядре, но не суть. Изменение разделов без даунтайма - это lvm непосредственно поверх диска. Если ты создал PV на партиции, ссзб

В таком случае мне кажется проще создавать для виртуалки 2 диска. 512мб под /boot, а второй уже под lvm, который можно уже без проблем тянуть как захочешь. Но так будет некрасиво

Чем некрасиво? Хорошее решение

growpart

делает ресайз партиций на лету

Еще один идиот?

Идиот был твой отец, потому что не предохранялся.

Мы о виртуалке говорим. С хоста диск может и с mdadm/btrfs/zfs идти со всеми резервами. Что у тебя в вирте развалится? И откуда вообще разговор о резервировании?

Ты ж предлагаешь расширять vg за счет второго pv. Так делать не надо, если не хочешь огрести проблем потом. Причем тут резервирование?

Ни mbr, ни gpt не позволят увеличить раздел на лету. Ну, скорее код ядре, но не суть

Наглое 4.2, берешь и пересоздаешь раздел c тем же началом и другим концом, а затем перечитываешь. Другое дело, что это нифига не безопасно (особенно если промахнулся) и не best practice. Но технически возможно.

Наглое 4.2, берешь и пересоздаешь раздел c тем же началом и другим концом, а затем перечитываешь. Другое дело, что это нифига не безопасно (особенно если промахнулся) и не best practice. Но технически возможно.

Возможно, поменяли. ЕМНИП, раньше (2.6 ?) было нельзя

Да, в RHEL6 было нельзя без перезагрузки. В RHEL7 стало можно.

В общем-то стандартная разметка системного диска, в RHEL так же. Разве что LVM лежит не в расширенном разделе, а в первичном.

Ты что-то сделал не так. fdisk может предложить затереть сигнатуру LVM в начале раздела. Не ответил ли ты «yes» на этот вопрос?

Затёр походу всё к х*** жукам майским.

В любом случае, надеюсь ты понимаешь, что все попытки восстановления делаются на копии данных? А оригинал отложен за угол и не подвергается больше никаким изменениям

Сохранился лог сессии? Например, в открытом терминале?

Как уже сказали, возможно ты проглядел, что fdisk предложил зачистить «lvm member signature»

Created a new partition 1 of type 'Linux' and of size 3 GiB.
Partition #1 contains a LVM2_member signature.

Do you want to remove the signature? [Y]es/[N]o: n

Тогда рецепт примерно такой: https://serverfault.com/questions/1016744/recover-deleted-lvm-signature

Если бы у тебя сохранился бекап метаданных lvm (он сохраняется при каждом изменении и вроде бы при каждой загрузке в /etc/lvm/backup/), было бы проще

Метаданные предположительно не затерты и все еще лежат в начале PV, в первом 1 MiB

Меня смущает откуда начинает стартовать vda2. Почему дебиан при разметке оставил сектора между vda1 и vda2?

Меня это тоже смущает. Никогда намеренно не использовал msdos extended partition. Но вроде бы важно только смещение vda5, а не extended контейнера, в котором он создан

Попробуй testdisk. В принципе, даже если pv и не восстановишь, почти наверняка единственный LV был на весь PV и его можно вытащить через dd

расширять vg за счет второго pv. Так делать не надо,

Ты опять идиот.

Ты ж предлагаешь расширять vg за счет второго pv. Так делать не надо, если не хочешь огрести проблем потом.

Не только моно, но и нуна, если цель lvm raid

потому что не предохранялся.

Риск потери данных зависит от того, где расположены эти PV. В случае ВМ ~80%, что он будет расположен в том же хранилище, что и старый PV. При этом добавить новый диск или расширить старый - монопенисуально

Всегда нужно адекватно оценивать риск и помнить тервер. Аргументы в стиле доты «люк, я твой отец» среди инженеров не котируются

bigbit router сигнатуру затерел (опустил виновато голову), но это был реверспрокси и я предварительно выдернул конфиги виртуальных хостов, чтоб не вспоминать потом куда, как и на какой порт что проксируют.

Развернул всё заново, подкинул всё назад, летсэнкриптом сгенерировал https и всё работает.

Решил попробовать так, как с пеной у рта советует futurama у которого все идиоты…=) Под бут lvcreate’нул 512мб, под данные 4G. Получилось так

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda     254:0    0  512M  0 disk 
└─vda1  254:1    0  510M  0 part /boot
vdb     254:16   0    4G  0 disk 
└─vdb1  254:17   0    4G  0 part 
  └─v-l 253:0    0    4G  0 lvm  /

А некрасиво - это на гипервизоре, где помимо наименования одного блочного устройства под гостя, теперь будет их два

LV                VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
...        
  rprx-boot         vgdata rwi-aor--- 512.00m                                    100.00          
  rprx-data         vgdata rwi-aor---   4.00g                                    100.00          
...        

…и да, у меня LVM внутри LVM. Это нормально
P.S> на гипервизоре LVM-mirror
P.P.S> Да, я заморочился с LVM-mirror, но это уже отдельный холивар

А для чего тебе на 5 гигов в виртуалке вообще нужен лвм?

А для чего тебе на 5 гигов в виртуалке вообще нужен лвм?

А зачем его на большее делать? Повторюсь - это реверспрокси, много места не требуется, но с учётом того, что вдруг оно закончится:

1. Можно будет увеличить.
2. LVM как никак поколение next разметки. Думаю надо придерживаться его

поколение next

не поколение некст, а решение для длительного аптайма. забыл нужное слово.

не поколение некст, а решение для длительного аптайма. забыл нужное слово.

Для решения длительного аптайма можно было завезти в обычную разметку доработки, а не придумывать что-то новое

При чём тут аптайм?

LVM как никак поколение next разметки

Ты немного опоздал на вечеринку. RHEL 11 или 12 уже может перейти по умолчанию на Btrfs, и LVM потихоньку начнёт уходить в прошлое.