Использование LVM Snapshots для упрощения работы с виртуальными машинами

Как же достали статьи по очевидным вещам.

По статье: Нахрена последний раздел делать дважды? расширенные разделы делаю очень неохотно, как минимум, потому, что это усложняет структуру дисков. Ошибся циферкой и всё, ССЗБ.... Благо 4 раздела для некоторых задач хватает, к тому же, есть GPT или ещё можно сделать 2 MBR раздела: один корневой с /boot , а на LVM - е всё остальное (/var, /usr и т. д.) Это досовское наследие должно сдохнуть вместе с самим ДОСом!

Гм, прочитав заголовок новости, был на 100% уверен, что автор новости - IBM_dw

>Гм, прочитав заголовок новости, был на 100% уверен, что автор новости - IBM_dw

Кстати, аналогично! :)

>Гм, прочитав заголовок новости, был на 100% уверен, что автор новости - IBM_dw

Я даже расстроился, увидев что это не так

Мне интересно, как удается делать машины с конфигами в /etc, если еще с седьмой, по-моему, версии они хранятся в /var что-то там, а в /etc питоноподобные конфиги устарели и deprecated?

>Это досовское наследие должно сдохнуть вместе с самим ДОСом!

Чему надо сдохнуть, так это неправильным принципам по работе с "разделами" в Linux. Там же всё рассматривается без всяких абстракций, по-простому: если есть DOS-раздел, значит от этого не уйти. Дурашки картонные!

/ - 512МБ
SWAP - 512МБ
/tmp - 1024МБ
/var - 512МБ
/usr - 10ГБ
/home - всё остальное.
всё это помещается в один(!) основной раздел (слайс) в FreeBSD. Рядом (в MBR) есть место для установки ещё трёх систем.

Уместить это всё для одной(!) Linux-системы даже в четырёх DOS-разделах не представляется возможным. Вот и придумывают всякие костыли...

Верните IBM_dW, сволочи!

> всё это помещается в один(!) основной раздел (слайс) в FreeBSD. Рядом (в MBR) есть место для установки ещё трёх систем.

> Уместить это всё для одной(!) Linux-системы даже в четырёх DOS-разделах не представляется возможным. Вот и придумывают всякие костыли...

LVM - костыль, а слайс - не костыль? Логика железная, только ржавая какая-то.

> можно сделать 2 MBR раздела: один корневой с /boot , а на LVM - е всё остальное (/var, /usr и т. д.) Это досовское наследие должно сдохнуть вместе с самим ДОСом!

Да оно и дохнет успешно:

pvcreate /dev/sd?; vgcreate bla /dev/sd?

и всё, никаким досом даже и не пахнет.

LVM имхо, лучше слайсов.. жаль только пока нормально не грузится с оного.. или, как я уже выразился, есть GPT , который даже венда понимает.. А уж ядро Линукса - и подавно, (в большинстве дистров "из коробки")..

> Да оно и дохнет успешно: > pvcreate /dev/sd?; vgcreate bla /dev/sd?

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

> LVM имхо, лучше слайсов.. жаль только пока нормально не грузится с оного..

LILO нормально грузит. GRUB не грузит, да.

> LILO нормально грузит. GRUB не грузит, да.

Вот тут-то и загвоздка, так как "из коробки" LILO не поддерживает загрузку XEN-ядра, правда, есть какой-то патч для этого, но у меня под 64 битной системой были ошибки при компиляции...

> Вот тут-то и загвоздка, так как "из коробки" LILO не поддерживает загрузку XEN-ядра, правда, есть какой-то патч для этого, но у меня под 64 битной системой были ошибки при компиляции...

http://wpkg.org/Running_Xen_with_LILO

Скорость чтения со снапшота меньше, чем просто с логического тома. Так как надо проверять таблицу исключений (COW table) на предмет того, не изменились ли данные по сравнению с оригинальным томом. И таблица исключений сама по себе занимает место. И через несколько месяцев работы доменов XEN на таких снэпшотах в результате записи\перезаписи их размеры увеличатся заметно. Короче, идею в топку.

Спасибо, конечно, но это та самая ссылка, которую мне предложил гугл..

там идём по ссылке на mbootpack и "радостно втыкаем" на:

"It's been brought to my attention that mbootpack doesn't compile properly on 64-bit linux sysytems; it needs a 32-bit tool chain. "

насколько я понял, оно компилится только под 32 бита, а значит, не сможеи загружать 64 битные ядра? Или я ошибаюсь? (использлвать 32 бита не предлагать, пожалуйста... )

> насколько я понял, оно компилится только под 32 бита, а значит, не сможеи загружать 64 битные ядра? Или я ошибаюсь? (использлвать 32 бита не предлагать, пожалуйста... )

64-битное ядро содержит две точки входа: одну "32-битную". Загрузчик может вообще особо не задумываться, что там внутри, ядро само доведёт себя до ума, если надо будет. Вроде бы даже загрузка сразу в 64-битный режим - это не по стандарту multiboot, а фича linux.

Попробуй запустить 64-битное ядро на 32-битной машине. Оно же загрузится и радостно скажет, что на таком старье дальше не попрёт ;)

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

P.S.: Всё вышесказанное может оказаться полным бредом, но на момент написания кажется автору вполне разумным :)

>Гм, прочитав заголовок новости, был на 100% уверен, что автор новости - IBM_dw

Я тоже.

>pvcreate /dev/sd?; vgcreate bla /dev/sd?

А grub при этом как грузить ?

>и всё, никаким досом даже и не пахнет.

Да дался вам этот дос!

1-й - раздел /boot, 2-й - LVM и еще два раздел под другие OS, если они используются. Чего вам не нравится?

> А grub при этом как грузить ?

Да дался вам этот grub!..

Если надо ставить на тот же винт что-то ещё, что в LVM не всунется, то всё равно придётся делать досовские разделы. Тогда уж, конечно, можно и /boot вытащить на отдельный раздел. Я же писал про случай, когда на компе только linux(ы) или всё остальное на отдельном винте (или в виртуалках, которые внутри LVM).