Комментарии 33
Пеши исчо, кармы насыпал.
Спасибо за поддержку. Рад, что вызвало интерес. С огромным удовольствием напишу еще (наработки есть :) ).
Так и не понял в чем проблема выключить VMWare перед выключением сервера?
А также не понял, как ваш скрипт этому поможет? Если вы делаете shut down серверу, то скрипт же не сработает и машины все равно не выключатся корректно.
А если вы помните, что надо запустить скрипт, то почему не помните, что надо выключить VMWare?
А также не понял, как ваш скрипт этому поможет? Если вы делаете shut down серверу, то скрипт же не сработает и машины все равно не выключатся корректно.
А если вы помните, что надо запустить скрипт, то почему не помните, что надо выключить VMWare?
Так и не понял в чем проблема выключить VMWare перед выключением сервера?
===
1.Наша рассеяность. Случайно выключили физ.машину, а виртуальную не выкл. Итог сбой.
2.Недобросовестный коллега, на которого оставили машину, забыл выключить. Ночью отключили электричество. Потеря данных. (Коллеги бывают разные ;) )
и.т.д случаи бывают разные.
===
А также не понял, как ваш скрипт этому поможет?
1 и 2. Выставит по запуску машину на паузу, а не будет выключаться с помощью ОС host машины. (личное мнение: это удобно и более безопасно)
Если вы делаете shut down серверу, то скрипт же не сработает и машины все равно не выключатся корректно
===
Мое понимание проблемы:
Вариант 1 — плохой.
1. выключается ваша host ос, подает сигнал guest ос ( если вы так настроили :), иначе все пропало )
Вот на этом этапе может некорректно завершить VMware сессию guset ос.
(личные наблюдения).
Вариант 2 — мое предложение
1. Вы выключаете не стандартным образом, а запускаете батник — он все делает за вас.
А если вы помните, что надо запустить скрипт, то почему не помните, что надо выключить VMWare?
1. У меня до трех машин работает, и когда я ухожу, некторые ими еще пользуются и забывают выключить. А у нас корп. стандарт — на ночь компьютер надо выключить.
2. Иногда на физ.компе запускаются машины, о которых я даже могу и не знать :).
Итого: скрипт поможет исключить (не на 100%) человеческий фактор и не потерять данные.
Проблематика: Человеческий фактор — некоторые просчеты VMware Server
===
1.Наша рассеяность. Случайно выключили физ.машину, а виртуальную не выкл. Итог сбой.
2.Недобросовестный коллега, на которого оставили машину, забыл выключить. Ночью отключили электричество. Потеря данных. (Коллеги бывают разные ;) )
и.т.д случаи бывают разные.
===
А также не понял, как ваш скрипт этому поможет?
1 и 2. Выставит по запуску машину на паузу, а не будет выключаться с помощью ОС host машины. (личное мнение: это удобно и более безопасно)
Если вы делаете shut down серверу, то скрипт же не сработает и машины все равно не выключатся корректно
===
Мое понимание проблемы:
Вариант 1 — плохой.
1. выключается ваша host ос, подает сигнал guest ос ( если вы так настроили :), иначе все пропало )
Вот на этом этапе может некорректно завершить VMware сессию guset ос.
(личные наблюдения).
Вариант 2 — мое предложение
1. Вы выключаете не стандартным образом, а запускаете батник — он все делает за вас.
А если вы помните, что надо запустить скрипт, то почему не помните, что надо выключить VMWare?
1. У меня до трех машин работает, и когда я ухожу, некторые ими еще пользуются и забывают выключить. А у нас корп. стандарт — на ночь компьютер надо выключить.
2. Иногда на физ.компе запускаются машины, о которых я даже могу и не знать :).
Итого: скрипт поможет исключить (не на 100%) человеческий фактор и не потерять данные.
Проблематика: Человеческий фактор — некоторые просчеты VMware Server
Да еще вариант:
1. Срабатывает UPS, запускается скрипт и все ставит на паузу. (помогает пауза, в том случаем, если происходит сложный стресс тест. Восстановили — пошло дальше)
1. Срабатывает UPS, запускается скрипт и все ставит на паузу. (помогает пауза, в том случаем, если происходит сложный стресс тест. Восстановили — пошло дальше)
еще добавлю:
Если при срабатывании UPS, будет выключаться host ос, при этом вызывая shutdown guest ос — это будет гораздо дольше, чем пауза guest ос — выключение host ос.
Тут важно время — батарейка не резиновая :)
Если при срабатывании UPS, будет выключаться host ос, при этом вызывая shutdown guest ос — это будет гораздо дольше, чем пауза guest ос — выключение host ос.
Тут важно время — батарейка не резиновая :)
А кстати, как в VMWare server пауза реализована? Пауза на диск всю информацию сохраняет? После перезагрузки все полностью восстанавливается? Но тогда это должно быть что-то типа Snapshot
Сохраняется образ памяти, потом восстанавливается.
После снятия паузы все восстанавливается.
Ну это не совсем Snapshot ( как архитектурно это реализовано — не копал).
Да, кстати, в данной версии можно сделать только 1 snapshot.
После снятия паузы все восстанавливается.
Ну это не совсем Snapshot ( как архитектурно это реализовано — не копал).
Да, кстати, в данной версии можно сделать только 1 snapshot.
Странно — у нас тестовые компы, автобилды и т.п. на VMWare серверах именно ночью большую часть работы делают. На ночь сервера выключать — это зло, надо бы в этом начальство убедить. Электричество что ли экономят?
Насчет батника: если есть батник, который вы хотите запускать, то можно просто в этом батнике было посылать команду для VMWare на выключение. А также прописать shutdown через несколько минут — тогда и скрипт будет из 2-х строк всего и задача будет выполнена.
Насчет батника: если есть батник, который вы хотите запускать, то можно просто в этом батнике было посылать команду для VMWare на выключение. А также прописать shutdown через несколько минут — тогда и скрипт будет из 2-х строк всего и задача будет выполнена.
Все сервера, что стоят в серверной они работаю и ночью.
Но некоторые не помещаются или просто используются мощные пользовательские ПК — в качестве серверов для виртуалок (ну конечно и как для работы)
===
батник:
Насчет батника: если есть батник, который вы хотите запускать, то можно просто в этом батнике было посылать команду для VMWare на выключение.
===
Не осилил этого :). Про какую команду идет речь?
В любом случае, для режима shutdown guest os, нужен установлен vmware tools. А он не всегда ставиться, коллегами. Представьте вы работает с машинами, их много, вы не уследите где, кто, что поставил.
Но некоторые не помещаются или просто используются мощные пользовательские ПК — в качестве серверов для виртуалок (ну конечно и как для работы)
===
батник:
Насчет батника: если есть батник, который вы хотите запускать, то можно просто в этом батнике было посылать команду для VMWare на выключение.
===
Не осилил этого :). Про какую команду идет речь?
В любом случае, для режима shutdown guest os, нужен установлен vmware tools. А он не всегда ставиться, коллегами. Представьте вы работает с машинами, их много, вы не уследите где, кто, что поставил.
>> Не осилил этого :). Про какую команду идет речь?
Код же на vbs написан — можно послать команду типа exit из меню file. Я скрипты для VMWare не изучал — точно не знаю.
>>В любом случае, для режима shutdown guest os, нужен установлен vmware tools
Вы удаленно что-ли компьютеры выключаете?
Код же на vbs написан — можно послать команду типа exit из меню file. Я скрипты для VMWare не изучал — точно не знаю.
>>В любом случае, для режима shutdown guest os, нужен установлен vmware tools
Вы удаленно что-ли компьютеры выключаете?
Просто так послать команду не получится, ее полюбому надо вызывать через сторонние библиотеки. Так что без кода не обойтись. А в примере много кода, так как я просто переделал стандартный поставочный скрипт — минимум усилий — максимум удовольствия.
Замечу:
В поставку входит еще такой стандартный скрипт, который можно вызвать ту же самую паузу одной командой. Но надо знать полный путь к машине.
Вот пример ключей:
C:\Program Files\VMware\VMware VIX>vmrun
Usage: vmrun [Authentication flags] COMMAND [PARAMETERS]
Authentication flags
-h -P -u -p COMMAND PARAMETERS DESCRIPTION
list List all running VMs
start Path to vmx file Start a VM
stop Path to vmx file Stop a VM
reset Path to vmx file Reset a VM
suspend Path to vmx file Suspend a VM
upgradevm Path to vmx file Upgrade VM file format, virtual hw
installtools Path to vmx file Install Tools in Guest OS
snapshot Path to vmx file Create a snapshot of a VM
deleteSnapshot Path to vmx file Remove a snapshot from a VM
revertToSnapshot Path to vmx file Set VM state to a snapshot
Но тут то и оно, ты не знаешь, что у тебя за виртуалка стоит, ты не знаешь в какой точно папке.
Вот поэтому, мой способ просматривать все зарегистрированные машины и ставить их на паузу, более оптимален.
Пауза — это менее требовательная операция.
Выключение гостевой системы — требует многих нюансов и не всегда стабильна, поэтому более требовательна.
>>В любом случае, для режима shutdown guest os, нужен установлен vmware tools
>>Вы удаленно что-ли компьютеры выключаете?
Не удаленно, а в заданное время, по scheduler. Когда уже офис закроют точно. Многие сидят до 21.00.
Замечу:
В поставку входит еще такой стандартный скрипт, который можно вызвать ту же самую паузу одной командой. Но надо знать полный путь к машине.
Вот пример ключей:
C:\Program Files\VMware\VMware VIX>vmrun
Usage: vmrun [Authentication flags] COMMAND [PARAMETERS]
Authentication flags
-h -P -u -p COMMAND PARAMETERS DESCRIPTION
list List all running VMs
start Path to vmx file Start a VM
stop Path to vmx file Stop a VM
reset Path to vmx file Reset a VM
suspend Path to vmx file Suspend a VM
upgradevm Path to vmx file Upgrade VM file format, virtual hw
installtools Path to vmx file Install Tools in Guest OS
snapshot Path to vmx file Create a snapshot of a VM
deleteSnapshot Path to vmx file Remove a snapshot from a VM
revertToSnapshot Path to vmx file Set VM state to a snapshot
Но тут то и оно, ты не знаешь, что у тебя за виртуалка стоит, ты не знаешь в какой точно папке.
Вот поэтому, мой способ просматривать все зарегистрированные машины и ставить их на паузу, более оптимален.
Пауза — это менее требовательная операция.
Выключение гостевой системы — требует многих нюансов и не всегда стабильна, поэтому более требовательна.
>>В любом случае, для режима shutdown guest os, нужен установлен vmware tools
>>Вы удаленно что-ли компьютеры выключаете?
Не удаленно, а в заданное время, по scheduler. Когда уже офис закроют точно. Многие сидят до 21.00.
Tools не всегда можно поставить. Мне например не нужны X-ы, а в FreeBSD tools их тянут.
Но выход есть, просто по handbook-у настроить ntp демон, так проще.
Знаю о них и поглядываю периодически. У меня были какие-то проблемы почему-то где-то год назад, кажется не компилировались на FreeBSD 6.2 или конфликтовали с собранным ядром. Сейчас виртуалками меньше занимаюсь потому не нужно.
www.cbronline.com/article_news.asp? guid=B7B8BFD5-543F-4870-BE02-A07D0A41EBFD
Уже как раз год прошол. Скачал почти сразу после релиза и разочаровался поначалу, потому как отличий от стандартных vmware tools не было.
Уже как раз год прошол. Скачал почти сразу после релиза и разочаровался поначалу, потому как отличий от стандартных vmware tools не было.
Мое личное использование:
1. Сосед запускает на мне виртуальную машину.
2. Я не знаю как она сконфигурирована.
3. Мне надо выключить ПК.
4. Использую паузу, так как она менее требовательна к настройкам виртуал. машины соседа.
Рассматривался такой вариант.
Хотел спросить про время: при такой настройке, синхронизация происходит во время старта машины или через интервал времени?! Такую опцию никогда не использовал.
1. Сосед запускает на мне виртуальную машину.
2. Я не знаю как она сконфигурирована.
3. Мне надо выключить ПК.
4. Использую паузу, так как она менее требовательна к настройкам виртуал. машины соседа.
Рассматривался такой вариант.
Хотел спросить про время: при такой настройке, синхронизация происходит во время старта машины или через интервал времени?! Такую опцию никогда не использовал.
> Если autostop настроен на остановку, она оснановится без лишних телодвижений.
Согласен, если только настроен :)
> Синхронизация происходит периодически. После запуска после паузы время корректируется на актуальное.
В данной ситуации можно выделить проблематику: если выполняющаяся работа зависит от времени guset ос, то подход не актуален.
Например: выполняется тест, в результате записываются данные о времени запросов к базе (оптимизируем 2-х часовой запрос). Вечером вирт.машина останавливается, утром включается, синхронизируется время — итого в отчет попадет неверный расчет.
Согласен, если только настроен :)
> Синхронизация происходит периодически. После запуска после паузы время корректируется на актуальное.
В данной ситуации можно выделить проблематику: если выполняющаяся работа зависит от времени guset ос, то подход не актуален.
Например: выполняется тест, в результате записываются данные о времени запросов к базе (оптимизируем 2-х часовой запрос). Вечером вирт.машина останавливается, утром включается, синхронизируется время — итого в отчет попадет неверный расчет.
Хорошая статья, спасибо.
P.S. Хорошо бы из заголовка точку убрать, глаз режет…
P.S. Хорошо бы из заголовка точку убрать, глаз режет…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
VMware Server :: управляемся с парком машин