21.11.2014 14:53, Volodymyr Kostyrko пишет:
On 21.11.2014 13:07, Владимир Друзенко wrote:
21.11.2014 01:59, Volodymyr Kostyrko пишет:
On 20.11.2014 18:20, Владимир Друзенко wrote:
20.11.2014 19:09, Владимир Друзенко пишет:
И да, "-o volmode=dev -o volsize=?" - это же не файловая система, а
блочное устройство. Как потом быстро и просто её перенести на другой
сервер или даже на ноут на другой программной платформе (другая ОС)?
dd
К тому же VirtualBox умеет использовать блочные устройства только по
iSCSI. Есть конечно bhyve, но он пока не умеет BIOS и VGA.
VBoxManage internalcommands createrawvmdk - и жуёт на ура.
Очень много лишних телодвижений... Вот как скачать виртуалку на ноут в
локалке с произвольной операционкой?
zfs send | zfs receive
Как на это отреагирует *произвольная* операционка? :-o
Как потом на ней эту виртуалку запустить?
NFS, samba и scp/sftp в твоём случае не помогут без предварительного dd.
Ещё неплохо бы вспомнить "тонкие диски" - на сколько я понимаю после
такого dd диск будет "толстый". А значит надо будет качать лишние
гигабайты ноликов, которые будут занимать место на винте ноута - зачем
такое?
Они всё равно при передаче по сети жмутся
scp/sftp и то не всегда, NFS и samba ничего не жмут.
По крайней мере ни разу о таком нигде не слышал, хотя, например, с
самбой работаю ещё с версии 2.0.
а при хранении на диске - подразумеваются. Фактически получается
sparse файл.
Что? С какого перепугу скачанный по самбе файл на оффтопик на файловую
систему ext4 или ntfs (FAT!) вдруг станет sparse?
Мы вообще об одном и том же говорим?
В среднем у меня на виртуалку приходится 3 диска - вместо одной команды
zfs create надо делать 3.
А как в одну команду перенести все диски виртуалки на другой, более
медленный или более быстрый носитель на том же сервере, или просто
сделать копию (cp и mv уже не подойдут)?
Обычно не держу больше одного пула на сервере. Всегда лучше построить
zraid чем мерять на каких дисках быстрее,
15krpm и 7200rpm (все современные) какбэ намекают на разницу в скорости
даже без дополнительного измерения (хотя я его и проводил).
Да и размеры дисков разные - 300Gb и 500/1000Gb (на разных серверах)
соответственно.
Я вижу, что твой вариант костылей существенно более костыльный, чем мой,
и всё это только ради ZFS в виртуалке. А оно надо? :-P
Не совсем, я виртуалки никуда не раздаю, они мне в основном нужны для
тестирования. Ну там поднять OpenFire поверх постгресса
среплицированного bucardo на нескольки линуксах. Поэтому я посылаю на
фиг многие вещи чтобы получить прирост производительности, пусть и
небольшой. У нас просто цели разные.
Вот собственно почему мне твой вариант и не подходит. ИТ компания,
виртуалки на 90% стенды разработки, тестирования, демонстрации и
продакшина для различных заказчиков с зоопарком операционок - FreeBSD,
Linux (CentOS, RHEL, Oracle Linux, Ubuntu, SUSE, прошивка тонкого
клиента IGEL - Ubuntu-based вроде, ...), венда (от XP до 2012), даже
Solaris как-то был. Регулярно необходимо или отдать виртуалку
заказчику/провести демонстрацию со своего ноута на территории заказчика,
или развернуть на своих мощностях виртуалку
заказчика/партнёра/субподрядчика/...
И только на 10% продакшин для внутренних нужд + песочница для отладки
внутренних сервисов.
Простота и удобство импорта/экспорта чуть ли ни главное требование.
Я создаю для каждой виртуалки отдельную фс, и диски виртуалки лежат
там
как файлы.
могу тогда ещё рекомендовать recordsize=8k
Зачем так мало? Использую дефолтные 128K на хосте.
Потому что в виртуалке файлы пишутся кусками в 4k а на хосте по
правилам Copy-On-Write перезаписывается весь сектор в 128k. Та же
проблема и с базами данных: https://wiki.freebsd.org/ZFSTuningGuide
http://open-zfs.org/wiki/Performance_tuning
О базах слышал. Надо подумать...
Это опция пула или файловой системы? Есть возможность изменить без
пересборки пула? (Сам пока не гуглил).
Ещё есть qemu и может он и умеет блочные устройства, но не думаю что
имеет смысл на него мигрировать.
мечтаю когда bhyve c qemu замутят.
А зачем qemu ожидать, когда есть bhyve - его ожидать куда интереснее (и
перспективнее). :-D
В qemu мне нравится возможность активно играться с девайсами и их
количество, помню сел в раскоряку, здесь флешки нету, есть флешка в
датацентре, но это 500км. Есть софт, который ляпает на флешку самотык
для обновления фирмвари, но только на флешку и никак иначе. Создал
виртуальный диск, подбросил в qemu как флешку - и на ура.
Как же он определяет что это флешка - софт под вендой что ли?
А так да - то, что VirtualBox не умеет образы подсовывать как USB
флешки, тоже порой не хватает.
Раньше в qemu был qemu-kmod который позволял выполнять уже
оттранслированый код на уровне ядра с куда большей
производительностью. Потом товарищ Морис его выкинул и начал
использовать линуксовый kvm, который по большому счёту то же самое что
и bhyve - системный минимальный набор для виртуализации. Насколько я
понимаю bhyve более самодостаточен, но от использования его как
бекенда для исполнения виртуалок с qemu в виде фронтенда для
трансляции и работы с виртуальными девайсами я бы не отказался. Незнаю
насколько это реально, скорее мечта...
Что такого нельзя сделать с помощью PetiteCloud + VNC (когда реализуют),
а можно с qemu?
