Skip navigation
2011

Источник: KB Article: 1038963

Симптомы

  • Невозможно сделать snapshot виртуальной машины
  • Невозможно создать snapshot'ы
  • Невозможно применить snapshot виртуальной машины
  • Невозможно удалить snapshot'ы
  • Не видно snapshot'ов в Snapshot Manager'е


Решение



  • Убедитесь, что виртуальный диск (virtual disk) пригоден для создания снапшотов. VMware не поддерживает создание снапшотов для "сырых" дисков, дисков RDM в режиме физической совместимости, Independent дисков или для виртуальных машин, сконфигурированных с "bus-sharing". Для получения дополнительной информации обратитесь к разделу "Using Snapshots To Manage Virtual Machines" руководства Virtual Machine Administration Guide.


  • Убедитесь, что хранилище не заполнено и на нем достаточно места для применения (commit) всех снапшотов к ВМ. Для получения дополнительной информации обратитесь к документу: Investigating disk space on an ESX or ESXi host (1003564).


Примечание: Начиная с ESX 4.0 Update 2, больше не требуется дополнительное место для применения снапшотов.




  • Убедитесь, что ресурсов хранилища, на которое производится коммит (commit) достаточно. Для получения дополнительной информации обратитесь к документу: Investigating an out of resources error on a datastore (1003762).


  • Убедитесь, что у пользователя имеются права для создания или применения снапшотов. Для получения дополнительной информации обратитесь к документу: Reverting a snapshot fails with a permission denied error (1001600).


  • Убедитесь, что никакое другое стороннее программное обеспечение, предназначенное для резервного копирования (virtual backup software) виртуальных машин, не блокирует файлы снапшотов. Для получения дополнительной информации обратитесь к документу: Unable to commit virtual machine snapshots because another task is in progress (1010310).


Post Scriptum

Вдобавок к этому документу рекомендую посмотреть ранее сделанную мною подборку статей и постов на тему снапшотов: Snapshots: Подборка интересных постов и статей.

Команда FtpGet

С помощью данной программы можно скачать с FTP сервера какой-либо файл.
  • Список опций:
ftpget.jpg
  • Пример использования:
# cd /tmp
# ftpget -v -u Deshifrator -p 123 10.5.5.25 ReadMe.txt Install/ReadMe.txt
Connecting to 10.5.5.25 (10.5.5.25:21)
ftpget: cmd (null) (null)
ftpget: cmd USER Deshifrator
ftpget: cmd PASS 123
ftpget: cmd TYPE I (null)
ftpget: cmd PASV (null)
ftpget: cmd SIZE Install/ReadMe.txt
ftpget: cmd RETR Install/ReadMe.txt
ftpget: cmd (null) (null)
ftpget: cmd QUIT (null)


Команда FtpPut

С помощью данной программы можно закачать на FTP сервер какой-либо файл.

  • Список опций:

ftpput.jpg

  • Пример использования (создадим архив конфигурационных файлов системы и сохраним его на FTP сервер, адрес которого 10.5.5.25):
# /sbin/auto-backup.sh
# ftpput -u Deshifrator -p 123 10.5.5.25 state.tgz /bootbank/state.tgz


P.S.

По мотивам статьи, которую я прочитал в Базе Знаний на оф. сайте VMware: KB Article: 1033346

cron — это демон-планировщик задач в UNIX-подобных операционных системах, использующийся для периодического выполнения заданий в определенное время. Регулярные действия описываются инструкциями, помещенными в файлы crontab, которые находятся в каталоге: /usr/spool/cron/crontabs или /var/spool/cron/crontabs. (ru.wikipedia.org)

Для чего же нам может понадобиться планировщик в ESXi? Ну, например, вы хотите каждый день архивировать и сохранять на FTP сервер какой-либо важный для вас конфигурационный файл. Либо вам нужно собрать данные о производительности сервера ESXi в определенное время. Практически все периодические задачи поможет вам автоматизировать  планировщик заданий - демон cron. Чуть ниже показано, как можно автоматизировать процесс сбора информации о производительности хоста ESXi в определенное время.


Практикум

Редактируем конфигурационный файл cron'а для пользователя root, добавляя в него строку, запускающую каждую ночь, ровно в одну минуту первого (00:01), команду esxtop, собирающую информацию о производительности хоста ESXi каждые 60 секунд в течении 1440 итераций:

# echo '1 0 * * * /sbin/esxtop -b -d 60 -n 1440 > /vmfs/volumes/ESXi-01-Local/esxtop-output-`hostname`-`date +%Y-%m-%dT%H-%M-%SZ`.csv &' >> /var/spool/cron/crontabs/root

Для того, чтобы cron увидел только что сделанные изменения, перезапускаем его:

# kill `cat /var/run/crond.pid`
# /bin/busybox crond

Теперь всё готово, но есть одно очень большое НО. Все изменения, которые мы сделали в файле /var/spool/cron/crontabs/root, будут потеряны после перезагрузки хоста ESXi. С одной стороны - это хорошо, ну а с другой - не очень. Если нам нужно, чтобы наше крон-задание выполнялось и после перезагрузки хоста, то выполняем следующие действия:


  • Редактируем с помощью встроенного текстового редактора vi системный конфигурационный файл /etc/rc.local, добавляя в самый конец файла следующие строки:
/bin/kill `cat /var/run/crond.pid`
/bin/echo '1 0 * * * /sbin/esxtop -b -d 60 -n 1440 > /vmfs/volumes/ESXi-01-Local/esxtop-output-`hostname`-`date +%Y-%m-%dT%H-%M-%SZ`.csv &' >> /var/spool/cron/crontabs/root
/bin/busybox crond
  • Выполняем скрипт auto-backup.sh, чтобы изменения, сделанные в /etc/rc.local, сохранились после перезагрузки хоста (создаем резервную копию):
# /sbin/auto-backup.sh

Про cron в ESXi у меня всё. Чуть ниже приведу небольшой список статей, которыми я пользовался при написании данного поста.



P.S.

В статье "How to query for MACs on internal vSwitch on ESXi (англ.)", которая располагается в блоге virtuallyGhetto.com, описывается, как получить список MAC адресов на виртуальном свиче vSwitch в ESXi с использованием утилиты vsish (VMkernel Sys Info Shell) и самописного скрипта. К чему это я: те, кто не любит возиться со скриптами, могут поступить проще, получив список MAC адресов на виртуальном свиче (vSwitch), воспользовавшись для этого очень мощной, удобной и при этом свободной (free) программой для отображения информации о виртуальных машинах и хостах ESX/ESXi - RVTools:

rvtools-mac-list.jpg


P.S.

Источник: KB Article: 1011520


Изменяем для vSwitch0 политику балансировки нагрузки:

  • Route based on IP hash (IP-Hash):

vim-cmd /hostsvc/net/vswitch_setpolicy --nicteaming-policy='loadbalance_ip' vSwitch0

  • Route based on the originating virtual port ID:

vim-cmd /hostsvc/net/vswitch_setpolicy --nicteaming-policy='loadbalance_srcid' vSwitch0

Последняя команда особенно полезна в том случае, когда вы изменили политику балансировки для свича на IP-Hash и при этом "забыли" соответствующим образом настроить физические свичи, тем самым потеряв связь до сервера ESXi.


VMware ПРЕДУПРЕЖДАЕТ:

THE CONTENT OF THIS ARTICLE IS PROVIDED "AS-IS," AND TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, VMWARE DISCLAIMS ALL OTHER REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, REGARDING THIS CONTENT, INCLUDING THEIR FITNESS FOR A PARTICULAR PURPOSE, THEIR MERCHANTABILITY, OR THEIR NONINFRINGEMENT. VMWARE SHALL NOT BE LIABLE FOR ANY DAMAGES ARISING OUT OF OR IN CONNECTION WITH THE USE OF THIS CONTENT, INCLUDING DIRECT, INDIRECT, CONSEQUENTIAL DAMAGES, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF VMWARE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.


P.S.

Источник: KB Article: 1031873 и KB Article: 1020128


О том, что такое "Changed Block Tracking (CBT)" и с чем его едят, хорошо написано на vmgu.ru.


При написании данного поста наткнулся я на статью "vSphere Change Block Tracking" в блоге Сандро Галдава. Прочитав её, я понял, что уже все подробно написано до меня. Поэтому я не стану заново изобретать велосипед и просто напишу небольшую памятку, переведя официальную статью, взятую из VMware KB.


Чтобы активировать "Changed Block Tracking" для виртуальной машины, выполните следующие действия:


  1. Выключите виртуальную машину.
  2. Щелкните правой кнопкой мыши на ВМ и нажмите Edit Settings.
  3. Перейдите на вкладку Options.
  4. Щелкните по General в разделе Advanced и затем нажмите на кнопку Configuration Parameters. Откроется диалоговое окно.
  5. Щелкните по кнопке Add Row.
  6. Добавьте параметр ctkEnabled и установите для него значение, равное true.
  7. Щелкните по кнопке Add Row, добавьте scsi0:0.ctkEnabled и установите для него значение, равное true.

cbt.jpg

Note: scsi0:0 в scsi0:0.ctkEnabled указывает на SCSI устройство, ассоциированное с определенным жестким диском в виртуальной машине. При добавлении жесткого диска в виртуальную машину, ему назначается определенное SCSI устройство, например, scsi0:0, scsi0:1, или scsi 1:1.


P.S.

CDP (англ. Cisco Discovery Protocol) — проприетарный протокол второго уровня, разработанный компанией Cisco Systems, позволяющий обнаруживать подключённое (напрямую или через устройства первого уровня) сетевое оборудование cisco, его название, версию IOS и IP-адреса. (описание взято с сайта wikipedia.org)


ru.wikipedia.org


blog.scottlowe.org


vmwareinfo.com


vMind.ru


amikkelsen.com


vforv.me


vmetc.com


boche.net


kb.vmware.com

Оригинальная статья в VMware Knowledge Base
Troubleshooting IP-Hash outbound NIC selection (KB Article: 1007371)

Симптомы

Если вы настроили NIC Team (с использованием двух физических uplink'ов и EtherChannel) с целью увеличения пропускной способности до двух различных сетевых хранилищ (обычно NFS или iSCSI), и если для балансировки нагрузки вы используете IP-Hash (Route based on IP hash), то у вас могут возникнуть следующие проблемы:

 


  • Трафик на vSwitch не сбалансирован по uplink адаптерам
  • Весь трафик передается только через один uplink адаптер

Route based on IP hash - при использовании данной политики трафик от одного порта "виртуальной" стороны может выходить сразу через все порты "физической" стороны. Идентификатором условной "сессии", передаваемой через один pNIC, является не номер виртуального порта, как в первом случае, а хеш пары "IP-источник IP-получатель". Таким образом, трафик от одной ВМ к одному клиенту не займет больше одного pNIC, а вот трафик один-ко-многим может занять сразу все.

Выше приведенное описание Route based on IP hash взято из статьи, представленной в блоге Михаила Михеева www.vm4.ru.


Решение

Выше приведенные проблемы могут возникать из-за того, что при вычислении hash (хэш) для пары "IP-источник (source) IP-получатель (destination)", возвращается один и тот же результат. Чтобы решить данную проблему, воспользуйтесь ниже приведенными практическими примерами, чтобы вручную вычислить хэш для пары ip адресов. Эти примеры помогут вам выбрать два IP адреса так, чтобы использовались оба uplink адаптера на vSwitch.


Практический пример №1

В этом примере IP адреса для NFS хранилищ подобраны НЕПРАВИЛЬНО.


В данном примере мы использовали vSwitch с двумя uplink адаптерами, EtherChannel и политику балансировки нагрузки IP-Hash:


Links = 2 (0 и 1)

VMKnic 10.0.0.10 = 0xa00000a

NFS1 10.0.0.20 = 0xa000014

NFS2 10.0.0.22 = 0xa000016

  • Используйте следующую IP-Hash формулу, чтобы вычислить исходящий (outbound) адаптер:

 

VMKnic > NFS1 (0xa00000a Xor 0xa000014 =1E) % 2= 0
VMKnic > NFS2 (0xa00000a Xor 0xa000016 =1C) % 2= 0
    1. Откройте калькулятор, выберите Вид -> Программист (верное для Windows 2008 R2).
    2. Введите VMKnic IP адрес в HEX формате (a00000a) и нажмите Xor.
    3. Введите IP адрес NFS1 в HEX формате (a000014) и нажмите =.
    4. Нажмите Mod, потом 2 (кол-во uplink адаптеров) и затем нажмите =. Результат будет 0.
    5. Повторите действия с 1 по 5, используя при этом HEX IP адреса NFS2 (a000016) в шаге 3. Результат будет 0.

IP-Hash выберет первый uplink адаптер в группе потому, что у них один и тот же результат. То есть, в данном случае, когда у первого NFS сервера IP адрес 10.0.0.20, а у второго 10.0.0.22, политика балансировки нагрузки IP-Hash нам абсолютно ничем не поможет. Весь трафик будет ходить только через один физический сетевой интерфейс. Чтобы этого избежать, для NFS серверов нужно специальным образом подобрать необходимые IP адреса. Чуть ниже показан пример, в котором для NFS серверов подобраны правильные IP адреса.


Практический пример №2

В этом примере IP адреса для NFS хранилищ подобраны ПРАВИЛЬНО.


  • Измените IP адрес для NFS2 с 10.0.0.22 на 10.0.0.21
  • Используя любой online IP Hex Конвертер, преобразуйте IP адреса в Hex.

Links = 2 (0 и 1)

VMknic 10.0.0.10 = 0xa00000a

NFS1 10.0.0.20 = 0xa000014

NFS2 10.0.0.21 = 0xa000015

  • Используйте следующую IP-Hash формулу, чтобы вычислить исходящий (outbound) адаптер:
VMKnic > NFS2 (0xa00000a Xor 0xa000015 =1F) % 2= 1
    1. Откройте калькулятор, выберите Вид -> Программист.
    2. Введите VMKnic IP адрес в HEX формате (a00000a) и нажмите Xor.
    3. Введите IP адрес NFS2 в HEX формате (a000015) и нажмите =.
    4. Нажмите Mod, потом 2 (кол-во uplink адаптеров) и затем нажмите =. Результат будет 1.

Теперь IP-Hash алгоритм возвращает другой результат. А это значит, что IP-Hash будет распределять трафик, используя оба uplink адаптера на свиче (vSwitch). То, что нам и нужно.


Post Scriptum

Используя нехитрые инструменты (в частности, обычный windows калькулятор) и данную статью (либо статью в базе знаний VMware), можно избежать возможных ошибок при проектировании сетевой инфраструктуры. Как было видно, неправильно назначенный IP адрес для сетевого хранилища, может привести к тому, что мы не получим ожидаемого результата от политики балансировки нагрузки IP-Hash.


В общем, данный документ обязателен к прочтению каждому администратору виртуальной и сетевой инфраструктуры. Чуть ниже приведу пару ссылок на посты, так или иначе касающиеся темы балансировки нагрузки с использованием IP-Hash:



Если у вас на предприятии используется распределенный коммутатор (dvSwitch), то вам нужно использовать для балансировки нагрузки LBT, вместо Route based on IP hash. Почему именно так, написано в другом моём посте.

Deshifrator Hot Shot

IP-HASH vs LBT

Posted by Deshifrator May 23, 2011

Источник: frankdenneman.nl


Конфигурирование виртуального свича (vSwitch) и выбор политики для балансировки нагрузки (load-balancing policy) являются ключевыми моментами при проектировании виртуальной инфраструктуры. Выбор политики балансировки нагрузки может оказать большое влияние на производительность виртуальной машины и может ввести дополнительные требования для физической сети.


Все больше и больше компаний используют IP-hash для балансировки нагрузки. Главный аргумент - это то, что увеличивается пропускная способность и улучшается избыточность. И, даже если в организации активно используется распределенный свич (dvSwitch), большинство организаций по-прежнему использует IP-hash, при этом игнорируя новую политику балансировки нагрузки "Route based on physical NIC load", доступную в распределенных свичах dvSwitch.

Route based on physical NIC Load - это новая политика балансировки нагрузки (load-balancing policy), которая появилась в VMware vSphere 4.1 и доступна только для распределенных коммутаторов dvSwitch. Route based on physical NIC Load, известная также как Load Based Teaming (LBT), принимает во внимание сетевую  нагрузку, создаваемую виртуальной машиной во избежание затора (congestion); пытается  динамически перераспределить и сбалансировать нагрузку путем ремаппинга виртуального порта (virtual switch port) на другую, менее загруженную физическую сетевую карту.

ip-hash-3.png

В статье "IP-HASH VERSUS LBT", представленной в блоге frankdenneman.nl, детально описывается принцип работы IP-hash и LBT (Route based on physical NIC load), их различия, плюсы и минусы. Чуть ниже приведены рекомендации, взятые из выше приведенной статьи (мой свободный перевод):

При использовании на предприятии распределенных коммутаторов (dvSwitch), рекомендуется использовать Load-Based teaming (LBT), а не IP-hash. Для LBT не нужно каким-либо специальным образом конфигурировать физическую сеть, что снижает общий уровень сложности и, плюс к этому, LBT может приспосабливаться к колебаниям нагрузки (чего IP-hash просто не может).


P.S.

Deshifrator Hot Shot

BusyBox: Command Help

Posted by Deshifrator May 23, 2011

Как мы все знаем, в гипервизоре VMware ESXi нет Service Console. Вместо неё у ESXi есть другая, урезанная, консоль на основе BusyBox.

BusyBox is a software application that provides many standard Unix tools, much like the larger (but more capable) GNU Core Utilities. BusyBox is designed to be a small executable for use with the Linux kernel, which makes it ideal for use with embedded devices. (en.wikipedia.org)

Чуть ниже приведены команды (апплеты), которые доступны в оригинальном BusyBox:

[, [[, acpid, addgroup, adduser, adjtimex, ar, arp, arping, ash,
awk, basename, beep, blkid, brctl, bunzip2, bzcat, bzip2, cal, cat,
catv, chat, chattr, chgrp, chmod, chown, chpasswd, chpst, chroot,
chrt, chvt, cksum, clear, cmp, comm, cp, cpio, crond, crontab,
cryptpw, cut, date, dc, dd, deallocvt, delgroup, deluser, depmod,
devmem, df, dhcprelay, diff, dirname, dmesg, dnsd, dnsdomainname,
dos2unix, dpkg, du, dumpkmap, dumpleases, echo, ed, egrep, eject,
env, envdir, envuidgid, expand, expr, fakeidentd, false, fbset,
fbsplash, fdflush, fdformat, fdisk, fgrep, find, findfs, flash_lock,
flash_unlock, fold, free, freeramdisk, fsck, fsck.minix, fsync,
ftpd, ftpget, ftpput, fuser, getopt, getty, grep, gunzip, gzip, hd,
hdparm, head, hexdump, hostid, hostname, httpd, hush, hwclock, id,
ifconfig, ifdown, ifenslave, ifplugd, ifup, inetd, init, inotifyd,
insmod, install, ionice, ip, ipaddr, ipcalc, ipcrm, ipcs, iplink,
iproute, iprule, iptunnel, kbd_mode, kill, killall, killall5, klogd,
last, length, less, linux32, linux64, linuxrc, ln, loadfont,
loadkmap, logger, login, logname, logread, losetup, lpd, lpq, lpr,
ls, lsattr, lsmod, lzmacat, lzop, lzopcat, makemime, man, md5sum,
mdev, mesg, microcom, mkdir, mkdosfs, mkfifo, mkfs.minix, mkfs.vfat,
mknod, mkpasswd, mkswap, mktemp, modprobe, more, mount, mountpoint,
mt, mv, nameif, nc, netstat, nice, nmeter, nohup, nslookup, od,
openvt, passwd, patch, pgrep, pidof, ping, ping6, pipe_progress,
pivot_root, pkill, popmaildir, printenv, printf, ps, pscan, pwd,
raidautorun, rdate, rdev, readlink, readprofile, realpath,
reformime, renice, reset, resize, rm, rmdir, rmmod, route, rpm,
rpm2cpio, rtcwake, run-parts, runlevel, runsv, runsvdir, rx, script,
scriptreplay, sed, sendmail, seq, setarch, setconsole, setfont,
setkeycodes, setlogcons, setsid, setuidgid, sh, sha1sum, sha256sum,
sha512sum, showkey, slattach, sleep, softlimit, sort, split,
start-stop-daemon, stat, strings, stty, su, sulogin, sum, sv,
svlogd, swapoff, swapon, switch_root, sync, sysctl, syslogd, tac,
tail, tar, taskset, tcpsvd, tee, telnet, telnetd, test, tftp, tftpd,
time, timeout, top, touch, tr, traceroute, true, tty, ttysize,
udhcpc, udhcpd, udpsvd, umount, uname, uncompress, unexpand, uniq,
unix2dos, unlzma, unlzop, unzip, uptime, usleep, uudecode, uuencode,
vconfig, vi, vlock, volname, watch, watchdog, wc, wget, which, who,
whoami, xargs, yes, zcat, zcip

Но не все выше приведенные команды (апплеты) будут выполняться в VMware ESXi. Дело в том, что в ESXi присутствует более урезанная версия BusyBox. Ниже приведен список апплетов, которые доступны в ESXi редакции BusyBox:

[, [[, addgroup, adduser, ash, awk, basename, cat, chgrp, chmod,
chown, chroot, chvt, cksum, clear, cp, crond, cut, date, dd, 
delgroup, deluser, df, diff, dirname, du, echo, egrep, eject, env, 
expr, false, fdisk, fgrep, find, ftpget, ftpput, getty, grep, 
groupadd, groupdel, groups, gunzip, gzip, halt, head, hexdump, 
hostname, id, inetd, init, kill, ln, loadkmap, lockfile, logger, 
login, ls, md5sum, mkdir, mkfifo, mknod, mktemp, more, mount, mv, 
nohup, nslookup, od, passwd, poweroff, printf, readlink, reboot, 
reset, resize, rm, rmdir, sed, seq, setsid, sh, sha1sum, sleep, 
sort, stat, stty, su, sum, sync, syslogd, tail, tar, tee, test, 
time, touch, true, umount, uname, uniq, uptime, useradd, userdel,
usermod, usleep, vi, watch, wc, wget, which, whoami, xargs, zcat

Описание выше приведенных команд (всевозможных ключей и аргументов), можно посмотреть на официальном сайте проекта BusyBox в разделе Command Help.



P.S.

При написании данного поста понадобилось мне еще раз взглянуть на то, как организована справка в BusyBox. Для этого я решил выполнить в ESXi первую попавшуюся на глаза команду (из стандартного набора команд, приведенных чуть выше). Этой командой оказалась cksum. Еще раз повторю, что данную команду я выбрал совершенно случайно.

cksum — рассчитывает количество байт и контрольную сумму (CRC) в файле по стандарту ISO/IEC 8802-3:1989. (ru.wikipedia.org)

Так вот, чтобы увидеть справку по данной программе, я по привычке добавил ключ "-h" в конце команды и нажал Enter:

cksum.jpg

И вместо справки я опять получил Segmentation fault. Почему опять, да потому что совсем недавно я уже описывал другую ситуацию, при которой у меня так же выскакивала ошибка сегментации (Segmentation fault).



P.P.S.

    Deshifrator's Blog


    vMind.ru

    vmgu.ru
    vsphere.ru
    yellow-bricks.com
    wiki.vm4.ru
    blog.vadmin.ru
    vmutils.blogspot.com


    VMUG: Russia VMware User Group
    kb.vmware.com

    Источник: yellow-bricks.com


    Появилось новое техническое руководство: VMware ESXi 4.1 Operations Guide

    This paper describes the architecture of VMware ESXi and then explains how various management tasks are performed in it. This information can be used to help plan a migration to the VMware ESXi architecture from the legacy VMware ESX framework and to improve or enhance day-to-day operations.

    Данный документ описывает архитектуру гипервизора VMware ESXi и объясняет, как в нем выполняются различные административные задачи. Эта информация может быть использована как для планирования миграции к архитектуре VMware ESXi от VMware ESX, так и для облегчения (оптимизации) повседневных задач (операций).

    После прочтения двух достаточно интересных статей в блоге Сандро Галдава "V" for Virtualization:

     


    1. Форвардим логи ESXi сервера на Syslog сервер
    2. vMA в роли Syslog сервера для ESX/ESXi хостов


    я решил написать небольшую статью/пост про настройку FreeBSD в качестве централизованного сервера журналирования (syslog сервера) для хостов ESX/ESXi (да и не только). В качестве централизованного сервера журналирования у меня выступает ВМ с установленной на неё операционной системой FreeBSD 8.2 и со стандартным syslog даемоном. В общем, приступаем к настройке.

    Все ниже приведенные действия выполняются непосредственно на syslog сервере, если явно не указано иное.

    Создаем папку, в которой будут лежать логи хостов ESXi:

    # mkdir /var/log/vmlab
    

    Редактируем конфигурационный файл /etc/syslog.conf, добавляя в него необходимые строки:

    # echo '+192.168.33.13' >> /etc/syslog.conf
    # echo '*.* /var/log/vmlab/esxi-01.log' >> /etc/syslog.conf
    

    Для того, чтобы лог файлы в папке vmlab сильно не разрастались, настраиваем их ежедневную ротацию с сохранением семидневного архива. Для этого редактируем файл /etc/newsyslog.conf, добавляя в него стро(ку|ки):

    /var/log/vmlab/esxi-01.log root:wheel 640 7 * @T00 JC
    

    Для применения всех ранее сделанных изменений, необходимо перезапустить службу syslogd и newsyslog. Но перед этим нужно проделать еще одну небольшую, но очень важную настройку. По умолчанию в ОС FreeBSD syslog  даемон запускается с заранее установленным флагом "-s",

    ps-syslog.jpg

    который запрещает серверу принимать сообщения из сети. Чтобы syslog даемон смог принимать сообщения не только от localhost'а, но и с других серверов, редактируем конфигурационный файл /etc/rc.conf, добавляя в него следующую строку:

    # echo 'syslogd_flags=""' >> /etc/rc.conf
    

    Вот сейчас можно перезапустить службы:

    # /etc/rc.d/newsyslog restart
    # /etc/rc.d/syslogd restart
    

    Теперь наш syslog сервер настроен и готов к работе. Осталось только настроить ESXi, чтобы он отправлял логи на централизованный сервер журналирования. Для этого на хосте ESXi из-под пользователя root выполняем следующую команду:

    vim-cmd hostsvc/advopt/update Syslog.Remote.Hostname string 192.168.33.17
    

    После выполнения выше приведенной команды, хост ESXi (с IP адресом 192.168.33.13) будет отправлять свои лог-записи как в файл /var/log/messages, который лежит на локальном жестком диске, так и на централизованный syslog сервер (с IP адресом 192.168.33.17). Сервер, в свою очередь, будет сохранять входящие сообщения от хостов ESXi в определенные файлы, указанные в конфигурационном файле syslog.conf.



    P.S.

    Данная статья является логическим продолжением ранее написанной мною статьи: Xangati for ESX (Часть 1). Напомню, что в первой части моей статьи мы остановились на том, что запустили импортированную из OVF шаблона виртуальную машину.

    В первой части статьи я забыл упомянуть о том, что бесплатная (free) редакция Xangati for ESX позволяет наблюдать только за одним хостом ESX/ESXi, и нет возможности интеграции с VMware vCenter.

    Теперь пора перейти непосредственно к настройке самого Xangati for ESX. Сразу хочу сказать, что настройка достаточно проста и не займет много времени.


    Настройка

    Первым делом нужно перейти в vSphere Client -> Console. Откроется консоль ВМ, где нужно будет ввести логин: xanuser и пароль: use.xangati. После чего, в консоли появится окно, в котором нам предложат принять самоподписной сертификат:

    xangati-configure1.jpg

    Затем появится аутентификационное окно, в котором нужно будет ввести логин: admin и пароль: admin для доступа к Xangati for ESX User Interface (пользовательский интерфейс):

    xangati-configure2.jpg

    После успешной аутентификации нам станет доступна очень урезанная панель управления (если её так можно назвать), в которой можно будет изменить сетевые настройки и подкорректировать системное время (в частности, можно указать внешний ntp сервер):

    xangati-configure3.jpg

    Когда все параметры настроены, нажимаем на кнопку Yes, после чего виртуальная машина будет перезагружена. Как только ВМ загрузится, открываем web браузер и, в его адресной строке, вводим https://192.168.33.18 (в вашем случае ip адрес скорее всего будет другим). Откроется страничка, в которой нужно нажать Login напротив Management Dashboards. В результате этого загрузится и запустится Java приложение, выдав уже знакомое нам окно для ввода логина и пароля (логин и пароль тот же: admin/admin). После успешной аутентификации нам предстоит выполнить еще пару шагов по настройке Xangati. И, первым делом, Wizard предложит нам изменить стандартный пароль на свой, более сложный:

    xangati-configure4.jpg

    Далее нас попросят ввести аутентификационные данные для доступа к хосту ESX/ESXi (так как Xangati я разворачивал в своем тестовом окружении, то я не стал создавать отдельного readonly пользователя на хосте ESXi, поэтому в окне мастера, в качестве Login Name, указываю root):

    xangati-configure5.jpg

    Задаём список наших сетей:

    xangati-configure6.jpg

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

    xangati-configure7.jpg

    Как только мастер завершит процесс настройки, появится основное рабочее окно, в котором мы сможем мониторить ресурсы, которые потребляют виртуальные машины, сетевую активность; создавать и просматривать различные отчеты и ещё много чего:

    dashboard.jpg

    Попользовавшись некоторое время данной программой, я понял, что данный инструмент для меня бесполезен, да и, честно говоря, не особо он и удобный. Интерфейс у него топорный. Мне понравилось только, как организован Dashboard. А все остальное как-то уныло. Но это лично моё мнение. Возможно, кому-то данное приложение придется по вкусу, хотя бы из-за того, что этот инструмент достаточно легко развернуть, плюс у него есть очень замечательная возможность: он умеет записывать состояние счетчиков по типу того, как записывается видео. Можно создавать много таких "видео" записей и, спустя какое время, их просматривать. Ради такой функции стоит хотя бы раз установить и попробовать Xangati for ESX.

    Источник новости: yellow-bricks.com

    Анонс в Exchange Team Blog


    Теперь можно использовать VMware HA и VMware DRS применительно к Microsoft Exchange Server 2010 SP1, что позволяет добиться большей гибкости и надежности. На своём предприятии мы Exchange не используем (у нас exim+dovecot), но для тех предприятий, где используется Exchange, и при этом он виртуализирован, эта новость будет очень полезной.

    Xangati for ESX - это Virtual Appliance, предназначенный для отображения в режиме реального времени активности хоста ESX/ESXi, его виртуальных машин и используемых ими ресурсов. Бесплатная версия - достаточно урезанная. У платной же версии и функционал побогаче, и есть возможность интеграции с VMware vCenter. Более подробную информацию по данному продукту вы можете найти на официальном сайте.


    На официальном сайте вы также можете ознакомиться и с другими достаточно интересными продуктами компании Xangati: Xangati VI Dashboard и Xangati VDI Dashboard.

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

    Для успешной установки Xangati for ESX нам потребуется:


    • ESX/ESXi 3.5, 4.x
    • 512Mhz CPU (1 vCPU)
    • 1GB RAM
    • 20GB Disk (3GB if Thin Provisioning is used)
    • DHCP enabled on the Port Group Xangati will join


    Подготовительные работы

    Чтобы Xangati for ESX смог нормально функционировать, нужно чтобы он "видел" всю сетевую активность на виртуальном свиче. Для этого нам потребуется создать новую группу портов на vSwitch0 с VLAN ID, равным 4095, и с активированным для этой группы портов Promiscuous Mode.

    За дополнительной информацией по Standard vSwitch можете обратится в блог Антона Жбанкова, а именно сюда и сюда. Там про Promiscuous Mode и про VLAN ID 4095 всё очень хорошо написано.

    Также можете прочитать мой пост про Promiscuous Mode, разъясняющий, что это и зачем он нужен.

    На текущий момент сеть в моём тестовом окружении выглядит так:

    current-network.jpg

    Как видно выше, группы портов с VLAN ID, равным 4095 нет. Поэтому создаем её:

    new-pg.jpg

    Далее не забываем активировать Promiscuous Mode для только что созданной группы:

    pmode-en.jpg

    Теперь наша сеть выглядит следующим образом:

    new-network.jpg

    Подготовительные работы сделаны. Необходимая группа портов для нормальной работы Xangati for ESX создана. И вот теперь можно переходить непосредственно к процессу развертывания Xangati for ESX из OVF шаблона.


    Импортируем OVF шаблон

    Для начала скачиваем образ виртуальной машины (Virtual Appliance) в открытом формате OVF (Open Virtualization Format) с официального сайта. Просто так скачать не получится. Для начала нужно будет зарегистрироваться, а уж потом придет письмо на почту с заветной ссылкой. Хочу заметить, что образ ни много, ни мало весит 1.6 гигабайта.

    Open Virtualization Format (OVF) - это открытый стандарт для упаковки и распространения virtual appliances. О том, что такое Virtual Appliances, я писал в начале этой статьи.

    После того, как образ закачан, распаковываем его:

    file-list.jpg

    Далее переходим в vSphere Client -> Deploy OVF Template. Откроется окно, в котором нужно будет указать путь до шаблона:

    deploy-ovf1.jpg

    После того, как мы указали путь до шаблона и нажали Next, появится сводная информация по данному шаблону:

    deploy-ovf2.jpg

    Далее задаем имя, которое в дальнейшем будет присвоено импортируемой виртуальной машине:

    deploy-ovf3.jpg

    Указываем Resource Pool, в котором будет находиться наша виртуальная машина:

    deploy-ovf4.jpg

    Выбираем подходящий datastore:

    deploy-ovf5.jpg

    Выбираем тип виртуального диска - "толстый" или "тонкий":

    deploy-ovf6.jpg

    Здесь мы должны выбрать группу портов на виртуальном свиче, в которую будет входить наша виртуальная машина. Помните о том, что мы специально для Xangati создавали группу портов Xangati-Monitor? Вот её-то здесь и нужно выбрать:

    deploy-ovf7.jpg

    Практически все готово к началу процесса импорта. Wizard напоследок покажет кратенькую суммарную информацию:

    deploy-ovf8.jpg

    и, после нажатия кнопки Finish, запустится процесс импорта ВМ из OVF шаблона:

    deploy-start.jpg

    После того, как процесс импорта виртуальной машины закончится, наша сеть приобретет следующий вид:

    new-network1.jpg

    Теперь осталось только запустить новоиспеченную виртуальную машину и - полдела сделано:

    xangati-start.jpg

    Как выше я уже писал, полдела сделано. Осталось только настроить Xangati for ESX. Но, непосредственно про настройку самого Xangati for ESX, я расскажу во второй части, которая появится чуть позже.



    P.S.

    Deshifrator Hot Shot

    Promiscuous mode

    Posted by Deshifrator May 16, 2011

    Promiscuous Mode ("Неразборчивый" режим) - это режим, при котором сетевой адаптер начинает получать все пакеты независимо от того, кому они адресованы. Если рассматривать promiscuous mode в контексте виртуального свича (vSwitch), а, точнее, группы портов на этом свиче, то данный режим позволит перехватывать все пакеты, проходящие через данную группу портов, любой виртуальной машине, непосредственно присоединенной к ней.


    Зачем нужен Promiscuous Mode?

    Чтобы лучше понять назначение promiscuous mode, приведу практический пример. Допустим, у нас есть четыре виртуальные машины:


    1. FreeBSD - на этой ВМ стоит чистая FreeBSD 8.2
    2. WinXP - MySQL Primary
    3. WinXP-2 - MySQL Secondary
    4. Debian - Внешний веб-сервер


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

    и сеть, которая на данный момент выглядит следующим образом:

    current-network.jpg

    Как видно выше, все четыре ВМ находятся в одной группе портов и прекрасно себе работают. Но в один очень хороший день вы решаете на фактически простаивающей ВМ с чистой ОС FreeBSD установить IDS, так сказать, чтобы спалось спокойно.

    Система Обнаружения Вторжений, соответствующий англоязычный термин Intrusion Detection System (IDS) - программное или аппаратное средство, предназначенное для выявления фактов неавторизованного доступа в компьютерную систему или сеть, либо несанкционированного управления ими, в основном, через Интернет. (взято с сайта wikipedia.org)

    Для нормальной работы IDS в среде VMware vSphere (да и не только) нужно, чтобы на определенной группе портов или на виртуальном свиче был активирован Promiscuous Mode.

    Казалось бы, что проще: нужно всего лишь активировать promiscuous mode для группы портов "VM Network" и установить на FreeBSD какую-нибудь IDS. Но у данного подхода есть очень большой минус - при этом все виртуальные машины, входящие в данную группу портов, смогут перехватывать пакеты, им не адресованные. А это очень большая брешь в безопасности. Тогда как же быть? Как повысить безопасность? Ответить на эти вопросы и решить проблему с безопасностью нам помогут VLAN'ы. Поэтому переконфигурируем нашу сеть, используя для достижения поставленной цели VLAN'ы.


    Настройка

    Первым делом нужно создать две группы портов на vSwitch0 с одним и тем же VLAN ID:

    # esxcfg-vswitch -A VLAN-10-DPM vSwitch0
    # esxcfg-vswitch -A VLAN-10-EPM vSwitch0
    # esxcfg-vswitch -v 10 -p VLAN-10-DPM vSwitch0
    # esxcfg-vswitch -v 10 -p VLAN-10-EPM vSwitch0
    

    Чуть выше мы создали группу портов VLAN-10-DPM (DPM - Disable Promiscuous Mode) и VLAN-10-EPM (EPM - Enable Promiscuous Mode). Чтобы изменения вступили в силу, перезапускаем Management Network (перезапустить можно непосредственно через консоль сервера, либо в окне терминала, выполнив dcui):

    dcui.jpg

    Как только перезапустится Management Network, наша сеть приобретет вот такой вид:

    current-network1.jpg

    Следующим шагом активируем Promiscuous Mode для группы портов VLAN-10-EPM:

    p-mode-en.jpg

    Затем перенастраиваем ВМ FreeBSD на группу портов VLAN-10-EPM, а остальные три виртуальные машины - на группу VLAN-10-DPM.

    Не забывайте про то, что когда вы измените для ВМ группу портов, она сразу же станет недоступна для других (внешних) сетей, если до этого вы НЕ НАСТРОИЛИ физический свич + роутер на корректную обработку VLAN.

    Для этого переходим в настройки ВМ, выбираем Network Adapter и, в Network Label, выбираем VLAN-10-DPM или VLAN-10-EPM:

    settings-vm.jpg

    После всех манипуляций наша сеть будет выглядеть следующим образом:

    current-network2.jpg

    Теперь ВМ с FreeBSD, находясь в группе VLAN-10-EPM, сможет перехватывать и анализировать (если к этому моменту стоит IDS) весь трафик, который проходит внутри группы VLAN-10-DPM. При этом ВМ, входящие в группу VLAN-10-DPM, не смогут перехватывать трафик друг друга.


    Тестирование

    Чтобы убедиться, что все настроено правильно, нужно протестировать. Для этого на ВМ WinXP (IP: 192.168.33.87) пускаем пинг до виртуальной машины WinXP-2 (IP: 192.168.33.28). А на FreeBSD запускаем на выполнение программу tcpdump, которая переведет сетевой интерфейс в promiscuous mode и начнет выводить на экран захваченные пакеты:

    tcpdump.jpg

    Как видно выше, FreeBSD получает пакеты, которые ей не адресованы, то есть promiscuous mode работает. А это значит, что и IDS будет работать так, как положено, анализируя весь трафик, который "бегает" внутри группы VLAN-10-DPM.


    В заключение ко всему выше написанному, хочу добавить, что такое решение (с применением VLAN) потребует донастройки или даже замены (если свич/роутер не поддерживает VLAN) физического свича/роутера, что может вызвать проблемы. Это нужно заранее учитывать перед началом настройки для того, чтобы избежать возможных простоев.



    P.S.

    Если в настройках vSwitch активировать Promiscuous Mode, то он будет активирован для всех групп портов:

    vSwitch.jpg

    Будьте очень внимательны и активируйте promiscuous mode только для тех групп портов, где это действительно необходимо.



    P.P.S




    Месяца полтора назад купил на озоне (www.ozon.ru) данную книжку. И вот только сегодня закончил её читать. Ниже представлено описание данной книги, взятое с задней обложки:


    book-vsphere4.jpg

    Описание

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


    Об авторе

    Скотт Лоу - автор, консультант и блоггер, специализирующийся на вопросах виртуализации, хранения информации и других технологиях корпоративных систем. Являясь одним из ведущих специалистов по вопросам виртуализации в компании ePlus Technology, Скотт занимается планированием, разработкой, внедрением и сопровождением платформы VMware для самых разных компаний. Скотт поддерживает посвященный виртуализации блог blog.scottlowe.org; его статьи опубликованы на сайтах SearchVMware.com и SearchServerVirtualization.com. В 2008 году за вклад в развитие VMware Скотт Лоу получил награду VMware vExpert Award, которой удостоена лишь очень узкая группа специалистов.


    Темы книги:

    • повышение производительности работы всех компонентов пакета VMware vSphere 4
    • установка и настройка VMware ESX Server и VMware ESXi Server, vCenter Server и VMware Update Manager
    • управление виртуальными машинами и сетями, устройствами хранения и доступом пользователей
    • миграция и повышение производительности виртуальных машин в рамках существующей инфраструктуры
    • принципы обеспечения высокой доступности (HA) и непрерывности бизнес-процессов в среде VMware
    • обеспечение безопасности виртуальной инфраструктуры vSphere и мониторинг производительности виртуальных систем
    • устранение последствий неожиданных сбоев в работе физического сервера с помощью VMware Fault Tolerance
    • создание сценариев и автоматизация задач виртуализации с помощью PowerShell и PowerCLI



     

    Моё мнение

    Лично мне эта книга очень понравилась. Много полезных практических советов. Много так необходимой (лично мне) хорошей теории. Книга написана достаточно понятным языком. Единственно, что немного хромает - перевод, но это совсем незначительный минус. Книга однозначно для повседневного использования, то бишь настольная. Поэтому рекомендую её всем. Перед покупкой книги можете заглянуть внутрь её на сайте amazon.com (правда только на английском языке).


    На озоне вместе с книгой "VMware vSphere 4. Полное руководство" купил книгу русского автора Михаила Михеева "Администрирование VMware vSphere 4.1". Должна быть хорошей. Как прочитаю, напишу своё мнение.

    Просматривая блог www.vm4.ru, я наткнулся на интересный пост, где была ссылка на другой пост в блоге blog.aboutnetapp.ru. В общем, автор блога "about NetApp" перевел на наш могучий русский язык "Руководство по наилучшим способам использования систем NetApp с VMware vSphere v4.1". Оригинал на английском здесь.


    vsphere-bp.jpg

    Был сильно впечатлен качеством проделанной работы. Огромное СПАСИБО автору перевода.


    Находясь под впечатлением, решил написать данный пост, тем самым выразив благодарность автору. Ну и, может быть, кто-то еще не читал данный перевод, пропустив новость (как я) в блоге автора перевода или в блоге Михаила Михеева.

    Решил создать незатейливую табличку, в которой будут собраны различные блоги, интересные мне для чтения. Может быть, кому-нибудь еще данная табличка также окажется полезной, как и мне. За этим и опубликовываю.


    Собственно, табличка:

     

    БлогОписание
    www.vm4.ruВиртуализация. VMware vSphere, MS Hyper-V, Xen, etc...
    blog.vadmin.ruЗаписки виртуального админа. Новости, обзоры и заметки о виртуальных машинах и платформах виртуализации.
    yellow-bricks.comYellow Bricks is a personal Blog about virtualization(mostly VMware related) maintained by me, Duncan Epping. The name is derived from an Arctic Monkeys song, Old Yellow Bricks. Yellow Bricks are solid but flexible at the same time because you can build virtually anything. Same goes for virtualization, it provides you with a firm foundation while gaining flexibility at the same time. Yellow Bricks, building blocks for virtualization.
    vm.pro-it.kzТема этого блога - довольно интересная, мощная и перспективная технология виртуализации IT инфраструктуры на решениях и продуктах компании VMware.
    www.vmlab.gevEra of the Virtual Revolution. The blog about virtualization using VMware products.
    www.vforv.me"V" for Virtualization
    www.vmkernel.ruТехнический блог по продуктам VMware. Интересные (и не очень) истории о возникающих проблемах и путях их решения.
    www.ntpro.nlEric Sloof is working in the information technology for over 15 years and has built up a broad experience. Currently he’s active as a VMware Certified Instructor and combines the delivery of VMware Training Courses with consultancy. Besides teaching and consultancy, he’s an active member of the VMware community and VMware has rewarded him with the vExpert title. His website NTPRO.NL is voted as one of the best VMware blogs year after year and ranks high in the top 25.
    www.vmgu.ruВиртуализация vSphere, Hyper-V, XenServer и Red Hat. Более 1450 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat
    www.vmind.ruБлог, посвященный виртуализации. Он будет вам полезен, если вы используете виртуализацию или собираетесь это сделать в будущем. На блоге публикуются новости виртуального мира, а также статьи о виртуализации. Основной упор делается на Xen Server, Vmware VI и Microsoft Hyper-V.
    virtualizationsecuritygroup.ruVirtualization Security Group Russia - некоммерческое объединение российских специалистов, занимающихся вопросами обеспечения информационной безопасности инфраструктур виртуализации. Группа объединяет десятки специалистов из Москвы, Санкт-Петербурга, Красноярска и Тюмени.
    www.vsphere.ruVMware vSphere - виртуализация ЦОД
    www.boche.netJason Boche is an IT industry veteran, a VMware Virtualization Evangelist, and a blogger with nearly 15 years of professional experience. Boche maintains a top-10 VMware blog at boche.net, has twice been awarded VMware vEXPERT, is the Minneapolis Area VMware User Group Leader, is a frequent VMware/VMTN Communities Roundtable podcaster, and is a contributor/moderator at the VMware VMTN Communities as well as the Petri IT Knowledgebase. Boche holds the following technical certifications: VCDX3 (#34), VCDX4, VCAP4-DCA (#14), VCAP4-DCD (#35), VCPx3, MCSEx3, MCSAx2, MCP, CCAx2, A+.
    kendrickcoleman.comA technical blog focused on IT infrastructure written by Kendrick Coleman. I focus on virtualization and the evolution of the cloud, but I also like to dive into other areas of IT. I use this blog for publishing solutions to uncommon problems I find in my day to day duties. If I happen to resolve a problem that google can't find, you can expect me to write a blog post about it.
    www.vladan.frVirtualization News, videos and tutorials
    www.petri.co.ilPetri IT Knowledgebase by Daniel Petri – Microsoft MVP
    virtualinsanity.comA technology blog with a focus on virtualization and cloud computing
    blog.scottlowe.orgThe weblog of an IT pro specializing in virtualization, storage, and servers
    blog.aboutnetapp.ruЭтот сайт является личным блогом независимого специалиста в области сетевых систем хранения данных компании NetApp (ранее Network Appliance).
    vsphere-land.comYour ultimate VMware information destination
    frankdenneman.nlFrankdenneman.nl is the personal blog of Frank Denneman and has a strong focus on resource management of a VMware virtual infrastructure and has recently been voted number 6 worldwide on vSphere-land.com
    hypervizor.comMy name is Hany Michael and I’m a Senior Consultant at VMware. I blog about various topics ranging from the core vSphere technologies all the way to the vCloud based products.
    virtuallyghetto.comvirtuallyGhetto is a personal site primarily focused on VMware automation using the various scripting APIs and SDKs.
    virtualgeek.typepad.comVirtual Geek an insider's perspective, technical tips n' tricks in the era of the VMware Revolution
    deinoscloud.wordpress.comMy Blog Related To The Virtualization and Cloud Computing Era
    thelowercasew.comthelowercasew.com - a site dedicated to virtualization and VMware!  My name is Matt Liebowitz and I'm currently a Solution Architect specializing in virtualization for a consulting firm in New York City.
    virtu-al.netPowerShell и PowerCLI основные темы данного блога.
    vmware.progm.ruПолная информация о виртуализации на базе решений компании VMware.
    v-reality.infoCloud is new virtual reality
    vsential.comVirtualization in the real world
    blog.peacon.co.ukpeacon VIRTUALISATION BLOG BY JAMES PEARCE
    2vcps.com2vcps and a Truck


    Табличка будет постепенно пополнятся по мере того, как я буду находить интересные блоги.


    VMUG: Russia VMware User Group
    Официальный Русскоязычный Форум, где можно почерпнуть много полезной информации


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

    После майских праздников, выйдя на работу, я продолжил ковырять ESXi. И случайно обнаружил (наверное, так оно обычно и бывает), что, если запустить DCUI (Direct Console User Interface) в достаточно маленьком окне терминала,

    dcui-coredump.jpg

    то он тут же вываливается с ошибкой segmentation fault:

    dcui-coredump1.jpg

    При этом в лог-файле /var/log/messages появляются следующие записи:

    dcui-log.jpg

    DCUI ведет себя так, только если окно терминала, в котором он запускается, достаточно маленькое. Если его запустить в окне терминала чуть большего размера, чем показано на скриншоте, то DCUI отработает нормально.


    Честно говоря, достаточно неприятно видеть Segmentation fault в каких-либо компонентах VMware ESXi. Единственно, успокаивает тот факт, что DCUI через ssh официально не поддерживается (или я не прав?). Поэтому, запуская его в окне терминала, мы принимаем на себя все возможные риски от такого "неофициального" использования.



    P.S.

    В блоге на yellow-bricks.com углядел пост о том, что совсем недавно, а именно четвертого мая сего года, был выпущен (обновлен) документ: VMware vSphere 4.1 Networking Performance


     

    Оригинальное описание
    This paper demonstrates that vSphere 4.1 is capable of meeting the performance demands of today's thoughput-intensive networking applications. The paper presents the results of experiments that used standard benchmarks to measure the networking performance of different operating systems in various configurations. These experiments examine the performance of VMs by looking at VMs that are communicating with external hosts and are communicating among each other, demonstrate how varying the number of vCPUs and vNICs per VM influences performance, and show how the scalability results of overcommitting the number of physical cores on a system by adding four 1-vCPU VMs for every core.


    Мой свободный перевод
    Этот документ наглядно демонстрирует, что vSphere 4.1 способен удовлетворить потребности сетевых приложений, которые очень интенсивно используют сеть. В документе представлены результаты экспериментов, полученные с использованием стандартных тестов для измерения производительности сети в разных операционных системах и с различной конфигурацией. Эти эксперименты исследуют (examine) производительность виртуальных машин, наблюдая за тем, как виртуальные машины общаются с внешними хостами и как общаются друг с другом; демонстрируют, как различное число vCPUs и vNICs в ВМ влияет на производительность; показывают, как масштабируются (scalability) результаты при недостаточности (overcommitting) числа физических ядер в системе, добавив четыре однопроцессорных ВМ на одно ядро.


    Заключение (взято из документа)

    Оригинальное заключение
    The results in the previous sections prove that vSphere 4.1 is a high-performance platform with superior networking performance. Two VMs running on the same host can communicate with each other at rates of up to 27Gbps using only one virtual NIC. A single 4-vCPU VM running on vSphere 4.1 can push the limits of commodity x86 hardware (with only enough slots for four 10GbE NICs) by sending data at a rate of 36Gbps. The networking performance of vSphere 4.1 not only scales with increasing vCPUs, but also with increasing number of VMs. Networking performance is so consistent on highly loaded systems that, in most cases, there was no drop in performance observed when the number of VMs per physical CPU were doubled from two to four. vSphere 4.1 is the perfect platform for virtualizing even those applications which place substantial demands on the networking infrastructure.


    Мой свободный перевод
    Результаты, приведенные в предыдущих разделах, доказывают то, что vSphere 4.1 является высокопроизводительной платформой с превосходной сетевой производительностью. Две виртуальные машины, работающие на одном и том же хосте, могут общаться друг с другом на скоростях до 27Gbps, используя при этом только один виртуальный сетевой адаптер. Четырех-процессорная (4-vCPU) виртуальная машина, запущенная на vSphere 4.1, может достичь стандартных пределов x86 оборудования (только с достаточным количеством слотов для четырех 10GbE NICs) на передачу данных со скоростью 36Gbps. Производительность сети на vSphere 4.1 масштабируется (scales) не только с увеличением vCPUs, но и с ростом числа виртуальных машин. В большинстве случаев не наблюдалоcь падение производительности, когда число виртуальных машин на одном физическом процессоре было удвоено с двух до четырех. vSphere 4.1 является идеальной платформой для виртуализации даже для тех приложений, которые очень требовательны к сетевой инфраструктуре.



    P.S.

    • Скачать документ можно здесь
    • Пост на www.yellow-bricks.com
    • Technical Papers на vmware.com
    • В моём переводе возможно есть некоторые неточности. Поэтому буду рад любым Вашим предложениям в части улучшения данного перевода.

    Если свободного места на datastore не хватает, то размер данного datastore можно увеличить путём объединения нескольких дисков или партиций в один логический том (это не относится к NFS хранилищам). Делается это просто. Нужно зайти в свойства datastore, объем которого нужно увеличить. Далее нажимаем на кнопку Increase.

    volume-properties.jpg

    Откроется окно мастера, в котором нам предложат выбрать диск (LUN), который будет использован для увеличения объема datastore:

    select-disk.jpg

    После завершения работы Wizard'а, объем нашего datastore будет увеличен на объем ранее выбранного нами диска (LUN):

    volume-properties1.jpg

    Внимание! Увеличение размера datastore - действие необратимое. Диск, единожды задействованный для увеличения объема какого-либо datastore, больше нигде нельзя будет задействовать. Поэтому будьте внимательны.

    Данная статья является логическим продолжением ранее написанной статьи про iSCSI хранилище на базе FreeBSD. Только на этот раз я расскажу про настройку NFS-сервера под управлением FreeBSD для нужд ESXi.

    Network File System (NFS) - Сетевая Файловая Система, прозрачно предоставляющая доступ к файлам и файловой системе сервера. Существует множество реализаций NFS-серверов и клиентов. В данной статье мы рассмотрим настройку NFS-сервера на базе FreeBSD 8.2 и NFS-клиента на базе ESXi.

    Настраиваем NFS-сервер

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

    Первым делом отредактируем файл /etc/rc.conf, добавив в него строки, запускающие службы, необходимые для функционирования NFS-сервера, во время загрузки системы:
    # echo 'rpcbind_enable="YES"' >> /etc/rc.conf
    # echo 'nfs_server_enable="YES"' >> /etc/rc.conf
    # echo 'mountd_flags="-r"' >> /etc/rc.conf
    
    • nfsd - NFS демон, обслуживающий запросы клиентов
    • mountd - NFS mount daemon выполняет запросы, передаваемые ему от nfsd
    • rpcbind - Данный демон позволяет клиентам определить, какой порт использует сервер


    Далее создаем файл /etc/exports, в котором каждая строка задаёт экспортируемую файловую систему и список хостов (клиентов), имеющих доступ к ней (в нашем случае мы экспортируем только одну ФС):

    # touch /etc/exports
    # chown root:wheel /etc/exports
    # chmod 644 /etc/exports
    # echo '/usr/esxi-datastore  -maproot=root  192.168.33.13' > /etc/exports
    

    Флаг -maproot=root позволяет пользователю root на удаленной системе писать данные на экспортируемую файловую систему, как пользователь root. Если -maproot=root не задан, то, даже если пользователь имеет root доступ на удаленной системе, он не сможет модифицировать файлы на экспортируемой ФС. В нашем случае данный флаг нужно обязательно указать. Иначе ESXi увидит экспортируемую ФС, даже покажет, сколько места свободно и сколько занято, но что-либо создать или изменить на данной ФС не получится.


    Изначально каталога /usr/esxi-datastore не существует, поэтому создаем его:

    # mkdir -p /usr/esxi-datastore
    

    Для применения всех изменений и проверки того, что все стартует нормально при загрузке системы, перезагружаем её:

    # shutdown -r now
    

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

    # sockstat | egrep 'nfs|mount|rpc'
    root     nfsd       658   3  tcp4   *:2049                *:*
    root     nfsd       658   4  tcp6   *:2049                *:*
    root     mountd     656   5  udp6   *:730                 *:*
    root     mountd     656   6  tcp6   *:730                 *:*
    root     mountd     656   7  udp4   *:730                 *:*
    root     mountd     656   8  tcp4   *:730                 *:*
    root     mountd     656   9  dgram  -> /var/run/logpriv
    root     rpcbind    527   4  udp6   *:*                   *:*
    root     rpcbind    527   5  stream /var/run/rpcbind.sock
    root     rpcbind    527   6  udp6   *:111                 *:*
    root     rpcbind    527   7  udp6   *:967                 *:*
    root     rpcbind    527   8  tcp6   *:111                 *:*
    root     rpcbind    527   9  udp4   *:111                 *:*
    root     rpcbind    527   10 udp4   *:833                 *:*
    root     rpcbind    527   11 tcp4   *:111                 *:*
    

    Как видно выше все три демона (rpcbind, nfsd и mountd) запустились. А это значит, что NFS-сервер готов к работе.


    Добавляем NFS хранилище в ESXi

    Добавить NFS хранилище в ESXi достаточно просто. Для этого необходимо выбрать нужный хост ESXi, затем перейти на вкладку Configuration -> Storage -> Add Storage. Появится окно, в котором нужно выбрать тип нового хранилища. Так как нам нужно NFS хранилище, выбираем Network File System:

    storage-type.jpg

    Далее указываем сервер (доменное имя или ip адрес), экспортируемую папку (ФС) и указываем имя, которое будет присвоено новому datastore:

    nfs-folder.jpg

    Перед тем, как добавить NFS хранилище, Wizard покажет суммарную информацию о данном хранилище (если нас все устраивает, нажимаем Finish):

    nfs-finish.jpg

    После того, как мы нажмем Finish, и Wizard завершит свою работу, в списке Datastores появится наше NFS хранилище:

    list-datastores.jpg

    В разделе "Datastore Details" видно, что общий размер хранилища составляет 41.94 GB. При этом свободно 4.22 GB, а занято 37.73 гигабайта. Так откуда же взялись эти цифры? А все очень просто. Это размер раздела, на котором непосредственно располагается ранее созданный нами каталог /usr/esxi-datastore. Точно такие же данные можно получить, выполнив команду df -h в командном интерпретаторе FreeBSD.


    Теперь можно попробовать что-нибудь загрузить в наше NFS хранилище:

    putty-upload.jpg

    putty.jpg

    Файл putty.exe на NFS datastore залился без каких-либо проблем. Во FreeBSD файл putty.exe будет выглядеть так же, как и любой другой обычный файл:

    ls-putty.jpg

    Ну, вроде бы всё написал что хотел. Чуть ниже приведены ссылки как на материалы, которыми я пользовался при написании данной статьи, так и на статьи, которые мне показались интересными, актуальными и нужными. Рекомендую к прочтению.



    P.S.

    Взято с сайта www.scalaxy.ru :

    Скалакси — проект компании Оверсан. Наши основные услуги — хостинг масштабируемых виртуальных машин в облаке и полное сопровождение проектов.

    На их wiki и в блоге на Хабре, опубликовано описание (wiki, хабр) архитектуры Скалакси. Прочитал, показалось интересным, поэтому и публикую.

    Commonscheme.png

    Парочка интересных постов из блога Оверсан на Хабре: