Уменьшение размера vmdk-файла

Бывает после ошибок планирования, или каких либо других факторов, появляется необходимость уменьшить раздел диска VM. Посмотрим как это можно сделать.

1. Нужно уменьшить раздел гостевой ОС до минимально возможного значения.

2. Выключить VM.

3. Уменьшаем диск:

Открываем файл disk.vmdk. Видим там что то вроде
# Extent description
RW 52428800 VMFS “foo-flat.vmdk”

Умножением RW на 512 получаем размер диска:
52428800 * 512 = 26 843 545 600 (25.6 ГБ).

Например, хотим уменьшить диск до 12 ГБ. Для этого меняем disk.vmdk с помощью текстового редактора (vi или nano):
# Extent description
RW 12582912 VMFS “foo-flat.vmdk”

Теперь делаем Storage VMotion или Clone этой ВМ, и после этой операции диск становится нужного размера.

4. Включаем VM.

5. Расширяем партицию до размера диска.

По мотивам статьи

Настройка статического MAC-адреса для VM

Иногда бывает необходимо задать статический MAC адрес для VM. Например при P2V миграции, когда лицензия приложения привязывается к MAC адресу.

С помощью VMware vSphere Client можно задать статический MAC, но только из диапазона 00:50:56:00:00:00 - 00:50:56:FF:FF:FF.

Изменить можно так же с помощью редактирования VMX-файла VM, при этом можно присвоить любой MAC-адрес.

Алгоритм:

1. Выключаем VM.

2. копируем vmx-файл на рабочую станцию.

3. Меняем значение ethernet0.addressType с “vpx” на “static”.

4. Меняем ethernet0.GeneratedAddress на ethernet0.Address и пишем нужный MAC:

ethernet0.address = "00:10:43:45:14:CC"

5. Включаем VM.

PS: иногда система не перечитывает vmx файл при запуске - как итог имеем случай, что VM оказывается со старым MAC-адресом.

Такой случай решается очень просто:

1. Выключаем VM

2. заходим в консоль ESXi по SSH.

3. Выполняем 2 команды:

vim-cmd vmsvc/getallvms |grep

Результат будет примерно таким:

32 SRVTST [Test] SRVTST/SRVTST.vmx rhel5Guest vmx-07 Test Server

32 - это Inventory ID виртуальной машины.

Перезагружаем файл VM:

vim-cmd vmsvc/reload 32

Virtual Machines Newtork Adapter Types

Существуют следующие типы виртуальных сетевых интерфейсов:

• Vlance
• VMXNET
• Flexible
• E1000
• VMXNET 2 (Enhanced)
• VMXNET 3

Рассмотрим каждый из них по подробней:

Vlance – это эмулированная версия 10 Mbps-ого NIC-а AMD 79C970 PCnet32 LANCE NIC, чей драйвер доступен почти во всех 32 битных операционных системах за исключением Windows Vista и новее.

VMXNET – данный виртуальный адаптер не имеет физического аналога. Из за того что драйвера для VMXNET-а не встроены в операционные системы, нам надо устанавливать VMware Tools чтобы ОС его распознала.

Flexible – он идентифицирует себя как Vlance адаптер во время загрузки виртуальной машины, но инициализируется и функционирует как Vlance или VMXNET адаптер, зависимо от того установлены ли VMware Tools. Если VMware Tools установлены он себя ведет как VMXNET, а если же нет то как Vlance.

E1000 – это эмулированная версия Intel 82545EM Gigabit Ethernet NIC-а. Драйвера для данного адаптера включены почти во все современные операционные системы, а точнее:

• Linux с кернелом 2.4.19 и новее
• Windows XP Professional x64 Edition и новее
• Windows Server 2003 (32/64bit) и новее

VMXNET 2 (Enhanced) – данный адаптер основан на адаптере VMXNET, но предоставляет нам несколько высоко производительных функций такие как jumbo frame-ы* и hardware offloads. Он доступен начиная с ESX/ESXi 3.5 версии гипервизоров или же новее, и только в некоторых операционных системах:

• 32 and 64bit versions of Microsoft Windows 2003 (Enterprise and Datacenter Editions)
• 32bit version of Microsoft Windows XP Professional
• 32 and 64bit versions of Red Hat Enterprise Linux 5.0
• 32 and 64bit versions of SUSE Linux Enterprise Server 10
• 64bit versions of Red Hat Enterprise Linux 4.0
• 64bit versions of Ubuntu Linux

VMXNET 3 – данный адаптер является новым поколением паравиртуализированного NIC-а разработанного для более высокой производительности по сравнению со своими предшественниками. Он никак не связан не с VMXNET 2, не с VMXNET. Он полностью включает в себя функционал VMXNET 2 адаптера, а также в нем добавлено несколько новых функций такие как:

• Мultiqueue support (Receive Side Scaling в Windows системах)
• IPv6 offloads
• MSI/MSI-X interrupt delivery

VMXNET 3 поддерживается на виртуальных машинах только с hardware version 7, а так же с ограниченным количеством гостевых операционных систем:

• 32 and 64bit versions of Microsoft Windows XP, 2003, 2003 R2, 2008,and 2008 R2
• 32 and 64bit versions of Red Hat Enterprise Linux 5.0 и новее
• 32 and 64bit versions of SUSE Linux Enterprise Server 10 и новее
• 32 and 64bit versions of Asianux 3 и новее
• 32 and 64bit versions of Debian 4
• 32 and 64bit versions of Ubuntu 7.04 и новее
• 32 and 64bit versions of Sun Solaris 10 U4 и новее

* Jumbo frame-ы не поддерживаются в виртуальных машинах где гостевой ОС работает Solaris не при использовании VMXNET 2 адаптера не при использовании VMXNET 3 адаптера.

** Fault Tolerance не поддерживается на виртуальной машине использующий VMXNET 3 vNIC на vSphere 4.0, но полностью поддерживается когда она запушена на vSphere 4.1.

Источник

Бесплатная утилита vDisk Informer - выравнивание блоков в среде VMware vSphere

Ricky El-Qasem, автор сайта VirtualizePlanet.com, выпустил интересную бесплатную утилиту для VMware vSphere - vDisk Informer. Эта утилита решает две важные проблемы:

1. Поиск виртуальных машин, дисковое пространство которых используется неэффективно, попросту говоря, много свободного места:

При сканировании виртуальной инфраструктуры можно задавать объем в ГБ или МБ, начиная с которого будут отображаться соответствующие иконки, говорящие нам о том, что можно уменьшить диск виртуальной машины.

2. Вторая функция нужнее - она позволяет определить виртуальные машины, у которых наблюдается проблема некорректного выравнивания блоков дисков VMDK (например, после P2V-миграции). Можно также задавать параметры смещения - 32K или 64K (в зависимости от SAN-массива, где лежат ваши ВМ):

Скачать vDisk Informer можно по этой ссылке. Видео о возможностях здесь.

Источник

Подключение локального диска через RDM

Поиск решения дал ссылку на решение, которое работает в ESX 3.5.

Опытным путем было установлено, что для ESX 4.0 данные рекомендации будут выглядеть так:

1. Создаем для VM новый диск, после этого данный диск Remove без удаления, чтобы получить vmdk-файл/заготовку для конвертации! Диск можно создавать с параметрами по умолчанию. Какие они - не важно.
2. Открываем Putty, чтобы в  консоли написать немного команд.
3. Смотрим  разделы  fdisk –l , находим нужный нам раздел из которого надо сделать RDM (можно опознать по размеру).
4. Вычисляем его имя (naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) через  esxcfg-scsidevs -c
5. После этого в консоли вводим команду vmkfstools -i  -d , которая делает конвертацию vmdk-файла.

Синтаксис ее такой : vmkfstools -i [Путь к vmdk –файл ] -d rdm:/vmfs/devices/disks/naa.xxxxxxxxxxxxxxxxxxxxx  [vmdk-файл]

Пример: [root@dell-nf500 Arizona]# vmkfstools -i /vmfs/volumes/Local_Servers_VM/Arizona/Arizona_1.vmdk -d rdm:/vmfs/devices/disks/naa.60022190bd135e001238f9a43a44a6d8 Local_RDM.vmdk

Таким образом мы конвертируем любой vmdk-файл в RDM.

6. После этого подключаем полученный vmdk через VC-клиент к VM и делаем с ним то, что считаем нужным.

Источник

Пятьдесят семь RDM

По целому ряду причин, а точнее из-за особенностей организации хранения данных пользователей потребовалось поэкпериментировать с массовым подключением RDM в MSCS кластере .  Всего было 46 LUN на EMC CX3-40F выбрано для эксперимента по их подключению.
При подключении 31 LUN начиналась череда дивных «глюков» связанных с вылетами по таймауту при запуске такой VM, проблемы с невозможностью сохранить конфигурацию VM.
Чтение документации от Vmware ничего не проясняло, кроме одного маленького упоминания о том, что кворумный диск лучше подключать на SCSI-адрес 1:1. О причинах и ограничениях там мило умолчали, предоставив пользователям строить догадки на эту тему. Методом научного тыка поиска было обнаружено, что адреса контроллеров 1:0, 2:0, 3:0 не пригодны для работы с RDM при количестве более 30 шт. При переходе границы этого числа ничего не работало, совсем и никак.

Таким образом, методом нехитрого сложения показаний выясняется, что ограничение на 60 дисков на одну VM это не так, в случае RDM, это всего лишь 57.

Источник

Reclaiming unused VMDK space with storage thin provisioning

Интересный момент касательно thin дисков проясняют тут: Reclaiming unused VMDK space with storage thin provisioning.
Поясню, к чему это относится:

Когда мы создаем диск ВМ (например, в 100ГБ размером), мы выбираем тип файла-диска: thick или thin.
В первом случае файл сразу резервирует под себя места на диске. 100 ГБ диск ВМ займет на системе хранения 100 ГБ.
Во втором случае файл создается нулевого размера, и растет по факту затребования места изнутри. Записали внутрь еще 500 мегабайт - он на них и вырос.

Это все хорошо. Плохо же то, что если мы внутри ВМ 500 МБ удалим, файл-диск не уменьшится. И если 5000 удалим, тоже не уменьшится. Сколько не удалим, не уменьшится, потому что с т.зрения схд удаления не происходила. Это гостевая ОС в своей файловой системе какие то блоки пометила как "их можно использовать". Получается, со стороны ESX(i) нельзя определить, какие из занятых блоков на самом деле свободны.

В общем, вот рецепт как отнять таки ранее востребованное, но потом освобожденное месте, т.е. как уменьшить vmdk файл в thin режиме:
Скачиваем утилиту sdelete внутрь ВМ.
Натравливаем ее на тот диск, где есть удаленные данные, командой
sdelete - c E:
это для диска E:\
Теперь необходимо сделать Storage VMotion этой ВМ, и указав

Change to Thin Provisioned Disk даже если диск еще не thin но вы хотите его таким сделать

или можно указать Keep Disk Format если диск ВМ уже thin.

Источник

Сохранение настройки IP при миграции на VMware vSphere

Когда вы переносите физический сервер в виртуальную среду на платформу VMware ESX, например, средствами VMware Converter, настройки IP исходной машины теряются, поскольку сетевой адаптер становится виртуальным, соответственно, и драйвер меняется и настройки сбрасываются на DHCP.

Перед P2V-миграцией сохраните настройки IP физического сервера командой:

netsh interface ip dump >> %systemroot%\NetworkSettings.txt 

Затем, смигрируйте этот сервер в виртуальную машину на VMware vSphere и восстановите настройки командой:

netsh -f %systemroot%\NetworkSettings.txt

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

Источник

USB safely remove virtual nic

Те из вас, кто работает с vSphere, уже наверное сталкивались с особенностью виртуальных сетевых контроллеров - они теперь USB.
Теперь мы не ограничены количеством PCI слотов, и можем добавлять до 10 vNIC на одну ВМ, но так же пользователь даже с юзерскими правами можеть удалить vNIC как USB устройство.

Решение:

в свойствах VM -> Options -> General -> Configuration Parameters

добавить параметр:

Name: devices.hotplug

Value: false

К сожалению этим мы отключаем возможность горячего добавления устройств.

Источник