Русфонд

понедельник, 28 февраля 2011 г.

После перезагрузки не стартует служба VMware VirtualCenter Server

Если VirtualCenter использует локальную БД SQL Express 2005, то служба VMware VirtualCenter Server может стартовать раньше службы SQL Server. Чтобы VMware VirtualCenter Server ждал старта службы SQL Server настраиваем зависимость:
  1. Открываем список служб (services.msc).
  2. Для службы SQL Server > Properties > смотрим поле Service Name (например, MSSQL$SQLEXP_VIM).
  3. Правим ключ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vpxd: в значении DependOnService вписываем Service Name из предыдущего пункта.
  4. В итоге, для службы VMware VirtualCenter Server > Properties > на вкладке Dependencies появилась зависимость от службы SQL Server.

Как убрать значок VMware Tools из системного трея


Правим ключ реестра
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Tools.
Для значения ShowTray выставляем значение 0.

пятница, 25 февраля 2011 г.

Виртуальная машина c Windows 2008 теряет шлюз после перезагрузки

Для решения проблемы найдено знание 1016878.
Смотрим ключ реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<GUID>\DefaultGateway.
Удаляем все записи в ключе, находящихся выше правильного шлюза. Либо, если правильной записи вообще нет, добавляем ее руками.
Ну и не забываем ставить виндовые патчи.

вторник, 22 февраля 2011 г.

Ограничение количества процессоров и объема памяти для Windows-машины

Утилита System Configuration (msconfig.exe) позволяет в GUI править файл boot.ini (и нетолько его). Например, возможно уменьшить ресурсы (CPU, RAM). Указывается необходимое число ядер и максимальный размер памяти в MB. Естественно, далее нужно перезагрузится. Зато не нужно лезть в железо.
Век живи, век учись ))

вторник, 15 февраля 2011 г.

P2V для рабочих станций (и не только)

Хотим виртуализировать соседнюю рабочую станцию для игрушек.
Рабочая станция WS1 - та, которую виртуализируем.
Рабочая станция WS2 - та, на которой будет запускаться виртуальная WS1.

На WS1 устанвливаем VMware Converter, перезагружаемся.
На WS2 устанвливаем VMware Player, перезагружаемся.
Создаем образ WS1:

  •  Запускаем VMware Converter > Convert Machine;
  •  Выбираем источник Powered-on machine > This local machine;
  • Выбираем тип назначения VMware Workstation or other VMware virtual machine > VMware Workstation 7.0.x;
  • Указываем имя виртуальной машины (DNS-имя в ОС при этом не меняется);
  • Указываем путь, куда будет сохранен образ Select a location for the virtual machine;
  • В окне Options при необходимости меняем размер диска (уменьшаем для экономии), количество CPU, RAM, для Network Adapter указываем NAT и снимаем галку Connect at power-on (чтобы при включении виртуалки не было конфликтов с исходником);
  • Finish.
Копируем папку с образом WS1 на WS2.
 На WS2 запускаем VMware Player > Open Virtual machine > указываем путь к папке с образом WS1 > Edit virtual machine settings > Смотрим, что получилось, удаляем ненужные устройства (Serial port, USB и т. п., CD оставляем для установки VMware Tools).
Запускаем виртуальную машину, устанавливаем VMware Tools, при необходимости подключаем сеть (Edit virtual machine settings > Network Adapter > Connected, Connect at power-on).
Очень подробно тут.

Размер блока и раздела VMFS-3

VMFS block size and the VMFS datastore size
На днях к виртуальной машине (vCenter 4.1, ESX4.1) подключаю RDM-раздел и получаю ошибку "File[Name Datastore]nameVM.nameVM.vmdk is larger than the maximum size supported by datastore Name Datastore".
Ищу на http://kb.vmware.com/, получаю знание 1029697, где говорится правильно выбирайте VMFS block size. Вижу, где прокол (см. максимумы). Ограничение относится к VMFS-3.
Но самое интересное, что за год до этого на ESX 3.5 удалось подключить раздел размером 1TB, а виртуальная машина была на таком же VMFS-разделе, и после обновления на 4.1 прекрасно работает.. Возможно, дело в версии hardware виртуальной машины (как-нибудь проверю). Но  вопрос не в этом. До этого случая я никогда не обращал внимание на вопрос выбора размера блока VMFS и создавал datastore по умолчанию (block size 1MB). Обозначилась необходимость понимать, на что влияют размер блока, размер раздела, и учитывать это при планировании хранилища.
Результат изысканий:
И так, от размера блока зависит максимальный размер файла на разделе, и соответственно, размер виртуального диска, который можно выделить виртуальной машине:
VMFS-3
MAX block size 8MB
File size (1MB block size) 256GB
File size (2MB block size) 512GB
File size (4MB block size) 1TB
File size (8MB block size) 2TB minus 512B
Files per volume Approximately 30,720
Размер блока выбирается при создании VMFS-раздела. Размер блока нельзя изменить, при необходимости придется удалять Datastore и создавать заново.
Размер блока не оказывает влияние на производительность хранилища.
Размер блока не несет дополнительных накладных расходов на хранилище, т. к. для папок и файлов размером менее 1MB используются sub-bloks. Размер sub-blok 64KB. Количество sub-block ограничено, неболее 4096, после превышения этого порога используются блоки.
Проблемы при использовании разных размеров блока на разных Datastores:
  • vStorage APIs for Array Integration (VAAI - технология, позволяющая передать часть операций по работе с хранилищем от хоста к самому хранилищу) не работает между datastores с разными блоками;
  • VMware Consolidated Backup (VCB), использующий hot-add backup, может не работать;
  • другие системы резервного копирования, использующий hot-add backup, могут иметь такое же ограничения; например, мануле VDR сказано: "When choosing a datastore on which to store the files for the backup appliance, choose a datastore with the largest VMFS block size. This is necessary to ensure that the backup appliance can back up virtual machines from all datastores." (При выборе datastore, где будут хранится файлы backup applience, выбирайте datastore с самым большим размером блока. Это необходимо для того, чтобы быть уверенным, что backup applience сможет выполнить бэкап виртуальных машин со всех datastores).
  • могут быть проблемы с RDM-дисками и снэпшотами.
Подробнее о возможных проблемах с RDM-дисками и снэпшотами.
Итак, мы выбрали размер блока, разместили на datastore виртуальную машину и подключили к ней RDM-диск нужного размера. При этом, на datastore появится VMDK-файл (указатель), отображаемый размер которого соответствует размеру RDM. RDM может быть больше datastore.
Подключить RDM, размер которого не соответствует размеру блока VMFS, система не позволит (в этом я убедился на собственном опыте). Ограничения такие же, что и для файлов на VMFS.
Если RDM, больше datastore, то при попытке сделать снэпшот, получим ошибку Error: File ….. is larger than the Maximum size supported by datastore [NameDatastore]. Если RDM небольше datastore, снэпшот будет создан, независимо от того сколько свободного места на datastore.

Вывод - при планировании хранилища необходимо:
  1. выбирать одинаковый размер блока на разных datastores;
  2. учитывать размеры виртуальных дисков, которые будут использоваться в вашей среде; некоторые рекомендуют везде использовать максимальный размер блока 8MB;
  3. учитывать наличие RDM-дисков у виртуальных машин.
Использованы источники:

четверг, 10 февраля 2011 г.

Failover Cluster: Смена IP-адреса кластера

Если появляется необходимость смены IP-адресов серверов - узлов кластера, встает проблема смены IP-адреса самого кластера.
В failover cluster на Win 2008, в отличии от кластера на Win 2003, нет возможности изменить IP-адрес кластера в GUI консоли администрирования. Для смены кластерного IP пользуемся командной строкой.
  1. Меняем IP-адрес одного из узлов кластера. Смотрим консоль администрирования кластера Failover Cluster Management > [ClusterName] > Networks. Тут появляется вторая сеть, например Cluster Network 2.
  2. Если необходимо, меняем IP-адрес ресурсов кластера. Это можно сделать в GUI.
    Изменяем запись в DNS.
    Далее, Failover Cluster Management > [ClusterName] > Serveces and Applications > [ClusterGroupName] > [ResourceName] > [IP Address] > правый клик Properties > выбираем в поле Network "Cluster Network 2" и вписываем новый IP-адрес ресурса > жмем OK.
    Ресурс должен переместится на узел с новым IP-адресом.
  3. Меняем IP-адрес кластера. В командной строке набираем
    cluster res
    cluster res "Cluster IP Address" /priv 

    и смотрим, что имеем сейчас.
    Далее, набираем
    cluster res "Cluster IP Address" /priv Network="Cluster Network 2" address=[NewIPadddress] SubnetMask=[NewSubnetMask]

    Меняем запись в DNS.
  4. Меняем IP-адрес второго узла. После перезагрузки узла кластер доступен по новому IP-адресу.

VMware блоги

Настраиваем на Win 2003 кластер большиства со свидетелем

Win 2003 MSCS MNS FSW (Majority Node Set with File Share Witness)
В консоли администрирования кластера указать путь к свидетелю нельзя. Эти настройки выполняем с помощью командной строки (подробно тут).
Кратко:
После того как кластер собран (неболее двух узлов для кластера со свидетелем на Win 2003), и пользователю, от имени которого работает Cluster Service, назначены права на запись на шару свидетеля, выполняем команды:
  1. Cluster <ClusterName> res "Majority Node Set" /priv MNSFileShare=<ShareUNCPath>,
  2. Cluster <ClusterName> group "Cluster Group" /move (мигрировать группу можно и из консоли),
  3. Cluster <ClusterName> res "Majority Node Set" /priv (проверка настроек),
где <ClusterName> - имя кластера, <ShareUNCPath> - путь к файловой шаре свидетеля.