Vswp vmware что это
Vswp vmware что это
Очень сильно вырос объем файла подкачки vswp, как уменьшить? И что за виртуальные диски создались sql-000001.vmdk и sql-000002.vmdk?
Подскажите, что делать с этим? Объем свободного пространства на исходе.
> Очень сильно вырос объем файла подкачки vswp, как уменьшить?
Разбираться с количеством памяти на хосте и в виртуалке, в частности посмотрите в документации на reservation memory и на влияние ее на vswp size
> И что за виртуальные диски создались sql-000001.vmdk и sql-000002.vmdk?
Похоже на снапшоты. Что говорит snapshot manager?
А вообще если это MS SQL оставлять его без выставленного ограничния памяти в настройках не правильно. Память ему идет в прок только до каких то разумных пределов
Вручную вы аккуратно не сделаете (там нужно еще править ссылки в vmdk)
А что мешает посмотерть snapshot manager?
удалил один снапшот в менеджере а в datastore browser ни один не исчез.. Сегодня даже еще один создался sql-000003.vmdk. Он уже весит 3 ГБ.
Можете дать скриншот текущего состояния окна snapshot manager по этой машине, если там что-то есть?
Что у вас с резервным копированием данной ВМ?
Бэкапные снапшоты обычно кривые названия имеют. А эти похожи на ручные.
Быкапы делаю при помощи veeamzip.
Такое (лишние снапшот файлы) бывает, наиболее правильно сделать Delete All из Snapshot Manager и начинать жить с чистого листа
Альтернатива (не рекомендованная) : через консоль пройтись по vmdk файлам описаниям, найти лишние снапшот файлы.
Текущие используемые можно посмотреть так
после delete all все vmdk файлы исчезли. Сейчас на диске свободного места достаточно.
Будет ли дальше расти vswp файл? Где выставить настройки резервации памяти?
Если здесь, то какие значения выставлять?
> Будет ли дальше расти vswp файл?
Зависит от значений Reservation & от того насколько глубоко в swap будет лезть VM. Еще раз напомню, что имеет смысл ограничить использование памяти в самом SQL, если это MSSQL и у него в качестве Maximum server memory (in MB) стоит 2147483647 то рано или поздно SQL начнет использовать swap а hypervisor растить файл vswp. Поэтому если вы хотите макимально уменьшить размер файла vswp нужно выставить в reservation то количество памяти которое вы отдали VM и установить некое разумное значение для Maximum server memory
> Если здесь, то какие значения выставлять?
Высталять здесь, мое мнение по поводу значений выше
NetApp FAS и VMware ESXi: Swap
Начнём с того, что есть два типа свапинга, которые могут происходить на ESXi хосте. Их очень часто путают, поэтому давайте условно будем называть их Тип 1 и Тип 2.
Расположение данных VMware ESXi по умолчанию
Тип 1. VMX swapping (vSwap)
Это самый простой тип свапинга для описания. Память выделяется не только для виртуальных машин, а также и для различных компонент хоста, к примеру, для монитора виртуальных машин (VMM) и виртуальных устройств. Такая память может быть свапирована для того, чтобы выделить более нуждающимся виртуальным машинам больше физической памяти. По словам VMware эта возможность может высвободить от 50MB до 10MB памяти, для каждой виртуальной машины без существенного ухудшения производительности.
Тип 2. Guest OS Swapping
ESXi Host swapping
Такой файл существует только для запущенных виртуальных машин – при запуске гипервизор создаёт этот файл и удаляет при выключении виртуальной машины. Обратите внимание на размер этого файла — он равен разнице между сконфигурированной памятью для виртуальной машины и резервом физической памяти за этой машиной. Таким образом обеспечивается наличие заданного пространства памяти, когда виртуальная машина стартует (не зависимо от того, какая память используется — настоящая физическая или vSwap). Резерв заботится о том, чтобы виртуальная машина получила нужное пространство всегда в физической памяти хоста. А разница между резервом и настроенной памятью виртуальной машины сохраняется в vswp файл.
Ниже пример запуска виртуальной машины с 4GB памяти и резервом 2GB. Помните, что vSwap удаляется после выключения? А если в этот момент датастор хранящий эту виртуальную машину заполнится и останется свободного 1.8GB пространства, что произойдёт?
Что можно с этим сделать? Конечно же можно высвободить пространство на датасторе или расположить vSwap (Тип 1) на другом датасторе. По умолчанию он хранится в папке с виртуальной пашиной. Если это «standalone» хост: Configuration > Software > Virtual Machine Swapfile Location. Расположение vSwap файлов также можно изменить на уровне настроек каждой виртуальной машины. Откройте настройки виртуальной машины и выберите вкладку Options: 
Если этот хост часть кластера, загляните в настройки кластера Store the swapfile in the datastore specified by the host
Далее выберите датастор где будет храниться vSwap (Тип 1).
Зачем располагать свап на отдельный датастор?
Рекомендуемая схема расположения Swap’а для NetApp FAS
Во-первых стоит отметить что общее правило VMware гласит по возможности располагать vSwap (Тип 1) в папке с виртуальной машиной, так как вынесение на отдельный датастор может замедлить vMotion. Но в частном случае VMware + NetApp FAS вступает другая рекомендация. NetApp рекомендует хранить vSwap (Тип 1) на отдельном выделенном, одном для всех виртуальных машин датасторе, так как в этом случае разница при миграции vMotion практически нивелирована. VMware рекомендует, чтобы пространство под vSwap (Тип 1) было больше или равно разнице сконфигурированной и зарезервированной для виртуальной машины памяти. Иначе виртуальные машины могут не стартовать. Пример: у нас есть 5 виртуальных машин с размером памяти 4GB и резервацией для каждой 3GB.
Минимальный размер датастора для vSwap Тип 1:
5VM * (4 GB — 3GB )= 5GB
Если на хосте нет свободных физических 5VM * 3GB = 15 GB памяти, машины могут не стартовать, выводя ошибку:
The host does not have sufficient memory resources to satisfy the reservation
И в то же время будет создан Event log
Во-вторых это производительность – расположив свап на более медленном датасторе, если вы уверены, что свапинга почти никогда не будет. Или если виртуальные машины будут запрашивать больше памяти, чем есть на хосте, и свапинг будет постоянным – на более быстром датасторе.
В-третьих это снепшоты и дедубликация на уровне хранилища. Так как у нетапа снепшоты не влияют на производительность, они являются нормой жизни, выполняются постоянно и являются частью парадигмы резервного копирования NetApp для систем FAS. Свап это абсолютно бесполезная информация при резервном копировании и восстановлении. Если он интенсивно используется, а снепшоты часто снимаются, в снепшотах будет «захвачена» и храниться, все время жизни снепшота, эта бесполезная информация. А так как свап постоянно меняется, а спепшот захватывает только новые изменённые данные, в каждом таком снепшоте будет храниться эти новые изменённые данные из свапа, беспощадно поедая полезное пространство под бесполезные данные на хранилище. Дедублицировать свап нет никакого резона, ведь данные в свапе не нужны при восстановлении и никогда не будут считаны. В этом смысле удобно выносить свапы на отдельный датастор. NetApp рекомендует располагать свап на отдельный датастор с выключенными снепшотами и дедубликацией, так мы можем ещё сильнее уменьшить оверхед в снепшотах и на репликации.
NetApp не рекомендует использовать локальные диски (стр 76-78, DEC11) на хосте, для хранения vSwap (Тип 1) потому, что такая конфигурация имеет негативное влияние на скорость выполнения операции vMotion.
Стоит ли выносить Тип 2 Swap?
Размещение временных данных, таких как Swap и Pagefile.sys на выделенный датастор (создав выделенный виртуальный диск для этой цели) позволяет не дедублицировать и не бэкапировать эти данные также как и vSwap (Тип 1). Очень важно не забыть указать этот диск как Independent, чтобы агент VSC не заставлял FAS снимать снепшоты с раздела хранящего Swap файлы (Тип 2). 
У NetApp нет рекомендаций относительно Swap Тип 2, вынесение этих данных является опциональным дизайном, у которого есть свои плюсы и минусы:
Мы уже не раз затрагивали тему vswp-файлов виртуальных машин (файлы подкачки), которые используются для организации swap-пространства гипервизором VMware ESXi. Эти файлы выполняют роль последнего эшелона среди техник оптимизации памяти в условиях недостатка ресурсов на хосте. Напомним, что в гипервизоре VMware ESXi есть такие техники как Transparent Page Sharing, Memory Ballooning, a также Memory Compression, которые позволяют разбираться с ситуациями нехватки памяти, необходимой виртуальным машинам.
Однако, когда памяти у всех виртуальных машин совсем мало или отдельной ВМ ее требуется больше, чем сконфигурировано, а также происходит постоянное обращение к памяти (особенно, если в гостевых ОС нет VMware Tools), гипервизор начинает использовать vswp-файл подкачки, который по умолчанию находится в папке с виртуальной машиной. Мы уже писали о том, что в целях повышения быстродействия можно положить vswp-файлы виртуальных машин на локальные SSD-хранилища серверов ESXi, а также о том, как удалять мусорные файлы vswp.
Ниже мы приведем 8 фактов о swap-файлах виртуальных машин, которые основаны на вот этой заметке Фрэнка Деннемана:
1. Хранение vswp-файлов на локальных дисках сервера ESXi (в том числе Swap to Host Cache) увеличивает время vMotion. Это очевидно, так как приходится копировать vswp-файл в директорию ВМ (или другую настроенную директорию), чтобы его видел целевой хост.
2. С точки зрения безопасности: vswp-файл не чистится перед созданием. То есть там лежат не нули, а предыдущие данные блоков. Напоминаем, что размер файла подкачки равен размеру сконфигурированной памяти ВМ (если не настроен Reservation). Если же у машины есть Reservation, то размер vswp-файла определяется по формуле:
Configured memory – memory reservation = size swap file
То есть, если в настройках памяти машины ей выделено 4 ГБ, а Reservation настроен в 1 ГБ, то vswp-файл будет составлять 3 ГБ.
3. Как происходит копирование vswp-файла при vMotion? Сначала создается новый vswp-файл на целевом хосте, а потом копируются только swapped out страницы с исходного в целевой vswp-файл.
4. Что происходит при разнице в конфигурации размещения vswp-файлов в кластере и для отдельных хостов? Напомним, что в настройках кластера VMware vSphere есть 2 опции хранения vswp-файлов: в папке с ВМ (по умолчанию) и в директории, которая указана в настройках хоста:
Если на одном хосте настроена отдельная директория для vswp, а на другом нет (то есть используется папка ВМ), то при vMotion такой виртуальной машины vswp-файл будет скопирован (в папку с ВМ), несмотря на то, что целевой хост видит эту директорию на исходном.
5. Обработка файлов подкачки при нехватке места. Если в указанной директории не хватает места для свопа ВМ, то VMkernel пытается создать vswp-файл в папке с ВМ. Если и это не удается, то виртуальная машина не включается с сообщением об ошибке.
6. vswp-файл лучше не помещать на реплицируемое хранилище. Это связано с тем, что используемые страницы памяти, находящиеся в двух синхронизируемых файлах, будут постоянно реплицироваться, что может вызывать снижение производительности репликации, особенно если она синхронная и особенно при vMotion в недефолтной конфигурации (когда происходит активное копирование страниц и их репликация):
Таги: VMware, vSphere, VMachines, Storage, swap, VMFS, Blogs, ESXi
Мусорные vswp-файлы виртуальных машин на хранилищах VMware vSphere.
Эти файлы, понятно дело, надо удалить. Для этого удобнее всего использовать PowerCLI:
Пример вывода мусорных файлов vswp с путями:
Ну а дальше сами знаете, что с ними делать.
Таги: VMware, ESXi, Storage, Обучение, vSphere
При эксплуатации виртуальной инфраструктуры VMware vSphere иногда случается ситуация, когда виртуальную машину нельзя включить из-за того, что ее какой-нибудь из ее файлов оказывается залоченным. Происходит это при разных обстоятельствах: неудачной миграции vMotion / Storage vMotion, сбоях в сети хранения и прочих.
Наиболее распространенная ошибка при этом выглядит так:
Could not power on VM: Lock was not free
Встречаются также такие вариации сообщений и ошибок при попытке включения виртуальной машины, которое зависает на 95%:
Ну а при попытке соединения с консолью ВМ получается вот такое:
Error connecting to
.vmx because the VMX is not started
Поиск залоченного файла ВМ
Хорошо если в сообщении при запуске виртуальной машины вам сообщили, какой именно из ее файлов оказался залоченным (как на картинке выше). Но так бывает не всегда. Нужно открыть лог vmware.log, который расположен в папке с виртуальной машиной, и найти там строчки вроде следующих:
Failed to initialize swap file : Lock was not free
За логом на экране можно следить командой (запустите ее и включайте ВМ):
tail /vmfs/volumes/ / /vmware.log
Проверка залоченности файла ВМ и идентификация владельца лока
После того, как залоченный файл найден, нужно определить его владельца. Сначала попробуем команду touch, которая проверяет, может ли бы обновлен time stamp файла, т.е. можно ли его залочить, или он уже залочен. Выполняем следующую команду:
# touch /vmfs/volumes/ / /
Если файл уже залочен, мы получим вот такое сообщение для него:
cannot touch: Device or resource busy
Дальше выполняем такую команду:
Те, кто хочет дальше изучать вопрос, могут проследовать в KB 10051.
Таги: VMware, vSphere, Troubleshooting, Bugs, ESXi
Файлы снапшотов (snapshots) виртуальных машин VMware vSphere 5 и поддерживаемые операции.
О снапшотах виртуальных машин VMware vSphere мы уже много писали (например, можно пискать по тэгу «Snapshot»). Постараемся в этой заметке просуммировать информацию о том, что из себя представляют файлы снапшотов виртуальных машин vSphere 5 и как они обрабатываются.
Для того, чтобы снять снапшот виртуальной машины (virtual machine snapshot), можно кликнуть на ней правой кнопкой в vSphere Client и выбрать соответствующий пункт «Take Snapshot» из контекстного меню:
Далее появится окно снятия снапшота ВМ:
После создания снапшота заглянем в Datastore Browser на хосте VMware ESXi через vSphere Client:
По умолчанию размер COW-операции составляет 64 КБ, что эквивалентно 128 секторам (подробнее). Но сам снапшот растет блоками данных по 16 МБ. То есть запись 64 КБ данных исходного диска может породить прирост 16 МБ данных в диске снапшота.
По умолчанию снапшоты складываются в папку на VMFS-томе, где лежит виртуальная машина. Но это размещение можно сменить, поменяв рабочую папку (Working Directory) в настройках виртуальной машины через vSphere Client или в vmx-файле, для чего нужно добавить или поменять строчку:
workingDir=»/vmfs/volumes/SnapVolume/Snapshots/»
Кстати, эта же папка задает и размещение файла подкачки ВМ (*.vswp). Если вы его хотите оставить на прежнем месте, нужно добавить строчку:
sched.swap.dir = «/vmfs/volumes/VM-Volume1/MyVM/»
Ну и напоследок, какие операции поддерживаются для виртуальных машин со снапшотами:
Более подробную информацию о снапшотах можно найти в KB 1015180.
Ну и небольшая подборка ссылок по траблшутингу снапшотов в VMware vSphere:
И отдельно выделим вот эту потрясающую библию снапшотов: Troubleshooting Virtual Machine snapshot problems.
Таги: VMware, vSphere, Snapshot, Обучение, ESX, ESXi, VMachines, Troubleshooting
Swap to Host cache (Swap to SSD) в VMware vSphere 5.
Хорошая и развернутая статья о Swap to Host cache в VMware vSphere 5 есть у Duncan’а Epping’а, а здесь мы приведем основные ее выдержки.
Прежде всего, после установки VMware ESXi 5 хост может не увидеть локальные SSD-хранилища как пригодные для хранения кэша виртуальных машин. Для этого есть вот такой хак от Вильяма Лама. Далее мы идем на вкладку Configuration в vSphere Client и выбираем секцию Host Cache Configuration:
Тут мы можем задать объем дискового пространства на локальном томе VMFS, который мы можем использовать для файлов подкачки виртуальных машин, работающих на этом хосте. После включения этой возможности на этом локальном томе VMFS появится куча vswp-файлов, в которые гостевые ОС виртуальных машин этого хоста будут складывать свои свопируемые страницы памяти.
Поскольку эти своп-файлы находятся только на этом хосте, то при миграции vMotion содержимое страниц памяти из этих файлов надо скопировать на другой хост в его Host Cache или в vswp-файл в папке с виртуальной машиной на общем хранилище. Это, само собой, увеличивает время на миграцию vMotion, и это надо учитывать.
Наблюдать за использованием Host Cache можно из VMware vCenter 5 с помощью метрик «Swap in from host cache» и «Swap out to host cache» (а также «rate. «). В результатах вывода консольной утилиты esxtop это метрики LLSWR/s и LLSWW/s.
Что будет когда место на локальном свопе Host Cache закончится? Сервер ESXi начнет копировать страницы в обычный vswp-файл, который находится в папке с виртуальной машиной, что само собой повлияет на производительность. Кстати, размер Host Cache можно изменять при работающем хосте и виртуальных машинах, поэтому лучше увеличивать его вовремя, да и в целом не доводить до большого свопа виртуальных машин (то есть, правильно сайзить хосты по памяти для ВМ). К примеру, Duncan рекомендует 128 ГБ SSD-диски в RAID-1 для 128 ГБ оперативной памяти хоста.
Таги: VMware, vSphere, Storage, ESXi, Performance, Blogs, Enteprise, VMachines
Информация об использовании памяти виртуальными машинами VMware vSphere.
Как обычно, Duncan Epping написал отличный пост об использовании памяти виртуальными машинами на хостах VMware ESX. Постараемся объяснить это на русском языке. Итак, если открыть вкладку Summary в vSphere Client для виртуальной машины, мы увидим вот такую картину:
Здесь есть 2 главных параметра:
Далее мы видим панель Resources, здесь есть такие показатели:
Теперь идем на вкладку «Resource Allocation». Здесь все немного сложнее:
Появляются вот такие показатели:
Для Host Memory (видим, что это 2187 МБ = сконфигурированная память 2048 МБ + Overhead):
А формула такова: Consumed = Private + Overhead Comsumption
Для Guest Memory (2048 МБ сконфигурировано в настройках):
Ну и последняя секция Resource Settings:
Таги: VMware, vSphere, Memory, ESX, vCenter, Performance, Производительность, Blogs
Недавно у известного блоггера Дункана Эппинга спросили вот про такой интересный случай. Пользователь запустил команду esxtop на странице с показателями памяти для виртуальных машин и получил вот такой результат:
Собственно, какова ситуация, если смотреть по счетчикам на картинке:
Статистики виртуальной машины (обведено красным):
Посмотрим на соотношение свободной памяти хоста ESX и размер области, занятой balloon’ом: 1393 МБ и 1307.27 МБ, соответственно. Они приблизительно равны. Это означает, что при сдутии balloon’а гостевая ОС, в которой он был надут, начнет отъедать физическую память хоста ESX (да и еще выгружать своп). Это приведет к тому, что объем доступной памяти хоста ESX упадет и он снова окажется в ситуации, когда необходимо снова надувать balloon.
То есть VMware ESX (и драйвер vmmemctl) не делают резких движений, растут и сдуваются постепенно, делая оглядку на то, какая ситуация может получиться.
Таги: VMware, ESX, Memory, vSphere, VMachines
Как работают Limit, Reservation и Shares для пулов ресурсов в VMware vSphere / ESX.
Большинству пользователей виртуальной инфраструктуры VMware vSphere известны такие параметры как Limit, Reservation и Shares для пулов ресурсов (Resource Pool) в пределах кластеров VMware DRS и отельных хостов ESX. Именно этими тремя параметрами определяется потребление виртуальными машинами оперативной памяти и процессорных ресурсов хоста VMware ESX.
Таги: VMware, vSphere, Resources, ESX, HA, DRS
Зачастую бывает необходимо понять причины, по которым та или иная виртуальная машина на сервере VMware ESX испытывает проблемы производительности (тормозит). Можно воспользоваться встроенными графиками производительности VMware vCenter (вкладка Performance), однако этого может оказаться недостаточно. В консольной ОС VMware ESX (Service Console) есть утилита esxtop, которая позволяет отслеживать все аспекты производительности сервера виртуализации, а для VMware ESXi доступна утилита resxtop, которую можно запустить с помощью VMware vSphere Management Assistant.
Таги: VMware, ESX, esxtop, Performance, Производительность, ESXi, vSphere, resxtop
Калькулятор размера LUN под том VMFS для виртуальных машин VMware vSphere.
Интересный калькулятор дискового пространства LUN под том VMFS для виртуальных машин появился на vsphere-land.com.
Таги: VMware, vSphere, VMFS, VMDK, Storage, ESX
Обзор продукта Veeam Monitor для мониторинга серверов VMware ESX / vSphere.
Компания Veeam Software известна своими продуктами для управления и автоматизации виртуальной инфраструктуры VMware VI / vSphere. Флагманский продукт компании Veeam Backup для резервного копирования инфраструктуры виртуализации VMware vSphere уже завоевал популярность не только на Западе, но и в России (банки, телекоммуникационные компании), а вот про Veeam Monitor я хотел бы сегодня рассказать отдельно, потому как это единственное в своем роде качественное средство централизованного мониторинга хостов VMware ESX.
Таги: VMware, Veeam, Monitor, ESX, vSphere
Что такое Transparent Page Sharing на VMware ESX / ESXi и как он влияет на производительность?
Компания VMware имеет проприетарную технологию Transparent Page Sharing в платформе VMware ESX / ESXi, которая позволяет более эффективно расходовать RAM хоста.
Что такое Transparent Page Sharing у VMware ESX / ESXi? Это механизм поиска одинаковых страниц в оперативной памяти гостевой ОС виртуальной машины, при котором в случае нахождения одинаковых страниц, вместо копии вставляется ссылка на оригинальную страницу памяти. Тем самым сокращается необходимое количество RAM на хосте ESX / ESXi.
Компания VMware говорит о том, что механизм Transparent Page Sharing сокращает требуемое количество памяти на хосте ESX / ESXi на величину от 5 до 30 процентов в зависимости от задачи (чем однотипнее задачи в виртуальных машинах – тем больше одинаковых страниц и больше экономия). По умолчанию Transparent Page Sharing включен на хостах ESX / ESXi.
А теперь о недостатках Transparent Page Sharing.
Таги: VMware, ESX, ESXi