Victor Sudakov <Victor.Sudakov@f49.n5005.z2.fidonet.org> wrote:
VS>>> У меня опыт использования только VMWare ESXi и bhyve. Так вот VS>>> второй лично мне удобнее по ряду пунктов: AK>> это если в нем ничего кроме freebsd не держать. VS> Я тебе для этого его и предлагал (чтобы держать старые freebsd). это трата ценного ресурса на фигню. Завтра понадобится таки громоздить dns на 2008 - будем все переставлять?
AK>> Хотя правильно ее готовить через интерфейс к powershell. VS> Верю. Hо пока не прижмёт, не хочу учиться, каким хаком в VMware можно VS> создать из командной строки виртуальный бридж esxcli в руки. И да, на него есть документация. Hо вообще-то свитчи создаются один раз при проектировании, это вот куда более странная идея чем добавить виртуалку не той системы.
AK>> Кстати, как насчет в обратную сторону - флэшка тут, платформа с AK>> виртуалками- где-то там? VS> Скорее всего никак. Hо ничто не мешает образ флешки залить на гипервизор. во траходром-то. И это ради фоточки скинуть.
VS> кстати и с VMware так поступаю иногда, несколько нужных ISO-шников VS> лежат прямо на гипервизорах. исошники с дистрибутивами, положим, имеет смысл там и хранить, ими, обычно, пользуешься не один раз (когда один - гораздо удобнее опять же никуда с этим диском не ходить, все равно установка жрет времени почти независимо от скорости их чтения) А сменный носитель подключать удобнее, обычно, в свою рабочую станцию.
Я ж говорю - даже неинтересно выяснять, что эти опоздавшие еще не доделали или не поняли, зачем у всех остальных сделано. qemu двадцать лет, и она работает. Все остальные копипастеры ничего ценного к ней не добавили (вмварь добавила, но не к, а рядом и отдельно - все интересное там начинается, когда кластер состоит не из одного ржавого ящика на 100мегабитной сопле.)
VS> Будь они хоть трижды "thin provisioned" на самом гипервизоре, VS> при *скачивании* через vSphere Client ты получишь полноразмерные VS> 100 гиг, не sparse thin provision устроен ни разу не в виде sparse. При скачивании получишь ровно то же, что было на дисках esxi. Если 100гиг - значит, там свободного места было ноль.
VS> С вышеперечисленным я и не спорю, но для запуска кучки виртуальных VS> фришек это перебор. для этого берешь тот скрипт и сохраняешь, не глядя внутрь. Hу или cp. А когда надо скопировать пятый снапшот во второй ветке, лучше уже это делать в gui, чтоб не промахнуться.
VS> десятке появился vmx(4), работает нормально, с GENERIC ядром. Hо отправить рекомендую забыть как страшный сон. То есть в вмвари и именно текущих версий оно вроде и работает, но "золотой стандарт" - em. Патамушта к нему есть _и_ нормальные драйвера, _и_ нормальная эмуляция, которую тоже все копипастят неглядя. А на этих поделках ВHЕЗАПHО можно выхватить 100килобит между двумя виртуалками.
VS> гостям команду на shutdown без установленных VMWare tools нельзя. afair, сфера _всегда_ пытается дернуть acpi, если только специально не заставлять ее выключиться через пункт меню стодесятого уровня вложенности.
AK>> с неконсистентным состоянием виртуального диска? А смысл? VS> Как показывает практика, в 99,9% случаев ничего страшного в этом нет. ну значит твой "бэкап" это cp в консоли, нафига снапшоты городить? они еще и производительность сажают.
VS> со снапшотами, не гарантирует тебе консистентности, я об этом писал не раз с VS> примерами. VMware-вский snapshot manager, думаю, тоже не гарантирует. гарантирует. Потому что это снапшот живой системы, вместе с состоянием памяти и запущенными процессами. Разумеется, он атомарный. (правда, побочным эффектом при недофига мощности дисковой полки является фриз бэкапаемой системы, иногда надолго) Для (нормальной) системы с vm-tools его запуск в другом месте будет выглядеть как выход из незапланированного deep sleep (села батарейка в ноуте).
AK>> С тем же AK>> успехом можешь скопировать .vmdk из под запущенной вмвари. VS> И кто тебе гарантирует, что тебе в .vmdk не напишут что-нибудь прямо в тот те же кто тебе "гарантируют" консистентность содержимого снапшотов zfs
> Alex
--- ifmail v.2.15dev5.4 * Origin: Demos online service (2:5020/400)
