На форуме поделились информацией:
В 3.5u4 вы не можете увеличить VMDK диск, если он больше терабайта размером, через VI Client. Придется пользоваться командной строкой и vmkfstools.
VMware официально признала это багом, ждем исправления.
Показаны сообщения с ярлыком VI. Показать все сообщения
Показаны сообщения с ярлыком VI. Показать все сообщения
среда, 19 августа 2009 г.
пятница, 24 июля 2009 г.
VI3 Free eBook
Mike Laverick (rtfm-ed.co.uk) выложил в открытый доступ книгу по VI3 и пару гайдов.
VI3 eBook
Quick Start Guide to ESX3i
Upgrade Guide to ESX 3.5 and VirtualCenter 2.5
VI3 eBook
Quick Start Guide to ESX3i
Upgrade Guide to ESX 3.5 and VirtualCenter 2.5
понедельник, 25 мая 2009 г.
ESX 4 под ESX 3
Если у вас не хватает железа на то, чтобы посмотреть на ESX4 - рано расстраиваться.
Провел эксперимент - поставил ESXi 4 (GA) в ВМ под ESXi 3 (3.5u4) и наоборот. ВМ с ESXi 4 на тройке моментально завелась. А вот тройка на четверке, хоть и поставилась, но уже полтора часа пытается загрузиться.
Провел эксперимент - поставил ESXi 4 (GA) в ВМ под ESXi 3 (3.5u4) и наоборот. ВМ с ESXi 4 на тройке моментально завелась. А вот тройка на четверке, хоть и поставилась, но уже полтора часа пытается загрузиться.
четверг, 29 января 2009 г.
понедельник, 8 декабря 2008 г.
Почему загрузка процессоров меряется в мегагерцах?
Поспорили тут с товарищем за бутылочкой вина, правомерно ли измерять загрузку процессоров так, как это делается у VMware, в мегагерцах. До полпятого утра спорили :)
Разумеется, сама концепция измерения загрузки ресурсов в мегагерцах прямо скажем, удивительна, но лишь на первый взгляд. И вот почему.
Уточню. Не совсем загрузку процессоров мы меряем.
Предположим, есть кластер из M ESX серверов с разным количеством процессоров, и с разными частотами. На нем работает N >> M виртуальных машин с количеством виртуальных процессоров от 1 до 4. Для простоты, считаем, что процессоры на хостах все одного семейства, отличаются лишь частотами.
Итого, у нас есть некоторые вычислительные ресурсы под хорошо распараллеливающиеся задачи (много виртуальных машин). Как можно оценить общую вычислительную мощность кластера из трех машин физических, причем на одной 4 ядра по 2.33ГГц, на другой 8 по 3.0, а на третьей 16 по 2.66?
В процентах мерять загрузку явно не получится. Просто потому что взяв одну 1vCPU машину с запущенной числогрызкой (например, SETI@Home), обеспечивающей 100% загрузки виртуального процессора мы получим полностью загруженное ядро на одном из физических процессоров. 25%, 12.5% или 6.25% мощности хоста. Но ведь, что самое интересное, при 100% нагрузке на vCPU мы имеем еще и различную производительность, практически полностью зависящую от частоты процессора. Возьмем другой пример, машину с 4 vCPU и средней нагрузкой на vCPU около 20% (в обоих случаях полагаем отсутствие конкурецнии между машинами за ресурсы). Как посчитать, какой процент ресурсов отъедает машина от кластера?
Исходя из предположения о том, что виртуальные машины могут мигрировать по физическим в любом сочетании, остается только одно - брать абстрактную вычислительную мощность кластера. С учетом того, что виртуальные машины отлично параллелятся (причем лучше всего однопроцессорные), а задачи на них непредсказуемы, то остается лишь зависимость производительности от частоты процессора и количества ядер.
Грубо говоря, суммарная мощность = сумме (количество ядер*частоту).
Почему это правомерно? Исходя из архитектуры процессоров x86, у нас есть некоторый поток команд. Причем время исполнения этого потока команд заранее известно - мы точно знаем количество тактов процессора на каждую команду. Чтобы узнать время из количества тактов - ндо знать опять же только частоту процессора.
И что в итоге? В итоге мы получили, что именно в распараллеливаемых задачах общего плана остается единственное средство измерения вычислительной мощности - сумма частот процессоров. Это и есть наш вычислительный ресурс. Несколько парадоксально, конечно. Тем не менее, надо иметь в виду много ограничений и условий.
Итак, перейдем от измерения к управлению. Есть ситуация борьбы за ресурсы - 100% загрузка задачами физического сервера. Как нам делить его процессорное время? И снова можно делить лишь в мегагерцах, ибо в общем случае мы не знаем даже количества процессоров в машине, как и их частоту. А задача стоит именно дать виртуальной машине гарантированную производительность. Итого, мы выставляем резерв (сколько мегагерц, а точнее процессорного времени с учетом частоты процессора и количества ядер, получит виртуальная машина всегда), и дальше выставляем вес машины - какую долю от оставшихся ресурсов (процессорного времени) должна получить машина.
Обращаю ваше внимание, что данное рассуждение не претендует на истину в Высшей инстанции и имеет место быть лишь при определенных условиях и допущениях, основанных на непредсказуемости типа нагрузки.
Разумеется, сама концепция измерения загрузки ресурсов в мегагерцах прямо скажем, удивительна, но лишь на первый взгляд. И вот почему.
Уточню. Не совсем загрузку процессоров мы меряем.
Предположим, есть кластер из M ESX серверов с разным количеством процессоров, и с разными частотами. На нем работает N >> M виртуальных машин с количеством виртуальных процессоров от 1 до 4. Для простоты, считаем, что процессоры на хостах все одного семейства, отличаются лишь частотами.
Итого, у нас есть некоторые вычислительные ресурсы под хорошо распараллеливающиеся задачи (много виртуальных машин). Как можно оценить общую вычислительную мощность кластера из трех машин физических, причем на одной 4 ядра по 2.33ГГц, на другой 8 по 3.0, а на третьей 16 по 2.66?
В процентах мерять загрузку явно не получится. Просто потому что взяв одну 1vCPU машину с запущенной числогрызкой (например, SETI@Home), обеспечивающей 100% загрузки виртуального процессора мы получим полностью загруженное ядро на одном из физических процессоров. 25%, 12.5% или 6.25% мощности хоста. Но ведь, что самое интересное, при 100% нагрузке на vCPU мы имеем еще и различную производительность, практически полностью зависящую от частоты процессора. Возьмем другой пример, машину с 4 vCPU и средней нагрузкой на vCPU около 20% (в обоих случаях полагаем отсутствие конкурецнии между машинами за ресурсы). Как посчитать, какой процент ресурсов отъедает машина от кластера?
Исходя из предположения о том, что виртуальные машины могут мигрировать по физическим в любом сочетании, остается только одно - брать абстрактную вычислительную мощность кластера. С учетом того, что виртуальные машины отлично параллелятся (причем лучше всего однопроцессорные), а задачи на них непредсказуемы, то остается лишь зависимость производительности от частоты процессора и количества ядер.
Грубо говоря, суммарная мощность = сумме (количество ядер*частоту).
Почему это правомерно? Исходя из архитектуры процессоров x86, у нас есть некоторый поток команд. Причем время исполнения этого потока команд заранее известно - мы точно знаем количество тактов процессора на каждую команду. Чтобы узнать время из количества тактов - ндо знать опять же только частоту процессора.
И что в итоге? В итоге мы получили, что именно в распараллеливаемых задачах общего плана остается единственное средство измерения вычислительной мощности - сумма частот процессоров. Это и есть наш вычислительный ресурс. Несколько парадоксально, конечно. Тем не менее, надо иметь в виду много ограничений и условий.
Итак, перейдем от измерения к управлению. Есть ситуация борьбы за ресурсы - 100% загрузка задачами физического сервера. Как нам делить его процессорное время? И снова можно делить лишь в мегагерцах, ибо в общем случае мы не знаем даже количества процессоров в машине, как и их частоту. А задача стоит именно дать виртуальной машине гарантированную производительность. Итого, мы выставляем резерв (сколько мегагерц, а точнее процессорного времени с учетом частоты процессора и количества ядер, получит виртуальная машина всегда), и дальше выставляем вес машины - какую долю от оставшихся ресурсов (процессорного времени) должна получить машина.
Обращаю ваше внимание, что данное рассуждение не претендует на истину в Высшей инстанции и имеет место быть лишь при определенных условиях и допущениях, основанных на непредсказуемости типа нагрузки.
четверг, 11 сентября 2008 г.
Особенности раздачи permission в VMware VI
Ситуация.
Есть два кластера ESX-серверов. Есть человек с правами Virtual Machine Administrator на одном из кластеров. Новые виртуалки создаются от его лица без проблем, а вот клонировать или развернуть из шаблона не получается. При выборе Datastore возникает исключение "No permission".
Решение.
Создается роль "Browse Datastore" и применяется к "Main" БЕЗ наследования (Propagate = off).
Есть два кластера ESX-серверов. Есть человек с правами Virtual Machine Administrator на одном из кластеров. Новые виртуалки создаются от его лица без проблем, а вот клонировать или развернуть из шаблона не получается. При выборе Datastore возникает исключение "No permission".
Решение.
Создается роль "Browse Datastore" и применяется к "Main" БЕЗ наследования (Propagate = off).
понедельник, 11 августа 2008 г.
Oracle VM templates и VMware VI
Oracle выпустила официальные свободно доступные шаблоны виртуальных машин с Oracle DB в формате Oracle VM. Разумеется, как пройти мимо?
Шаблоны эти по сути всего лишь виртуальные диски в формате img (Xen). За 10 минут гугления было найдено руководство по конвертированию виртуальных машин из формата VMware в Oracle VM. Т.е. нам нужно сделать то же самое, только в обратном порядке.
Скачал, распаковал файл .tar.bz2 в .img. Конвертировать диски можно при помощи пакета qemu.
#qemu-img convert -f raw oracle10g_x86.img -O vmdk oracle10g_x86.vmdk
Заливаю свеженький vmdk, который кстати упаковался с 15ГБ raw до всего 4, на datastore. Добавляю в виртуальную машину диск. Ан нет, не добавляется - это ide диск. IDE HDD в под ESX не поддерживаются. Впрочем, как выяснилось, даже IDE->SCSI конверсия (поменять adaptertype) не поможет, внутренняя разбивка диска под lvm с привязкой к разделам hd*. Подключение к Workstation как IDE Тоже не спасло положения, таблица разделов не видна.
Будет время и железо - поставлю Oracle VM, опишу впечатления.
Шаблоны эти по сути всего лишь виртуальные диски в формате img (Xen). За 10 минут гугления было найдено руководство по конвертированию виртуальных машин из формата VMware в Oracle VM. Т.е. нам нужно сделать то же самое, только в обратном порядке.
Скачал, распаковал файл .tar.bz2 в .img. Конвертировать диски можно при помощи пакета qemu.
#qemu-img convert -f raw oracle10g_x86.img -O vmdk oracle10g_x86.vmdk
Заливаю свеженький vmdk, который кстати упаковался с 15ГБ raw до всего 4, на datastore. Добавляю в виртуальную машину диск. Ан нет, не добавляется - это ide диск. IDE HDD в под ESX не поддерживаются. Впрочем, как выяснилось, даже IDE->SCSI конверсия (поменять adaptertype) не поможет, внутренняя разбивка диска под lvm с привязкой к разделам hd*. Подключение к Workstation как IDE Тоже не спасло положения, таблица разделов не видна.
Будет время и железо - поставлю Oracle VM, опишу впечатления.
вторник, 29 июля 2008 г.
VI 3.5u2 & HA
Столкнулся с интересной проблемой.
В HA кластере у меня 2 сервера с 2-мя сетевыми портами и 1 с 4-мя. VI 3.5u1 ругался на сервере с 4-мя, что не хватает избыточности портов сервис-консоли, хотя HA работал. Я добавил еще одну сервис-консоль на другой vSwitch, и все, предупредение исчезло. HA продолжил работу.
После обновления до 3.5u2 HA-агент на сервере с 4-мя портами отказывался работать категорически. После раскопок в логах было выяснено, что этот сервер имеет network that don't exist on cluster members. И указывался порт второй сервис консоли, работавший в сети Service Console 2. Удалил этот порт. HA-агент успешно запустился и никаких предупреждений о недостаточной избыточности сервис-консоли не появилось.
Подписаться на:
Комментарии (Atom)
Сообщения
