Category: VMware

При попытке переноса одной ВМ между хранилищами было получено странное сообщение:

The ramdisk ‘root’ is full. As a result, the file /var/log/vmware/journal/… could not be written.

SSH на сервере не работал, поэтому пришлось лезть в iLO (это сервер HP).

Стандартная команда “df -h” результата не дала – вроде бы все хорошо.

Поиск в интернете выдал следующую KB2033073.

Два симптома из трех совпадали:

– не работал SSH;

– команда vdf -h выдавала полную занятость диска ‘root’ (Use = 100%).

Кем/чем – не понятно.

Из соседней KB была найдена команда, отобразившая список файлов >50MB

find / -path “/vmfs” -prune -o -type f -size +50000k -exec ls -l ‘{}’ \;

Почти все они, кроме /var/log/hpHelper.log относились к системным файлам. По этому журналу нагуглилась другая KB2055924.

Согласно этой KB, глюки софта от HP переполняли этот журнал при работе на Proliant Gen8.

Решение проблемы следующее:

1) Остановить агента HP Helper

/etc/init.d/hp-ams.sh stop

2) Удалить файл журналов

rm /var/log/hpHelper.log

3) Установить обновление на агентов или отключить агентов вообще

В случае отключения необходимо выполнить команду

chkconfig hp-ams.sh off

Если делать вообще ничего не хочется, можно перезагрузить хост. Однако, vMotion с такого хоста у меня тоже не сработал.

Если вы хоть раз создавали внешнюю базу для VMware Update Manager, то сталкивались с тем, что “обычный” ODBC-источник к ней не подходит. Это связано с тем, что UM – 32битное приложение и требует свои, 32битные ODBC Source.

У VMware есть своя статья, говорящая о том, как эти источники создавать:

• для 32 бит используется %windir%\SysWoW64\odbcad32.exe
• Для 64 бит – %windir%\System32\odbcad32.exe

Но, начиная с Windows 2012, процесс стал гораздо нагляднее: Continue reading “VMware Update Manager и ODBC 32bit”

Случайно нагуглил табличку с различными версиями виртуального железа:

Feature	ESXi 5.5 and later	ESXi 5.1 and later	ESXi 5.0 and later	ESX/ESXi 4.x and later	ESX/ESXi 3.5 and later
Hardware version	10	9	8	7	4
Maximum memory (GB)	1011	1011	1011	255	64
Maximum number of logical processors*	64	64	32	8	4
Maximum number of cores (virtual CPUs) per socket	64	64	32	8	1
Maximum SCSI adapters	4	4	4	4	4
Bus Logic adapters	Y	Y	Y	Y	Y
LSI Logic adapters	Y	Y	Y	Y	Y
LSI Logic SAS adapters	Y	Y	Y	Y	N
VMware Paravirtual controllers	Y	Y	Y	Y	N
SATA controllers	4	N	N	N	N
Virtual SCSI disk	Y	Y	Y	Y	Y
SCSI passthrough	Y	Y	Y	Y	Y
SCSI hot plug support	Y	Y	Y	Y	Y
IDE nodes	Y	Y	Y	Y	Y
Virtual IDE disk	Y	Y	Y	Y	N
Virtual IDE CD-ROMs	Y	Y	Y	Y	Y
IDE hot plug support	N	N	N	N	N
Maximum NICs	10	10	10	10	4
PCNet32	Y	Y	Y	Y	Y
VMXNet	Y	Y	Y	Y	Y
VMXNet2	Y	Y	Y	Y	Y
VMXNet3	Y	Y	Y	Y	N
E1000	Y	Y	Y	Y	Y
E1000e	Y	Y	Y	N	N
USB 1.x and 2.0	Y	Y	Y	Y	N
USB 3.0	Y	Y	Y	N	N
Maximum video memory (KB)	524288	524288	131072	131072	131072
SVGA displays	10	10	10	10	1
SVGA 3D hardware acceleration	Y	Y	Y	N	N
VMCI	Y	Y	Y	Y	N
PCI passthrough	6	6	6	6	0
PCI Hot plug support	Y	Y	Y	Y	N
Nested HV support**	Y	Y	N	N	N
vPMC support	Y	Y	N	N	N
Serial ports	4	4	4	4	4
Parallel ports	3	3	3	3	3
Floppy devices	2	2	2	2	2

* – максимальное количество процессоров в ВМ (vCPU) зависит не только от версии виртуального железа, но и от редакции гипервизора (Std/Ent и  т.д.) и количества логических процессоров на хосте.

** – по факту подразумевается проброс аппаратной виртуализации внутрь виртуальной машины. Это необходимо, чтобы в виртуальном ESXi с процессором Intel запустить 64битную ВМ. Без аппаратной поддержки виртуализации запустить 64битную ВМ на процессорах Intel нельзя. Стоит также отметить, что эта фича поддерживается на ограниченном количестве CPU.

Еще большее количество таблиц можно найти тут.