Выбор ФС для образов ВМ

скажу, что мнение насчёт XFS совершенно правильное

Понятно, спасибо. Скажите, а внутри ВМ имеет значение тип файловой системы? Например, если ВМ тоже linux и есть раздел с несколькими сотнями тысяч файлов размером от 1Кб до 100Кб, то будет ли профит от reiserfs на виртуальном диске? Я понимаю, что лучше поднять KVM с данными на LVM хоста, но пока буду использовать vmware server 2, потому как не знаю как провести online миграцию.

а vmware могет - интересно - на физ раздел диска поставить ?

Диски виртуальных машин лучше держать сразу в виде блочных устройств. Например LVM. Любая ФС будет только создавать лишнюю нагрузку на процессор.

>Например, если ВМ тоже linux и есть раздел с несколькими сотнями тысяч файлов размером от 1Кб до 100Кб, то будет ли профит от reiserfs на виртуальном диске?

должен быть

vmware server 2, на сколько я понял из доков не может.

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

vmdk --> row image file --> block device (lvm) --> kvm + lvm

Чтобы не простаивать делаешь на vmware клон системы и мигрируешь с клона в оффлайне.

>должен быть

не очевидно, не известно как происходит трансляция запросов на чтение-запись из ВМ на хост. Коллеги, может есть у кого реальный опыт применения разных ФС на ВМ?

>XFS
Да.
Why?
Специально создавался с одной из фич - быстрая работа с большими файлами, коими являются образы ЖД ВМ.

По графикам-тестам это прекрасно видно. Однако вредная потеря последних данных или файлов (давно было, может пофиксили уже)заставляет посоветовать работать через UPS или включить надёжное журналирование.

Использование raw block device в vmware server 2

http://communities.vmware.com/thread/177112

>Использование raw block device в vmware server 2

Недокументированная возможность :), ибо:

This works in VMware Workstation and apparantly also in Server 1.x but somehow the ability to use physical disks was removed from the UI of Server 2.0.

Раз из UI убрали, стало быть что то не так, хотя попробовать можно.

Когда что-то убирают из бесплатного продукта — ага, что-то не так.

> vmdk --> row image file --> block device (lvm) --> kvm + lvm

А как сделать row image file --> block device (lvm)? Пардон, если вопрос идиотский :).

> Однако вредная потеря последних данных или файлов (давно было, может пофиксили уже)заставляет посоветовать работать через UPS или включить надёжное журналирование.

Это само собой разумеется, на железе и UPSах не экономим.

вмваре не умеет raw-девайсы? тут у ораклебоев даже виртуалбокс умеет же!

Делов в том, что любая фс:
1)лишняя прослойка между данными и фм
2)лишняя точка отказа

kvm-img convert

Supported image file formats:
       vmdk
           VMware 3 and 4 compatible image format.
           Supported options:
           "backing_fmt"
               Image format of the base image
           "compat6"
               Create a VMDK version 6 image (instead of version 4)

Какой версия vmdk используется в vmware server 2 я не знаю.

Однако вредная потеря последних данных или файлов (давно было, может пофиксили уже)заставляет посоветовать работать через UPS или включить надёжное журналирование.

Что такое «надёжное журналирование» приминительно к xfs?

Похоже XFS отменятся, в связи с багом в ядре велика вероятность порчи файла-образа ВМ.

> Похоже XFS отменятся, в связи с багом в ядре велика вероятность порчи файла-образа ВМ.

С каким багом?

Заменяем vmware server на vmware ESXi, форматим диски в vmfs, переносим машины vmware converter'ом.

> С каким багом?

Гуглим kernel bug XFS.

Тоже склоняюсь к этому варианту, проверю железо на совместимость.

и натыкаемся на баги с ядрами 2.6.2x, при том, что на kernel.org: longterm - 2.6.35.10 . Не говоря про то, что уже 2.6.38 на подходе.

гуглим «kernel bug подставить-фс-которую-предлагает-оппонент» и называем его лошком и ноем на весь форум, какие вокруг все красноглазые и тупые. Например kernel bug ext3 или kernel bug vmfs.

По делу: чо там насчет голых блокдевайсов под виртуалки?

>и натыкаемся на баги с ядрами 2.6.2x, при том, что на kernel.org: longterm - 2.6.35.10 . Не говоря про то, что уже 2.6.38 на подходе

Предлагаешь на серверах использовать 2.6.3x? Я пас, 2.6.2x самое то.

>гуглим «kernel bug подставить-фс-которую-предлагает-оппонент» и называем его лошком и ноем на весь форум, какие вокруг все красноглазые и тупые.

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

Учитывая, что даже RHEL6 работает на 2.6.32 c бэкпортами, то ничего зазорного в его использовании не вижу.

Смгрировать с одного хост-сервера на другой будет посложнее, чем с файлами.

в чём же будет сложность? даже в отсутствии SAN dd+nc будет работать, в отличие от проблем со сдохшей громадной ФС

Косвенным подтверждением наличия багов с XFS в свежих ядрах, является тот факт, что virtualbox, установленный на ubuntu 10.10 (ядро 2.6.35-25) отключает кэширование IO и предупреждает о возможном повреждении образа диска, если образ расположен XFS.