• ↓
  • ↑
  • ⇑
 
Записи с темой: virtualization (список заголовков)
12:02 

VMWare Multicore Virtual Machines

В Dash'e под Chronostasis'ом.

Возможность создания многоядерного процессора для виртуальной машины - это благо. Особенно, когда речь идет о ВМ под различные базы данных, где условия лицензирования, прямо скажем, драконовские, а производительности хочется побольше. Яркий пример - лицензия, привязанная к количеству процессоров на сервере. Стандартный метод повышения производительности - увеличение количества процессоров, влечет за собой расходы на дополнительную лицензию ПО. Что же делать?
Вот тут и приходят на помощь множественные ядра процессора. В ВМ процессор будет один, но более производительный за счет 2 и более ядер. Как же такого добиться?
В базе знаний VMWare есть статья, которая может служить отправной точкой для создания multicore cpu ВМ. Вот она:
Setting the number of cores per CPU in a virtual machine
Ок, следуем рекомендациям, изложенным в данной статье, выставив параметр number of virtual processors равным 1 (один процессор), и cpuid.coresPerSocket равным 2 (нужно два ядра), запускаем машину, и вот что получаем:

Получаем 1 одноядерный процессор. Результат совсем не тот, что ожидался.
Для сравнения, вот что получается, если выставить number of virtual processors равным 2, а cpuid.coresPerSocket - 1:

Видим, что у нас два одноядерных процессора. Такая комбинация настроек сработала так, как и следует. Но опять же, не то, что нам в итоге необходимо.
Делаем фокус - ставим оба параметра равными 2. Получаем прекрасное:

Что и требовалось. Процессор один, число ядер - два.
То есть получаем, что по факту в vSphere 4.1 параметр number of virtual processors определяет не количество самих процессоров, а количество ядер, которое будет отдано в распоряжение ВМ. А число процессоров уже рассчитывается по формуле number of virtual processors / cpuid.corespersocket.
Все вышеуказанное справедливо именно для vSphere 4.1. Как дела обстоят в vSphere 5 - мне неизвестно, пятую версию использовать еще не доводилось.

@музыка: Buck-Tick - Dress (Trinity Blood Mix)

@темы: VMWare, Virtualization

22:03 

VMWare VCA-DCV certificate

В Dash'e под Chronostasis'ом.

Экзамен сдан еще 4 октября. Пакет пришел только пару дней назад, но он все же пришел.




Идем дальше...

@темы: VMWare, Virtualization

01:42 

Hyper-V Replication

В Dash'e под Chronostasis'ом.

Штудируем курс от MS, касающийся виртуализации на платформе Hyper-V, так как волею судьбы теперь я работаю с ней, а не с VMware. Дошли до репликации машин на удаленный сайт. Вроде бы все понятно, все ясно, и тут ведущие выдают просто потрясающее: до 20% потерянных циклов репликации считается нормой. Имеется в виду, что средства мониторинга Hyper-V поднимут предупреждение только после того, как число таких потерь превысит 20%.
Кхм... одна пятая от всех сеансов репликации за время наблюдения. И это, как я понимаю, ненастраиваемо.
Да, сама по себе итеративная репликация подразумевает, что в случае выхода из строя ВМ-источника при переключении на ВМ-копию будут потеряны (причем, безвозвратно) те данные, что не были реплицированы до сбоя. Но чтобы их было так много? Например, сценарий, где реплика проходит каждые 15 минут (максимальный интервал), и сбойные реплики с какого-то момента и перепуга идут подряд. Далее все зависит от того, от какого времени рассчитываются те самые 20%, но представим, что эти пять сбойных сеансов и стали критическими. Мониторинг начнет кричать только на шестой попытке. А это ни много ни мало - полтора часа. За полтора часа на производственной машине много чего может случиться. Если это файловый сервер - потеряем кучу изменений в файлах (слышатся вопли, допустим, юридического отдела: "Ааа, мы весь день в этом файле работали, все с начала начинать!"). Если это почтовый сервер - потеряем кучку входящих писем (начинает резать уши вопль из отдела продаж: "Ааа, у нас письмо там было на полтора лярда, верните сейчас же!"). Если это база данных... давайте не будем об этом...
Справедливости ради, для обеспечения доступности что почтовика, что сервера базы данных, сейчас уже используются другие методы, намного более эффективные. Все таки, Disaster Recovery Site - это, действительно, на случай ну просто полного эээмм... форс-мажора, назовем это так. А репликация делается, обычно, как раз в сторону DRS. Но все равно, одна пятая... Как было однажды сказано: "Шаня, я не знаю, как это в твоей системе координат, но в моей пять пицц - это пять пицц" ;)

@темы: Virtualization, Hyper-V, Этот безумный мир

03:54 

Nested Hypervisor

В Dash'e под Chronostasis'ом.

По большому счету, запись эта - шпаргалка для самого себя (записная же книжка, помним?), но мало ли кому еще пригодится.
Итак, ситуация - необходимо в виртуальной машине VMWare Workstation установить Hyper-V. При попытке провернуть такой фокус в виртуальной машине выведется печальное сообщение:
A hypervisor is already running.

Хотя в системе виртуальной машины ничем подобным и не пахнет.
Решение таково:
1. В vmx-файл виртуальной машины прописать следующее:

2. В свойствах виртуальной машины выбрать процессор(ы) и в его(их) свойствах включить следующие параметры: Virtualize Intel VT-x/EPT or AMD-V/RVI и Virtualize CPU performance counters
После этого установка Hyper-V завершится успешно.

@музыка: Diane and David Arkenstone - Night Flight

@темы: VMWare, Hyper-V, Virtualization

13:06 

Virtual Machine Manager 2012 Networking

В Dash'e под Chronostasis'ом.

Опять же, запись большей частью для себя и на память о том, как по-разному можно подходить к одному и тому же вопросу:
Hyper-V networking photo IMG244_zps6ee8c6fc.jpg

На осознание и понимание этой простейшей схемы ушла неделя прокуривания technet или даже больше. В то же время в vCenter все было настроено с первого тычка...

@темы: Hyper-V, Virtualization

16:23 

VMWare ESXi 5.5 with 2 GB RAM

В Dash'e под Chronostasis'ом.

Это извращение. Поскольку esxi 5.5 требует минимум 4 ГБ памяти, лучше просто добавьте памяти в хост-систему. Если же такой возможности нет...
1. Загрузить хост с диска установки esxi 5.5
2. На стартовом экране приветствия нажать Alt+F1, чтобы попасть в консоль.
3. Войти в систему, используя в качестве логина root с пустым паролем.
4. Сменить текущий каталог на /usr/lib/vmware/weasel/util
cd /usr/lib/vmware/weasel/util
5. Удалить скомплимированный скрипт установки, называется он upgrade_precheck.pyc:
rm upgrade_precheck.pyc
6. Сбросить неубиваемый обычными методами флаг Read Only с файла скрипта установки (файл upgrade_precheck.py)
cp upgrade_precheck.py upgrade_precheck.py.new
rm upgrade_precheck.py
cp upgrade_precheck.py.new upgrade_precheck.py
rm upgrade_precheck.py.new
chmod a+w upgrade_precheck.py

7. Отредактировать файл скрипта:
vi upgrade_precheck.py
В нем нужно найти параметр MEM_MIN_SIZE и прописать в него следующее:
MEM_MIN_SIZE = ((n * 1024 - 32) * SIZE_MIB
где n - количество гигабайт памяти в хосте.
Сохранение файла: :wq
8. Убить из памяти запущенный экземпляр инсталлятора (найти PID процесса /bin/python weasel/main.py):
ps -c | grep weasel
kill PID_of_/bin/python weasel/main.py

После выполнения восьмого пункта инсталлятор будет перезапущен автоматически с уже новыми требованиями по памяти.

@темы: VMWare, Virtualization

14:34 

Магия и технологии

В Dash'e под Chronostasis'ом.

Просто без лишних слов. Кусок романа "Тайна Клуба Дубовых Листьев":

— Если бы я не заселил это место, оно осталось бы бесполезной мертвой игрушкой. А беглые Магистры вдохнули в мой маленький остров жизнь, подарили ему часть своей силы. Теперь это место принадлежит им, и они не столько пленники, сколько его повелители. Если бы они оказались в настоящей Королевской тюрьме — ты же знаешь, какие там порядки? Колдовать в Холоми не получается ни у кого — по крайней мере, Очевидная магия там совершенно невозможна. А в Истинной эти ребята до сих пор не разбираются. И что бы они там делали? Жрали, спали, читали свежие газеты? Не так плохо по сравнению со смертью, но не так уж весело по сравнению с их нынешним существованием!
— Выходит, там, на острове, они могут колдовать? — осторожно спросил я.
— Сколько угодно, — кивнул Маба. — Но их чары не распространяются за пределы острова. Так что ребята могут творить все, что им вздумается, — нашему Миру они не повредят. Даже солнце тучкой на пять минут не закроют, ты уж мне поверь!


!!! ДА ЗДРАВСТВУЕТ ВИРТУАЛИЗАЦИЯ !!!

@музыка: Madonna - Frozen

@темы: Virtualization, VMWare, Hyper-V, Этот веселый мир

17:22 

VMware Hands-on-labs Site

В Dash'e под Chronostasis'ом.

VMWare просто молодцы. Давно пора было это сделать. Как в плане сервиса в целом, так и в плане поддержки/ее отсутсвия разных браузеров :)

 photo 95ea48f4-cd48-444d-ab4d-be97696de2e6_zps6e18096b.png

@темы: Virtualization, VMWare, Этот веселый мир

00:09 

Windows 10 Clustering

В Dash'e под Chronostasis'ом.


Во внутренних презентациях про производительность Storage Replica в Technical Preview Майкрософт использует один глагол - глагол "sucks". При этом утверждают, что это уже поправлено сейчас...

Говоря об асинхронной репликации... меня абсолютно не волнует сеть. Будь у меня Wifi, или 10 гигабит, мне наплевать...

Снапшоты... Дисковые снапшоты... и мы их, безусловно, должны реплицировать. Мы их пробуем реплицировать. И мы их реплицируем. Но они не работают.
Хотя это уже пофиксили.

Кибкало просто неподражаем :)

@темы: Virtualization, Hyper-V, Этот веселый мир

22:39 

VM Boot option

В Dash'e под Chronostasis'ом.

Буду краток. Запуск виртуальной машины в VMWare Workstation 10:

Я дождался!

@музыка: Genesis - Invisible Touch

@темы: Virtualization, VMWare

01:03 

VMWare Workstation copy/paste

В Dash'e под Chronostasis'ом.

Проблема, буквально задалбывающая при работе с VM WS - ни с того, ни с сего отваливается фукнция копирования/вставки их Host OS в Guest OS и наоборот. Обычный метод лечения - перезагрузка хоста, но бывают же случаи, когда перезагрузить хост просто нельзя. Тогда делаем так:
1. Идем в Guest OS. Вырубаем там процесс vmtoolsd.exe.
2. Идем в Host OS. Вырубаем там процесс vmware-tray.exe, после чего запускаем его заново.
3. Идем в Guest OS. Запускаем там ранее убитый vmtoolsd.exe при помощи команды "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr, или "C:\Program Files (х86)\VMware\VMware Tools\vmtoolsd.exe" -n vmusr для 64-bit Host OS.
И наслаждаемся копипастом ровно до следующего вылета.

Пробовал обойтись только перезапуском процесса в Guest OS, не помогает :(

@музыка: David Arkenstone - Prelude: Talis the messenger

@темы: Virtualization, VMWare

01:16 

Hyper-V HA VM Configuration

В Dash'e под Chronostasis'ом.

Пришла пора обновлять гипервизоры. Стандартная процедура при этом - выгнать с них все виртуалки, сидящие в кластере, погасить все, сидящие вне кластера. Делаем привычное Move - Live Migrate - Best Possible Node... И получаем облом вот такого вида:

Virtual machine migration operation for 'xxx' failed at migration source 'NODExxx'. (Virtual machine ID %VM-GUID%)

'xxx' failed to delete configuration: The request is not supported. (0x80070032). (Virtual machine ID %VM-GUID%)

Блуждания в инете говорят, что проблема в одном из двух:
1. Всякий антивирусный софт. В моем случае маловероятно, потому что с этой ноды уже несколько машин спокойно уехало. Для очистки совести заглянул в параметры антивирусного ПО - все, что относится к Hyper-V и кластеру - добавлено в исключения. Стало быть, не то.
2. Изменение настроек кластерной ВМ через оснастку Hyper-V. Рассуждения таковы: оснастка Hyper-V может банально не знать о кластерных настройках и при записи новых значений в файл просто вытрет их оттуда. Отсюда и кривая работа ВМ в кластере. Лечить - удалением пораженной машины из кластера и добавление оной в кластер заново.

В рабочем чате собирается BrainStorm. Поступает предложение выполнить валидацию всего кластера, исключив проверку стораджей. Запускаем. Проверка показывает ересь в плане сетевых настроек, но они на ВМ так влиять не должны. Смотрю на раздел VM Configuration, вместо привычного Success стоит Warning. А расскажи-ка мне поподробнее, что там предупреждение выкинуло? Каково же было мое удивление, когда я прочитал следующее:

Virtual Machine: xxx
Configuration Data Root: C:\ProgramData\Microsoft\Windows\Hyper-V

Вот в чем дело. Гипервизор считает, что файл описания ВМ хранится не на кластерном диске, а на локальном, куда хода остальным нодам кластера нет. Что ж, надо это исправить. Выключаем пораженную машину, в оснастке Failover Cluster Manager жмем на ней правой кнопкой мыши, выбираем Move, Virtual Machne Storage. В появившемся окне назначаем нужным разделам нужные каталоги на кластерном диске, и жмем ОК. А по нажатию кнопки ОК гипервизор нам заявляет, что переместить файл описания виртуальной машины не может, так как там этот файл уже есть. Хм... То есть у нас есть две копии одного файла, и рабочая из них та, что лежит в неположенном месте. Ладно, уберем их с кластерного диска, благо, имя конфликтующего файла оснастка кластера показывает. После этого дадим оснастке команду обновиться, чтобы она "забыла" о том, что на кластерном диске что-то было, и повторно попробуем переместить файлы конфигурации и обновить каталоги. В этот раз все прошло на ура.

Rinse and repeat 5 more times, потому что валидация кластера показала 6 таких пораженных виртуальных машин.

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

@музыка: Mass Effect 2 - Rescue Tali / Collectors Base Assault

@темы: Virtualization, Hyper-V

19:00 

Hyper-V Virtual Disk permissions

В Dash'e под Chronostasis'ом.

Чтобы больше не искать при случае.
Если перенесли vhd/vhdx-файл в другой каталог, скорее всего вы это сделали без сохранения прав на файл (типичный режим работы Проводника, будь он неладен). И эти права надо восстановить следующей командой:
icacls %VHD-or-VHDX-FILENAME% /grant "NT VIRTUAL MACHINE\%VM-ID%":(F)

Ну а сам VM-ID можно получить вот таким образом:
get-vm %VM-Name% | fl Id

@настроение: клац-клац-клац...

@темы: Virtualization, Hyper-V

22:29 

VirtualBox + NLB

В Dash'e под Chronostasis'ом.

В качестве системы десктопной виртуализации теперь отрабатывает VirtualBox. Его допилили до вменяемого состояния. Цель - NLB под Windows 2012 в гостевом домене. Стандартный сетап - две ноды по два интерфейса на ноду: один для управления, второй для кластера.
Читаем: начиная c Windows 2008 необходимо включать передачу трафика с одного сетевого интерфейса на другой (forwarding), или прибегать к multi-homed конфигурации, что не совсем хорошо. Уж лучше форвард, потому что все утверждают, что без этого работать ничего не будет. Не вопрос. Поднимаем обе ноды, ставим на них службы NLB, выдаем адреса сетевым адаптерам:
Node 1 - Management NIC: 192.168.1.11/24, GW: 192.168.1.254
Node 1 - NLB NIC: 192.168.10.1/24

Node 2 - Management NIC: 192.168.1.12/24, GW: 192.168.1.254
Node 2 - NLB NIC: 192.168.10.2/24

Поскольку у нас пара сетевых адаптеров на каждой ноде - выбираем режим работы кластера Unicast.

Развешиваем NLB кластер на NLB-адаптеры, даем ему адрес 192.168.1.20, включаем форвард. И... не выходит каменный цветок.

Меняем режим кластера на Multicast. Не работает.

Ладно, где наша не пропадала. Выбираем более легкий вариант - сетап с одним сетевым адаптером на ноду. Приводим настройки к начальному виду, убираем форвард (ибо в случае с одной сетевой картой он не нужен). Отключаем NLB NIC на обеих нодах. Развешиваем кластер на Management NIC, переключая кластер в Multicast, потому что с одной нодой работать можно только так. Не работает.

Курим. Оказалось, что сам VirtualBox в плане работы с NLB весьма прихотлив. На том адаптере, который будет заниматься обработкой кластерного трафика, в настройках виртуальной машины нужно включить т.н. "неразборчивый режим" сетевой карты. Включаем. Все взлетает.

Прокуриваем еще немного страниц в сети. Снова берем случай с двумя сетевыми картами на ноду, но адреса раздаем вот так:
Node 1 - Management NIC: 192.168.1.11/24, GW: 192.168.1.254
Node 1 - NLB NIC: 192.168.1.21/24

Node 2 - Management NIC: 192.168.1.12/24, GW: 192.168.1.254
Node 2 - NLB NIC: 192.168.1.22/24

То есть все 4 адаптера будут находиться в одной сети.

Снова развешиваем Multicast-кластер на NLB-адаптерах, включаем форвардинг, включаем "неразборчивость" сетевых карт. Работает. Интереса ради вырубаем форвард - работает. Еще ради интереса вырубаем "неразборчивость". Работает! Плюнув на все переключаем кластер в Unicast, поскольку в случае с двумя сетевыми предпочтительнее работать именно в нем. НЕ работает.

Вывод - VirtualBox может нормально общаться только с NLB Multicast-кластерами. Печально, но уж ничего не поделаешь. А вот то, что все работало вплоть до отключения Multicast... я могу только вспомнить старое доброе:
НУ ПОЧЕМУ ОНО РАБОТАЕТ?!

Хотя я и догадываюсь, почему оно даже без форварда работает в таком случае. Всему виной единая подсеть и долбанный on-link маршрут, который мне как-то очень сильно попортил крови. Впрочем, это уже другая история.

@музыка: Celtic Spirit - Runaway

@темы: Virtualization

13:28 

VM Storage target folders

В Dash'e под Chronostasis'ом.

Небольшая шпаргалка по переносу ресурсов виртуальных машин в кластере Hyper-V между разными CSV:

- VHD/-X переносится прямо в указанную целевую папку.
- XML-файл описания ВМ и снапшоты улетят в автоматически создаваемые подпапки в указанном каталоге.

Если представить это наглядно:

Результат перемещения ресурсов ВМ с диска Volume1 на диск Volume3. Перенос выполнялся в следующие каталоги:
Для файла VHDX - заказан перенос в папку Volume3\VHDXs. Диск улетел прямо в эту папку (созданную мной заранее).
Для всего остального - в папку Volume3. Подпапки Virtual Machines и Snapshots были созданы системой, ресурсы улетели именно в них.

Надеюсь, эта запись не даст мне впредь забыть, что и куда переносится. Имеющийся на работе бардак с расположением ресурсов разных ВМ меня уже порядком утомил, надо их к общему виду привести.

@музыка: RC88 - Rainbow Dash Theme (MLP - Fighting is Magic)

@темы: Virtualization, Hyper-V

17:25 

Guest VM provisioning

В Dash'e под Chronostasis'ом.

Очень хорошая статья на тему автоматической начальной настройки гостевой ОС:
Specialize Windows Server Hyper-V guest OS automatically - Клац!
Интересна она тем, что применить изложенный метод можно не только к Hyper-V, но и к любому гипервизору, способному работать с файловой системой оффлайн-ВМ. Потому как на одном из этапов нужно будет подложить в гостевую ВМ файл с параметрами машины.

Попробовав выполнить все описанное в VMWorkstation, могу сказать - работает. Если требуется поднять сразу пачку ВМ - все будет значительно быстрее, чем вбивать параметры сети и имени машины в домене руками. Хотя в моем случае нашлась пара подводных камней.

Первое. Засада с файлом ответов unattend.xml. В статье говорится, что ветку Autologon необходимо прописывать в этап конфигурации oobeSystem. В моем случае это не так, пришлось записать его в этап Specialize, иначе не работает.

Второе. В скрипте, где и выполняется настройка сети, между блоком работы с сетевым адаптером и блоком ввода в домен пришлось ввести задержку на несколько секунд. Иначе нарываемся на неприятность - сеть ВМ не успевает инициализироваться с новым адресом, а система уже пытается найти домен и присоединиться к нему. И ожидаемо валится.

@музыка: Nigel Stansord - Deep Space

@настроение: клац-клац-клац

@темы: Virtualization, VMWare, PowerShell, Hyper-V

Записная книжка

главная