Главная » Форум » Gentoo Linux » Виртуальные машины

образы машин в KVM

kostik_g 14 мая, 2012 - 13:26

Подскажите на какой файловой системе лучше хранить образы виртуальных машин.
Почему во всех руководствах советуют ЛВМ? Действительно с ним будет быстрее, или это только для удобства?

‹ не собирается virtualbox-modules-4.1.12 Даунгрейд ядра с 3.2 на 2.6.32 в текущей версии GENTOO ›
»

ЛВМ — это не файловая

Автор eegorov, дата создания 14 мая, 2012 - 13:33.

ЛВМ — это не файловая система.

»

да, согласен, вопрос

Автор kostik_g, дата создания 14 мая, 2012 - 13:55.

да, согласен, вопрос получился не очень
но суть осталась таже: необходимо ли создавать логические диски для хранения образов виртуальных машин, либо же можно просто их хранить на физических? Будет ли от этого прирост производительности? Да и, собственно, есть ли смысл в формате отличном от raw, например qcow2?

»

lvm - лишняя прослойка между

Автор _SerEga_, дата создания 14 мая, 2012 - 17:37.

lvm - лишняя прослойка между жестким диском и софтиной, т.е. она по определению замедляет. Но скорее всего почувствовать это не получиться. Профит от lvm начинается когда надо изменить размеры и/или количество дисков или забекапить, диск не прерывая работу надолго.

»

+

Автор Daevy, дата создания 20 июня, 2012 - 07:57.

в случае использования файла в качетсве блочного устройства для VM, появляется еще одна прослойка. для сравнения:
используем LVM: VM ФС -> гипервизор -> LVM-том -> физическое блочное устройство
используем файл: VM ФС -> гипервизор -> файл-образ -> ФС хост-системы -> физическое блочное устройство

вобще тонкостей масса, еще зависит использует/неиспользует ли VM страничный и дисковый кэши ОС.
http://virtbox.blogspot.com/2012/06/qemu-kvm.html

—

there is only war...

»

raw - размер диска скажем 100

Автор ananazzz, дата создания 14 мая, 2012 - 21:23.

raw - размер диска скажем 100 гб, файл образа и будет весить в любом случае 100 гб
qcow2 - рамер диска 100 гб, файл образа будет весить чуть более, чем будет занято (например только что поставленный дебиан 6, скажем, размер образа составит 1-2 Гб)
остальное гуглим, ибо двумя словами не передать :)

»

Да я гуглил, на фирме просто

Автор kostik_g, дата создания 15 мая, 2012 - 12:40.

Да я гуглил, на фирме просто существует устоявшийся план разворачивания сервера: на родительской ext4 + раздел под lvm (тоже ext4) на котором хранятся образы в raw.
Пытаюсь отстоять свою точку зрения, что нужно использовать qcow2 и отказаться от lvm. Хотелось бы услышать как делают другие.

»

, что нужно использовать

Автор slepnoga, дата создания 15 мая, 2012 - 15:47.
, что нужно использовать qcow2 и отказаться от lvm.

можно проще - юзать лвм sd block device ;) - плюсов - масса; основной - оверселлинг :)

—

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

»

ну оверселлинг мне не нужен,

Автор kostik_g, дата создания 16 мая, 2012 - 11:24.

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

А можно подробнее, про "ЛВМ блок девайс"? Немного расширеннее, а то так не гуглится.

Я бы вообще отказался от Лвм, т.к., насколько мне известно, восстановить с него данные в случае сбоя невозможно, и единственный профит от его использования - удобное изменение разделов. Но, каждые полгода-год проекты мигрируют между серверами - и этот профит по сути не нужен. Внутри же виртуалки, ЛВМ удобен, т.к. позволяет наращивать место по мере надобности.

Но, директор, утверждает что, в Вирт-Манагере образы должны лежать в Хранилище на ЛВМ, т.к. это обеспечивает большее быстродействие, по сравнению с Хранилищем на обычных разделах. Но, как-то не верится.

»

ну оверселлинг мне не нужен,

Автор slepnoga, дата создания 16 мая, 2012 - 13:36.
ну оверселлинг мне не нужен, т.к. проекты крутятся исключительно наши и продавать место мы не планируем.

я тоже не продаю - но возможность заявить размеры разделов больше, чем есть - сильно хорошо :0

А можно подробнее, про "ЛВМ блок девайс"? Немного расширеннее, а то так не гуглится.

диском для машинки является к примеру /dev/data_storage/vm-001 ( внутри него нагоняются партишки или что там надо)
доступ через partx с HW без проблем :), можно ссобразить вложенный lvm, как это сделано у меня

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

херня

Но, каждые полгода-год проекты мигрируют между серверами - и этот профит по сути не нужен.

освой сетевые возможности lvm - cman, clvm , drdb :)

Но, директор, утверждает что, в Вирт-Манагере образы должны лежать в Хранилище на ЛВМ, т.к. это обеспечивает большее быстродействие, по сравнению с Хранилищем на обычных разделах.

что должны - херня; что более быстродействие по сравнению с raw форматом - прав на 100% , читай про barrier для BLK

Но, как-то не верится.

Верить можно в бога, в лвм верить не надо - надо проверять.

—

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

»

slepnoga написал(а): ну

Автор kostik_g, дата создания 16 мая, 2012 - 17:54.
slepnoga написал(а):
ну оверселлинг мне не нужен, т.к. проекты крутятся исключительно наши и продавать место мы не планируем.

я тоже не продаю - но возможность заявить размеры разделов больше, чем есть - сильно хорошо :0

А чем это собственно, хорошо, зачем мне "виртуальные" 2 Тб вместо "живого" 1-го?

Цитата:
А можно подробнее, про "ЛВМ блок девайс"? Немного расширеннее, а то так не гуглится.

диском для машинки является к примеру /dev/data_storage/vm-001 ( внутри него нагоняются партишки или что там надо)
доступ через partx с HW без проблем :), можно ссобразить вложенный lvm, как это сделано у меня

Мне не совсем понятны упомянутые термины, но как я понял, на родительском разделе мы не создаем ФС, а просто подключаем LV внутрь ВиртМашины, а там уже создаем наши диски и ФС (с ЛВМ или без него - это уже не важно)

Цитата:
Я бы вообще отказался от Лвм, т.к., насколько мне известно, восстановить с него данные в случае сбоя невозможно, и единственный профит от его использования - удобное изменение разделов.

херня

Да, уже нагуглил что есть утилиты

Цитата:
Но, каждые полгода-год проекты мигрируют между серверами - и этот профит по сути не нужен.

освой сетевые возможности lvm - cman, clvm , drdb :)

Пока что мигрируем при помощи рсинка файлов и дампа базы

Цитата:
Но, директор, утверждает что, в Вирт-Манагере образы должны лежать в Хранилище на ЛВМ, т.к. это обеспечивает большее быстродействие, по сравнению с Хранилищем на обычных разделах.

что должны - херня; что более быстродействие по сравнению с raw форматом - прав на 100% , читай про barrier для BLK

Вот отсюда, можно еще подробнее ?

Цитата:
Но, как-то не верится.

Верить можно в бога, в лвм верить не надо - надо проверять.

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

»

+

Автор Daevy, дата создания 20 июня, 2012 - 08:05.

выглядит это так:
1. на хост-системе нарезаются тома нужных размеров

# lvs |grep kvm
  kvm720-bz-script2-code   kadu -wi-ao  25.00g                                      
  kvm720-bz-script2-root   kadu -wi-ao  20.00g                                      
  kvm720-bz-script2-static kadu -wi-ao  10.00g                                      
  kvm722-bz-banner-db      kadu -wi-ao  10.00g                                      
  kvm722-bz-banner-root    kadu -wi-ao  10.00g                                      
  kvm723-bz-rubik-code     kadu -wi-ao  25.00g                                      
  kvm723-bz-rubik-root     kadu -wi-ao  20.00g                                      
  kvm723-bz-rubik-static   kadu -wi-ao  10.00g                                      
  kvm725-bz-db-pg          kadu -wi-ao 145.00g                                      
  kvm725-bz-db-root        kadu -wi-ao  20.00g

а виртуальные машины запускаются с использованием этих блочных устройств.

/usr/bin/qemu-system-x86_64 ... \
-drive if=virtio,file=/dev/kadu/kvm720-bz-script2-root,index=0,media=disk \
-drive if=virtio,file=/dev/kadu/kvm720-bz-script2-code,index=1,media=disk \
-drive if=virtio,file=/dev/kadu/kvm720-bz-script2-static,index=2,media=disk \
...

внутри виртуальных машин уже разворачивается своя дисковая подсистема
ну и профит лично для меня в том что
- можно менять размер дисков на лету без остановки сервисов и даунтайма
- нет уровня файловой системы на уровне хост-системы

—

there is only war...

»

qemu-img info

Автор Aladdin, дата создания 15 мая, 2012 - 12:56.

qemu-img info образ.[img|qcow2|qed|прочие]

sudo qemu-img info /common/libvirt/images/windows-xp.img
image: /common/libvirt/images/windows-xp.img
file format: raw
virtual size: 12G (12884901888 bytes)
disk size: 4.5G

Как видно из примера, размер образа при создании задан 12G, реально занимает 4.5G.
От ФС зависит, сколько занимать будет... Поддержка т.н. "дыр". На ntfs/fat - не спорю - займет сколько занимает. ;)
в моем случае - reiserfs.

—

P.S.: Linux - это красная таблетка :-) Windows - синяя...

»

>>Подскажите на какой

Автор wi, дата создания 17 мая, 2012 - 09:48.

>>Подскажите на какой файловой системе лучше хранить образы виртуальных машин
Скажем так. Это техническое решение, и посему оно не может быть идеальным для всех случаев жизни. Ежели речь идет об лвм - очевидный плюс в выбрасывании прослойки файловой системы. Гостевой системе в монопольном режиме предоставляется по сути раздел диска. Очевидный плюс - ГАРАНТИРОВАННЫЙ размер каждой файловой системы каждого гостя. Это исключит остановку виртуализатора в случае внезапного роста образов qcow. Из минусов - очевидные потери дискового пространства.

qcow позволяет реально сэкономить на размерах образов. Некие потери в скорости по сравнению с raw не подлежат сомнению, возникает лишь вопрос об их существенности.

>>Почему во всех руководствах советуют ЛВМ? Действительно с ним будет быстрее, или это только для удобства?
Руководства пишут люди. Часто с плагиатом. Вероятно руководство с применением лвм стало образцом для прочих.

ЗЫ
Линь - достаточно гибкая штука. Вам лишь следует определиться с собственными потребностями. Ну а по поводу быстродействия... Не думаю что различные способы хранения образов смогут дать вам профит в производительности более 5%, что при учете погрешностей в вычислениях сродни среднестатистической ошибке.

»

wi написал(а): >>Почему во

Автор Daevy, дата создания 20 июня, 2012 - 21:40.
wi написал(а):
>>Почему во всех руководствах советуют ЛВМ? Действительно с ним будет быстрее, или это только для удобства?
Руководства пишут люди. Часто с плагиатом. Вероятно руководство с применением лвм стало образцом для прочих.

проводил тестирование, виртуальная машина с блочным устройством в виде файла, и в виде LVM-тома.
так вот, в случае использования LVM тома, на последовательном чтении/записи прирост производительности 6-7%, на случайном чтении/записи - 3-4%. Это с учетом что гости размещались на локально диске (для сетевого NFS или iSCSI хранилища, картина будет отличаться).

—

there is only war...

»

Это вполне понятно ибо в

Автор wi, дата создания 21 июня, 2012 - 16:16.

Это вполне понятно ибо в случае лвм нет файловой прослойки. По мере роста файлового кэша (своп должен быть весьма большим) разница сваливается к 2-4 %. Чисто теоретически еще пару процентов можно выжать используя рав раздел на харде, или вообще отдельный хард в качестве девайса вм. С управляемостью в этом случае не фонтан.Мой виртуализатор особой разницы между файлом qcow2 и разделом не показывает, там приличный рейд.

Однако речь не о том. Если вам реально необходимы эти 7% - пора менять железо.

»

+

Автор Daevy, дата создания 21 июня, 2012 - 21:53.

про 7%
помните когда только только появился KVM, его производительность составляла около 60%. то есть потери производительности поначалу были достаточно большие. да и сейчас кто-нибудь присутствующий в топике замеряет и сравнивает производительность голого железа и запущенных на нем виртуалок? врядли)))
к чему я клоню,.. KVM можно оптимизировать очень много и в разные стороны, это и подход к организации блочных устройств, и виртио, планировщик IO, управление кэшем, x2apic, hugepages и т.д... Производительность как раз и складывается вот из таких вот кусочков по 7%. Так что вот, можно раскидываться такими кусочками и покупать железо, а можно собрать их и получить неплохой профит (а сэкономленные деньги на квартальную премию;).

—

there is only war...

»

Спасибо за ответы

Автор kostik_g, дата создания 17 мая, 2012 - 11:08.

Вот я и разобрался с вопросом.
Как оказалось, я делал неверно, а вот так: (lvm + ext4) на родительской - raw - (lvm + ext4) на гостевой. А нужно просто не форматировать выделенный раздел родительской машины.

Образы в продакшне буду использовать raw, т.к. места более чем достаточно, а вот на тестовой и дома - qcow2.

Ну и буду надеяться, что когда-нибудь решат вопрос с ZFS.

Если не будет дополнений, тему закрою чуть позже.

»

Я ранее использовал образы

Автор micbal, дата создания 21 мая, 2012 - 14:46.

Я ранее использовал образы фиксированного размера, на xfs и ext4. Теперь на lvm, визуально быстрее стало диском работать.

»

Поправьте, если я не прав

Автор kostik_g, дата создания 22 июня, 2012 - 02:00.

Поставил дома КВМ и использую сл. схему:
пв - вг ---- передается в вирт-манагер через хранилище или просто подсоединяя лв
лу ---- образ моей виртуалки
пв - вг - лв - фс ---- внутри виртуальной машины

Наблюдаем вложенность, присущую ЛВМ

»

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".