= Сообщение: 5366 из 10756 ===================================== RU.UNIX.BSD =
От : Victor Sudakov 2:5005/49 17 Mar 17 19:28:26
Кому : Alex Korchmar 17 Mar 17 19:28:26
Тема : ошметки от 9.3
FGHI : area://RU.UNIX.BSD?msgid=2:5005/49+58cbe230
На : area://RU.UNIX.BSD?msgid=<1187506989@ddt.demos.su>+2c0bda4b
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.UNIX.BSD?msgid=<1187507005@ddt.demos.su>+fe297b72
==============================================================================
Dear Alex,
13 Mar 17 10:01, you wrote to me:
VS>>>> У меня опыт использования только VMWare ESXi и bhyve. Так вот
VS>>>> второй лично мне удобнее по ряду пунктов:
AK>>> это если в нем ничего кроме freebsd не держать.
VS>> Я тебе для этого его и предлагал (чтобы держать старые freebsd).
AK> это трата ценного ресурса на фигню. Завтра понадобится таки громоздить
AK> dns на 2008 - будем все переставлять?
С этим согласен, Windows на bhyve держать неудобно. Особенно неудобно ставить.
AK>>> Хотя правильно ее готовить через интерфейс к powershell.
VS>> Верю. Hо пока не прижмёт, не хочу учиться, каким хаком в VMware
VS>> можно создать из командной строки виртуальный бридж
AK> esxcli в руки. И да, на него есть документация.
Верю. Но посмотреть по ssh, что творится на serial console guest системы, я думаю, esxcli тебе не даст, в отличие от. В VMware вообще есть понятие serial консоли для ОС, которые ее поддерживают (и да, Windows тоже к ним относится)?
AK>>> Кстати, как насчет в обратную сторону - флэшка тут, платформа с
AK>>> виртуалками- где-то там?
VS>> Скорее всего никак. Hо ничто не мешает образ флешки залить на
VS>> гипервизор.
AK> во траходром-то.
AK> И это ради фоточки скинуть.
Тогда по ssh сразу на guest.
VS>> кстати и с VMware так поступаю иногда, несколько нужных ISO-шников
VS>> лежат прямо на гипервизорах.
AK> исошники с дистрибутивами, положим, имеет смысл там и хранить, ими,
AK> обычно, пользуешься не один раз (когда один - гораздо удобнее опять же
AK> никуда с этим диском не ходить, все равно установка жрет времени почти
AK> независимо от скорости их чтения) А сменный носитель подключать
AK> удобнее, обычно, в свою рабочую станцию.
AK> Я ж говорю - даже неинтересно выяснять, что эти опоздавшие еще не
AK> доделали или не поняли, зачем у всех остальных сделано. qemu двадцать
AK> лет, и она работает. Все остальные копипастеры ничего ценного к ней не
AK> добавили (вмварь добавила, но не к, а рядом и отдельно - все
AK> интересное там начинается, когда кластер состоит не из одного ржавого
AK> ящика на 100мегабитной сопле.)
Справедливости ради, qemu под FreeBSD тоже вполне себе есть.
VS>> Будь они хоть трижды "thin provisioned" на самом гипервизоре,
VS>> при *скачивании* через vSphere Client ты получишь полноразмерные
VS>> 100 гиг, не sparse
AK> thin provision устроен ни разу не в виде sparse. При скачивании
AK> получишь ровно то же, что было на дисках esxi. Если 100гиг - значит,
AK> там свободного места было ноль.
А вот хрен.
VS>> С вышеперечисленным я и не спорю, но для запуска кучки виртуальных
VS>> фришек это перебор.
AK> для этого берешь тот скрипт и сохраняешь, не глядя внутрь.
AK> Hу или cp.
AK> А когда надо скопировать пятый снапшот во второй ветке, лучше уже
AK> это делать в gui, чтоб не промахнуться.
Кому как.
VS>> десятке появился vmx(4), работает нормально, с GENERIC ядром. Hо
VS>> отправить
AK> рекомендую забыть как страшный сон. То есть в вмвари и именно текущих
AK> версий оно вроде и работает, но "золотой стандарт" - em. Патамушта к
AK> нему есть _и_ нормальные драйвера, _и_ нормальная эмуляция, которую
AK> тоже все копипастят неглядя. А на этих поделках ВHЕЗАПHО можно
AK> выхватить 100килобит между двумя виртуалками.
VS>> гостям команду на shutdown без установленных VMWare tools нельзя.
AK> afair, сфера _всегда_ пытается дернуть acpi, если только специально не
AK> заставлять ее выключиться через пункт меню стодесятого уровня
AK> вложенности.
При выключении самого гипервизора - ХЗ, может и пытается. Но без установленных VMWare tools пункт в меню "Guest shutdown" неактивен, можно сделать только "Power off".
AK>>> с неконсистентным состоянием виртуального диска? А смысл?
VS>> Как показывает практика, в 99,9% случаев ничего страшного в этом
VS>> нет.
AK> ну значит твой "бэкап" это cp в консоли, нафига снапшоты городить?
AK> они еще и производительность сажают.
Да, я как-то некорректно сказал. Вот cp в консоли не очень страшно и без снапшота, страшно разве что файлы СУБД. А при копировании vmdk ты ведь на знаешь, что там внутри происходит.
VS>> со снапшотами, не гарантирует тебе консистентности, я об этом
VS>> писал не раз с примерами. VMware-вский snapshot manager, думаю,
VS>> тоже не гарантирует.
AK> гарантирует. Потому что это снапшот живой системы, вместе с состоянием
AK> памяти и запущенными процессами. Разумеется, он атомарный. (правда,
AK> побочным эффектом при недофига мощности дисковой полки является фриз
AK> бэкапаемой системы, иногда надолго) Для (нормальной) системы с
AK> vm-tools его запуск в другом месте будет выглядеть как выход из
AK> незапланированного deep sleep (села батарейка в ноуте).
AK>>> С тем же
AK>>> успехом можешь скопировать .vmdk из под запущенной вмвари.
VS>> И кто тебе гарантирует, что тебе в .vmdk не напишут что-нибудь
VS>> прямо в тот
AK> те же кто тебе "гарантируют" консистентность содержимого снапшотов zfs
Быстрота, с которой они происходят. И я думаю, там есть фриз на время создания снпашота.
А вот при многоминутном копировании .vmdk есть большая вероятность, что в процессе кто-то туда напишет.
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322
* Origin: Ulthar (2:5005/49)
|
