Новые правила DRS в vSphere 4.1

В vSphere 4.1 при создании DRS правил появилась еще одна очень полезная опция, а именно VMs to Hosts affinity rules.

VMs to Hosts affinity rule-ы бывают двух видов:

• Must run rules (Принудительные) (а так же anti affinity)
• Should run rules (Предпочительные) (а так же anti affinity)

Must run rules – принудительные правила ограничивают HA, DRS и пользователей таким образом, что виртуальная машина может не включиться или же переехать на другой ESX/ESXi хост который не принадлежит ассоциированный DRS host группе.

Should run rules – дает предпочтение DRS-у чтобы запустить виртуальную машину на хосте который указан в ассоциированной DRS host группе.

Два самых характерных примеров использования:

1. Несколько Blade-шасси с серверами и желание обеспечения того, чтобы VM с одинаковым функционалом всегда оставались в пределах разных шасси.

2. Несколько VM с интенсивным обменом данными между собой, которые правильно размещать на одном хосте (например приложение и база данных)

Как это сделать, подробно и в картинках, здесь

Masking a LUN from ESX(i) 4.x

Перепостчу интересную статью:

Начиная с версии ESX(i) 4.0, изменилась процедура маскирования LUN'ов на уровне гипрвизора. Вместо прописывания адресов LUN в Advance Settings -> Disk -> Disk.MaskLUNs, в vSphere для все путей переопределятся плагин PSA на специальный - MASK_PATH.

Для начала удаляем из инвентори все объекты, связанные со скрываемым LUN'ом. Далее:

1. esxcfg-scsidevs -l Первой строчкой описания каждого устройства идёт LUN_ID, запоминаем его для скрываемого LUN'а

2. esxcfg-mpath -L | grep Находим все пути для этого раздела. Запоминаем адрес ввиде: vmhba#:C#:T#:L#, в моём случае vmhba2:C0:T2:L0. При желание, это можно сразу посмотреть в vSphere Client.

3. esxcli corestorage claimrule add --rule 123 -t location -A vmhba2 -C 0 -T 2 -L 0 -P MASK_PATHДобавляем правило в конфигурационных файл. Выбираем любой незанятый номер правила, но обязательно из диапазона 101--200.

4. esxcli corestorage claimrule load Загружаем созданное правило в список активных

5. esxcli corestorage claimrule list Проверяем, что в списке есть два одинаковых правила с выбранным номером с параметрами file и runtime.

6. esxcli corestorage claiming reclaim -d Переопределяем текущие правила для путей раздела на только что созданные.

Всё. Считаем до 10 и LUN больше недоступен для добавления datastor'а. Все пути, помеченные MASK_PATH, переходят в состояние Dead.

По статье kb.

Для чего это нужно? Например, для процедуры корректного удаления LUN'а "на лету":

Удаляем всё с LUN'а-> маскируем его-> отменяем презентацию LUN'а хосту средствами стораджа-> удаляем правила маскирования.

Источник

Информация о физических подключениях с помощью Cisco Discovery Protocol (CDP)

Если на хостах ESX/ESXi включен CDP и на свитчах, к котором они подключены он так же включен, то мы можем видеть много полезной информации. Например к какому свитчу и к какому порту подключен хост.

Нижеследующая команда показывает эту информацию

vmware-vim-cmd hostsvc/net/query_networkhin

Источник

Настройка Round Robin Multipathing с помощью Powershell

Ниже процитирован скрипт для смены режима Multipathing на Round Robin.

Connect-VIServer vcenter.nh.novant.net
$h = get-vmhost testvsphere.nh.novant.net
$hostView = get-view $h.id
$policy = new-object VMware.Vim.HostMultipathInfoLogicalUnitPolicy
$policy.policy = "rr"
$storageSystem = get-view $hostView.ConfigManager.StorageSystem
$storageSystem.StorageDeviceInfo.MultipathInfo.lun |
where { $_.Path.length -gt 1 } |
foreach { $storageSystem.SetMultipathLunPolicy($_.ID, $policy) }

Источник

Установка HP ESXi Offline Bundle.

Для интерграции серверов HP с програмными продуктами необходимо устанавливать агентов HP CIM. После установки работать станет намного приятнее :) Например получим Hardware Status, сможем из vSphere клиента видеть инвентарный и серийный номер сервера.

Итак, приступим:

1. Скачать hp-esxi4.1uX-bundle-1.0.zip с сайта HP (HP ESXi Offline Bundle for VMware ESXi 4.1 )

2. Скопировать архив на DataStore сервера.

3. Перевести сервер в режим обслуживания.

4. Запустить в shell команду:

esxupdate update --bundle=/.../hp-esxi4.1uX-bundle-1.0a.zip

где вместо ... указать путь к файлу

Результат выполнения:

Unpacking cross_oem-hp-smx-pr.. ######################################## [100%]

Unpacking cross_oem-vmware-es.. ######################################## [100%]

Installing packages :cross_oe.. ######################################## [100%]

Running [cim-install.sh]...

ok.

Running [/usr/sbin/vmkmod-install.sh]...

ok.

Running [/sbin/esxcfg-secpolicy -p /etc/vmware/secpolicy]...

ok.

The update completed successfully, but the system needs to be rebooted for the

changes to be effective.

5. Перезагрузить хост

Также можно расположить файл на HTTP сервере, о чем очень подробно расписано тут.

Обновление Firmware HBA адаптера Emulex

Для обновления Firmware на адаптерах Emulex есть несколько способов.

Они очень подробно перечислены в Firmware Update Manual for Emulex® HBAs.

Здесь я хочу описать один из самых удобных на мой взгляд способе, с помощью утилиты doslpcfg.

Итак, чтобы обновить Firmware нужно выполнить ряд простых шагов:

1. Сделать образ загрузочной дискеты и расположить на ней утилиту doslpcfg, а также файл с обновленной прошивкой.

2. Загрузиться с этой дискеты и выполнить обновление.

Синтаксис команды:

смотрим текущую версию Firmware на HBA2:

doslpcfg listrev n=2 s=1

запуск скрипта

doslpcfg @script file name

пример

doslpcfg @C:\test\script1.txt

вывод команды в файл

DOSLPCFG listboot n=1 >result.out

обновление firmware из файла

doslpcfg download a=adapter name i=firmware image filename

обновление всех LP9802 HBAs firmware, находящейся в файле hd100a4.all:

doslpcfg download a=lp9802 i=c:\image\hd100a4.all

Обновление выбранного адаптера

doslpcfg download n=adapter number i=firmware image filename

пример

doslpcfg download n=6 i=lf191a5.all

Изменение параметров HBA адаптера Qlogic в VMWare ESXi 4.1

ESXi Tech Support Mode Procedure To Change HBA Parameters:

Enter Tech Support Mode on your ESXi Hypervisor terminal.

See VMware KB article 1017910: http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1017910&sliceId=2&docTypeID=DT_KB_1_1&dialogID=150110694&stateId=0%200%20150112078

1. List the Qlogic HBas on your ESX server:

# ls /proc/scsi/qla2xxx/

4 5

2. Display the detailed information for one of the specific HBAs:

# cat /proc/scsi/qla2xxx/4

QLogic PCI to Fibre Channel Host Adapter for QLE2460:

Firmware version 4.04.09 [IP] [Multi-ID] [84XX] , Driver version 8.02.01-k1-vmw43

BIOS version 2.02

FCODE version 2.00

EFI version 2.03

Flash FW version 4.04.02

ISP: ISP2432

Request Queue = 0x41813000, Response Queue = 0x41894000

Request Queue count = 4096, Response Queue count = 512

Total number of interrupts = 5036

Device queue depth = 0x20

Number of free request entries = 3679

Number of mailbox timeouts = 0

Number of ISP aborts = 0

Number of loop resyncs = 1

Host adapter:loop state = , flags = 0x105ac3

Dpc flags = 0x0

MBX flags = 0x0

Link down Timeout = 045

Port down retry = 005

Login retry count = 008

Execution throttle = 2048

ZIO mode = 0x6, ZIO timer = 1

Commands retried with dropped frame(s) = 0

Product ID = 0000 0000 0000 0000

NPIV Supported : Yes

Max Virtual Ports = 127

SCSI Device Information:

scsi-qla0-adapter-node=2000001b329328b8:610813:0;

scsi-qla0-adapter-port=2100001b329328b8:610813:0;

FC Target-Port List:

scsi-qla0-target-0=5006016941e00787;

scsi-qla0-target-1=5006016041e00787;

FC Port Information:

scsi-qla0-port-0=50060160c1e00787:5006016941e00787:610113:81;

scsi-qla0-port-1=50060160c1e00787:5006016041e00787:610013:82;

3. View the modules loaded for the Qlogic HBA:

# /usr/sbin/esxcfg-module -g qla2xxx

qla2xxx enabled = 1 options = '' (currently there are no options set.)

4. Display the current Queue Depth for the Qlogic HBA:

# cat /proc/scsi/qla2xxx/4 | grep -i "queue depth"

Device queue depth = 0x20

5. Change the Queue Depth for the HBA to 64:

# esxcfg-module -s ql2xmaxqdepth=64 qla2xxx

6. Reboot the ESX server for the change to take effect:

NOTE: Ensure the ESXi server is in maintenance mode and all VMs are either vMotioned to another server or powered off.

# reboot

7. Display the current Queue Depth for the Qlogic HBA:

# cat /proc/scsi/qla2xxx/4 | grep -i "queue depth"

Device queue depth = 0x40

The queue depth has now been sucessfully changed for this HBA from 32 to 64.

ESXi 4.1 vSphere CLI Procedure to Change HBA Parameters

Identify the Qlogic driver Modules installed in your system.

C:\VMware\VMware vSphere CLI> vicfg-module.pl –l

(The following output was edited to only show the Qlogic modules)

Name ID Loaded

qla4xxx 36 Yes (iSCSI HBA driver)

qla2xxx 37 Yes (Fibre Channel HBA driver)

2. List the current options enabled for the Qlogic driver.

C:\VMware\VMware vSphere CLI> vicfg-module.pl –g qla2xxx

qla2xxx options = '' (currently there are no options set.)

3. Set the queue depth for the qla2xxx driver to 64.

C:\VMware\VMware vSphere CLI> vicfg-module.pl –s ql2xmaxqdepth=64 qla2xxx

No response is echoed.

4. Check the queue depth setting for the qla2xxx driver.

C:\VMware\VMware vSphere CLI> vicfg-module.pl -g qla2xxx

qla2xxx options = 'ql2xmaxqdepth=64'

Additional Common Parameter Examples:

vSphere CLI commands are shown in blue.

qla4xxx iSCSI driver

Keep Alive Timeout:

~ # esxcfg-module -s ka_timeout=120 qla4xxx

C:\VMware\VMware vSphere CLI> vicfg-module.pl -s ka_timeout=120 qla4xxx

~ # esxcfg-module -g qla4xxx

qla4xxx enabled = 1 options = 'ka_timeout=120'

C:\VMware\VMware vSphere CLI> vicfg-module.pl -g qla4xxx

qla4xxx enabled = 1 options = 'ka_timeout=120'

qla2xxx Fibre Channel driver

Extended Error Logging

# esxcfg-module -s "ql2xextended_error_logging=1" qla2xxx

C:\VMware\VMware vSphere CLI> vicfg-module.pl -s ql2xextended_error_logging=1 qla4xxx

#esxcfg-module -g qla2xxx

qla2xxx enabled = 1 options = 'ql2xextended_error_logging=1'

C:\VMware\VMware vSphere CLI> vicfg-module.pl -g qla2xxx

qla2xxx enabled = 1 options = 'ql2xextended_error_logging=1'

В завершение список остальных параметров:

Qla2xxx Fibre Channel driver parameter option definitions for ESXi 4.1

Note: INT stands for Integer

heap_initial: int Initial heap size allocated for the driver.

heap_max: int Maximum attainable heap size for the driver.

ql2xallocfwdump: int Option to enable allocation of memory for a firmware dump during HBA initialization. Memory allocation requirements vary by ISP type. Default is 1 - allocate memory.

ql2xcmdtimeout: int Timeout value in seconds for scsi command, default is 20

ql2xcmdtimermin: int Minimum command timeout value. Default is 30 seconds.

ql2xdevdiscgoldfw: int Option to enable device discovery with golden firmware Default is 0 - no discovery. 1 - discover device.

ql2xenablemsi: int Enables MSI-X/MSI interrupt scheme Default is 0 - disable MSI-X/MSI. 1 - enable MSI-X/MSI.

ql2xexecution_throttle: int IOCB exchange count for HBA.Default is 0, set intended value to override Firmware defaults.

ql2xextended_error_logging: int Option to enable extended error logging, Default is 0 - no logging. 1 - log errors.

ql2xfdmienable: int Enables FDMI registratons Default is 0 - no FDMI. 1 - perfom FDMI.

ql2xiidmaenable: int Enables iIDMA settings Default is 1 - perform iIDMA. 0 - no iIDMA.

ql2xintrdelaytimer: int ZIO: Waiting time for Firmware before it generates an interrupt to the host to notify completion of request.

ql2xioctltimeout: int IOCTL timeout value in seconds for pass-thur commands. Default is 66 seconds.

ql2xloginretrycount: int Specify an alternate value for the NVRAM login retry count.

ql2xlogintimeout: int Login timeout value in seconds.

ql2xmaxqdepth: int Maximum queue depth to report for target devices.

ql2xmaxsgs: int Maximum scatter/gather entries per request, Default is the Max the OS Supports.

ql2xoperationmode: int Option to disable ZIO mode for ISP24XX: Default is 1, set 0 to disable

ql2xplogiabsentdevice: int Option to enable PLOGI to devices that are not present after a Fabric scan. This is needed for several broken switches. Default is 0 - no PLOGI. 1 - perfom PLOGI.

ql2xqfullrampup: int Number of seconds to wait to begin to ramp-up the queue depth for a device after a queue-full condition has been detected. Default is 120 seconds.

ql2xusedefmaxrdreq: int

ql2xusedrivernaming: int Enables Consistent Device Naming feature Default is 0, set 1 to enable.

qlport_down_retry: int Maximum number of command retries to a port that returns a PORT-DOWN status.

usedefmaxrdreq: Default is 0 - adjust PCIe Maximum Read Request Size. 1 - use system default.

Qla4xxx (iSCSI HBA) driver parameter option definitions for ESXi 4.1

cmd_timeout: int Command Timeout

extended_error_logging: int Option to enable extended error logging, Default is 0 - no logging, 1 - debug logging

gratuitous_arp: int Gratuitous ARP

heap_initial: int Initial heap size allocated for the driver.

heap_max: int Maximum attainable heap size for the driver.

ioctl_timeout: int IOCTL Timeout

ka_timeout: int Keep Alive Timeout

ql4xdiscoverywait: int Discovery wait time

ql4xdontresethba: int Dont reset the HBA when the driver gets 0x8002 AEN default it will reset hba :0 set to 1 to avoid resetting HBA

recovery_tmo: int Recovery Timeout

Создание резервной копии базы vCenter

У многих база vCentr'а располагается на локальном SQL Express. Возникает вопрос с бекапом базы. Есть Отличная утилита Data Migration Tool, но она не работает с vCenter 4.1. Выход - использование SQL Server Management Studio Express. Процитирую источник:

Creating a Backup Script

If you don’t have SQL Server Management Studio Express installed already, download and install it now.

Fire it up and log on with a user that has sufficient permissions to access the vCenter database

Find your vCenter database by expanding Databases and select VIM_VCDB

Right click on VIM_VCDB and select Tasks and then Back Up…

This opens the Back Up Database window, where you set your backup options. Set your options in a manner that fits your environment. You can set options like the backup file location, retention policy etc.

So far, this is all fine and dandy. You can create a manual backup this way, without much hassle. How can we turn that into a scheduled job?
The first bit is to turn your backup options into a SQL script that can be scheduled. You do this by finding the Script drop-down menu on the top of the Backup Database window. Select Script Action to New Query Window.

This opens the script window, where you can see the script and test it to make sure it works as intended.

The next step is to save the generated script, you do so my going to File and select Save … As. I’ve created a folder called c:\scripts\ that I use to store my SQL scripts in, so I’ll save the backup script there as FullBackupVCDB.sql.

Scheduling the Backup Script

Now that we have a working backup script, we need to be able to schedule it to run. As we can’t do that within the SQL Server Management Studio Express application, we need to find another way of scheduling it. Windows Server 2008 R2 (and other versions) include a scheduling tool, and that’s what we’ll use to create our schedule.

On my standard vCenter installation, the SQL Server is installed in the default location of C:\Program Files (x86)\Microsoft SQL Server\. This means that the actual command we need to schedule will be (be sure to replace the server-/instance-name and script name if your values differ from mine):

“C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\SQLCMD.EXE” -S [servername]\SQLEXP_VIM -i c:\scripts\FullBackupVCDB.sql

Go to the Control Panel and select Schedule Tasks. Click Create Basic Task, give it a name and set an appropriate schedule.

Select Start a program as the action for the task, and when it asks for Program/Script enter “C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\SQLCMD.EXE” -S [servername]\SQLEXP_VIM -i c:\scripts\FullBackupVCDB.sql.

Click next and check the box that says Open the Properties dialog for this task when I click Finish then click Finish. In the VCDB Backup properties, make sure the Run whether user is logged on or not option is selected, to make sure the schedule runs as planned.

Once you have verified that the schedule works as intended, make sure that you include the location for your vCenter database in your regular backup scheme, and you should we a lot safer than you were.

Источник