Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4340 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: Вышел VMware vCenter Server 6.5 Update 1b

Несколько советов по дедупликации, компрессии и экономии дискового пространства в кластере VMware vSAN.


John Nicholson написал интересный пост с советами по экономии дискового пространства в кластере VMware vSAN, а также некоторыми рекомендациями по использованию техник дедупликации и сжатия данных.

Вот каким моментам следует уделить внимание:

1. Посмотрите на параметр политики хранения object space reservation (OSR) - если он установлен в 0, то виртуальные диски машин будут тонкими. Если же он будет больше 0, то пространство под диски будет резервироваться и vSAN не сможет эффективно использовать дедупликацию, так как будет вынужден поддерживать фиксированные резервы дискового пространства под ВМ.

2. Помните, что параметр резервирования свопа установлен в 100%, но это можно поменять, как мы писали в этой статье. Уменьшение параметра резервирования свопа оправдано, когда вы не собираетесь использовать memory overcommitment (то есть, ресурсов у вас с запасом), а значит виртуальным машинами не потребуется активно сбрасывать страницы в своп в случае недостатка физической памяти.

3. Помните, что отдельно развертываемые виртуальные машины c дисками типа "thick" или "Eager Zero Thick" (например, со старых клиентов vSphere Client или через консоль) могут перекрывать настройку политики OSR. Чтобы пофиксить это, вы можете переприменить политику хранения (storage policy) на эти хранилища. William Lam написал несколько скриптов, которые позволяют найти такие ВМ и накатить политики по-новой.

4. Убедитесь, что данные записываются на capacity tier - только там они будут дедуплицироваться и сжиматься. Если вы развернули всего 3-4 машины, они могут остаться в буффере (write buffer). Механизмы vSAN не тратят ресурсы на дедупликацию и сжатие объектов, которые долго не живут (то есть, находятся в буффере на запись). Например, 10 машин по 8 ГБ диска каждая тоже могут остаться на стейджинге и, пока не переместятся в постоянное хранилище, не будут дедуплицированы.

Вот тут можно посмотреть, как именно отрабатывает дедупликация, и сколько она экономит дискового пространства:

Ну и вот что Джон рекомендует в плане тестирования дедупликации и компрессии:

  • Самый простой способ организовать тестирование - запустить клонирование 200+ виртуальных машин, они сразу пойдут в capacity tier, и механизм дедупликации включится.
  • Надо помнить, что тестирование этих механизмов и реальное их применение дадут разные результаты, так как при тестировании вы последовательно пишете данные на хранилище и избегаете узких мест, связанных с дестэйджингом из кэша во время размеренного использования кластера vSAN в продакшене.
  • Тестирование алгоритма сжатия на данных, которые плохо сжимаются - плохая идея, так как в этом случае vSAN не будет тратить ресурсы на их сжатие, чтобы записать на хранилище. Это позволит быстрее читать их, а экономия с точки зрения диска будет небольшой (к тому же, алгоритм сжатия LZ4 не такой быстрый, как хотелось бы).
  • При резких всплесках объема записываемых данных и IOPS, которые не помещаются в кэш, видно, что механизмы сжатия и дедупликации приостанавливаются и теряют эффективность. Это связано с тем, что vSAN прежде всего должен обеспечить хороший показатель latency (то есть уровня сервиса), а уже во вторую очередь эффективность механизмов дедупликации и компрессии.

Ну и в довершение, интереснейший документ от VMware - "vSAN Space Efficiency Technologies".


Таги: VMware, Storage, vSAN

Переделка "толстых" файлов подкачки виртуальных машин в кластере VMware vSAN на "тонкие".


Некоторые из вас знают, что, начиная с версии vSAN 6.2, стало возможно создание "тонких" (thin) файлов подкачки. В более ранних версиях vSAN было возможно создавать только reserved своп-файлы, что требовало довольно больших объемов дисковой памяти. То есть, если у машины 16 ГБ оперативной памяти, то в два раза больше будет занято и на диске под своп (32 ГБ), так как при FTT=1 (failures to tolerate) дисковые объекты дублируются в рамках кластера.

Поэтому для сред, в которых достаточно памяти у хостов, и отсутствует Memory Overcommitment, сделали параметр в настройках кластера SwapThickProvisionDisabled, позволяющий виртуальным машинам создавать тонкие файлы подкачки.

Чтобы выставить эту настройку, есть специальный скрипт PowerCLI, который применяет ее ко всем хостам ESXi кластера vSAN.

Однако выставить настройку недостаточно - ведь, чтобы файлы подкачки стали тонкими, то есть пересоздались, надо перезагрузить (выключить и включить) виртуальные машины с толстыми swap-файлами. Найти такие машины позволит вот этот Python-сценарий. Ну а дальше уже перезагрузите машины по списку - это позволит вам сэкономить значительный объем дискового пространства кластера.


Таги: VMware, vSAN, Storage, ESXi, VMachines

Резервное копирование виртуальных машин в облако средствами NAKIVO Backup & Replication.


Многие из вас уже знают продукт NAKIVO Backup & Replication, представляющий собой недорогое решение для резервного копирования и репликации виртуальных машин VMware vSphere, Microsoft Hyper-V и Amazon EC2. Недавно мы писали о бета-версии NAKIVO Backup & Replication 7.2, в которой появилось много новых возможностей. Ну а сегодня мы хотим рассказать о функциях для бэкапа виртуальных машин в облако с помощью решения NAKIVO
Таги: NAKIVO, Backup, Cloud, Amazon, Azure

Новое на VMware Labs - утилита DRS Lens для более глубокого понимания механизма балансировки нагрузки.


На сайте проекта VMware Labs появилась очередная заслуживающая внимания утилита DRS Lens, поставляемая в виде виртуального модуля (Virtual Appliance). Она позволяет администраторам виртуальных инфраструктур получить больше информации о работе механизма балансировки нагрузки на хост-серверы VMware vSphere DRS.

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

Summary

Это вкладка с общей информацией. Тут агрегируются данные с других разделов в удобное представление для администратора.

Cluster Balance

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

VM Happiness

На этом дэшборде впервые можно увидеть метрику VM happiness в графическом интерфейсе. Здесь представлена диаграмма, показывающая число ВМ, которые "счастливы" в кластере (то есть работают под нормальной нагрузкой) и число тех, которые "несчастны" (работают в стрессовых условиях при недостатке ресурсов). Пользователь может выбирать отдельные ВМ для просмотра метрик производительности, которые влияют на VM happiness, такие как %CPU ready, memory swapped и т.п.

vMotions

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

Operations

На этом дэшборде можно отслеживать различные операции (задачи на стороне vCenter Server), которые выполнялись с течением времени. Администраторы могут сопоставлять информацию о задачах с этого дэшборда с данными других вкладок.

Все эти вещи позволят более детально ответить на вопрос - а что же именно и когда механизм DRS делает с виртуальными машинами при перемещении между хост-серверами ESXi.

Скачать VMware DRS Lens можно по этой ссылке. После развертывания виртуального модуля утилитой можно пользоваться по следующим адресам:

https://<appliance-ip>/drs/app

http://<appliance-ip>:8080/drs/app


Таги: VMware, Labs, DRS, vSphere, VMachines, Virtual Appliance

VMware vSphere VMkernel Observations (VOBs) - как создавать кастомные алармы для различных событий (alarms).


В VMware vSphere есть механизм для создания и анализа кастомных алармов - VMkernel Observations (VOBs). VOB'ы - это системные события, которые можно использовать для пользовательских алармов в целях отладки различных аспектов виртуальной инфраструктуры (сетевого взаимодействия, кластеров vSAN, производительности и т.п.).

Чтобы добавить такой аларм, нужно знать его уникальный идентификатор (ID), ассоциированный с конкретным типом события. Эти события и их ID можно посмотреть в следующем файле на хосте ESXi:

/usr/lib/vmware/hostd/extensions/hostdiag/locale/en/event.vmsg

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

/var/log/vobd.log

Для того, чтобы создать кастомный аларм на основе VOB, нужно при создании нового аларма выбрать пункт "specific event occuring on this object":

И далее добавить соответствующий идентификатор, например, такой:

esx.problem.vob.vsan.pdl.offline

Событий, для которых можно создать кастомные алармы, очень много. Вот некоторые из них:

VOB ID VOB Description
esx.audit.vsan.clustering.enabled VSAN clustering services have been enabled.
esx.clear.vob.vsan.pdl.online VSAN device has come online.
esx.clear.vsan.clustering.enabled VSAN clustering services have now been enabled.
esx.clear.vsan.vsan.network.available VSAN now has at least one active network configuration.
esx.clear.vsan.vsan.vmknic.ready A previously reported vmknic now has a valid IP.
esx.problem.vob.vsan.lsom.componentthreshold VSAN Node: Near node component count limit.
esx.problem.vob.vsan.lsom.diskerror VSAN device is under permanent error.
esx.problem.vob.vsan.lsom.diskgrouplimit Failed to create a new disk group.
esx.problem.vob.vsan.lsom.disklimit Failed to add disk to disk group.
esx.problem.vob.vsan.pdl.offline VSAN device has gone offline.
esx.problem.vsan.clustering.disabled VSAN clustering services have been disabled.
esx.problem.vsan.lsom.congestionthreshold VSAN device Memory/SSD congestion has changed.
esx.problem.vsan.net.not.ready A vmknic added to VSAN network configuration doesn't have valid IP. Network is not ready.
esx.problem.vsan.net.redundancy.lost VSAN doesn't haven any redundancy in its network configuration.
esx.problem.vsan.net.redundancy.reduced VSAN is operating on reduced network redundancy.
esx.problem.vsan.no.network.connectivity VSAN doesn't have any networking configuration for use.
esx.problem.vsan.vmknic.not.ready A vmknic added to VSAN network configuration doesn't have valid IP. It will not be in use.
ad.event.ImportCertEvent Import certificate success
ad.event.ImportCertFailedEvent Import certificate failure
ad.event.JoinDomainEvent Join domain success
ad.event.JoinDomainFailedEvent Join domain failure
ad.event.LeaveDomainEvent Leave domain success
ad.event.LeaveDomainFailedEvent Leave domain failure
com.vmware.vc.HA.CreateConfigVvolFailedEvent vSphere HA failed to create a configuration vVol for this datastore and so will not be able to protect virtual machines on the datastore until the problem is resolved. Error: {fault}
com.vmware.vc.HA.CreateConfigVvolSucceededEvent vSphere HA successfully created a configuration vVol after the previous failure
com.vmware.vc.HA.DasHostCompleteDatastoreFailureEvent Host complete datastore failure
com.vmware.vc.HA.DasHostCompleteNetworkFailureEvent Host complete network failure
com.vmware.vc.VmCloneFailedInvalidDestinationEvent Cannot complete virtual machine clone.
com.vmware.vc.VmCloneToResourcePoolFailedEvent Cannot complete virtual machine clone.
com.vmware.vc.VmDiskConsolidatedEvent Virtual machine disks consolidation succeeded.
com.vmware.vc.VmDiskConsolidationNeeded Virtual machine disks consolidation needed.
com.vmware.vc.VmDiskConsolidationNoLongerNeeded Virtual machine disks consolidation no longer needed.
com.vmware.vc.VmDiskFailedToConsolidateEvent Virtual machine disks consolidation failed.
com.vmware.vc.datastore.UpdateVmFilesFailedEvent Failed to update VM files
com.vmware.vc.datastore.UpdatedVmFilesEvent Updated VM files
com.vmware.vc.datastore.UpdatingVmFilesEvent Updating VM Files
com.vmware.vc.ft.VmAffectedByDasDisabledEvent Fault Tolerance VM restart disabled
com.vmware.vc.guestOperations.GuestOperation Guest operation
com.vmware.vc.guestOperations.GuestOperationAuthFailure Guest operation authentication failure
com.vmware.vc.host.clear.vFlashResource.inaccessible Host's virtual flash resource is accessible.
com.vmware.vc.host.clear.vFlashResource.reachthreshold Host's virtual flash resource usage dropped below the threshold.
com.vmware.vc.host.problem.vFlashResource.inaccessible Host's virtual flash resource is inaccessible.
com.vmware.vc.host.problem.vFlashResource.reachthreshold Host's virtual flash resource usage exceeds the threshold.
com.vmware.vc.host.vFlash.VFlashResourceCapacityExtendedEvent Virtual flash resource capacity is extended
com.vmware.vc.host.vFlash.VFlashResourceConfiguredEvent Virtual flash resource is configured on the host
com.vmware.vc.host.vFlash.VFlashResourceRemovedEvent Virtual flash resource is removed from the host
com.vmware.vc.host.vFlash.defaultModuleChangedEvent Default virtual flash module is changed to {vFlashModule} on the host
com.vmware.vc.host.vFlash.modulesLoadedEvent Virtual flash modules are loaded or reloaded on the host
com.vmware.vc.npt.VmAdapterEnteredPassthroughEvent Virtual NIC entered passthrough mode
com.vmware.vc.npt.VmAdapterExitedPassthroughEvent Virtual NIC exited passthrough mode
com.vmware.vc.vcp.FtDisabledVmTreatAsNonFtEvent FT Disabled VM protected as non-FT VM
com.vmware.vc.vcp.FtFailoverEvent Failover FT VM due to component failure
com.vmware.vc.vcp.FtFailoverFailedEvent FT VM failover failed
com.vmware.vc.vcp.FtSecondaryRestartEvent Restarting FT secondary due to component failure
com.vmware.vc.vcp.FtSecondaryRestartFailedEvent FT secondary VM restart failed
com.vmware.vc.vcp.NeedSecondaryFtVmTreatAsNonFtEvent Need secondary VM protected as non-FT VM
com.vmware.vc.vcp.TestEndEvent VM Component Protection test ends
com.vmware.vc.vcp.TestStartEvent VM Component Protection test starts
com.vmware.vc.vcp.VcpNoActionEvent No action on VM
com.vmware.vc.vcp.VmDatastoreFailedEvent Virtual machine lost datastore access
com.vmware.vc.vcp.VmNetworkFailedEvent Virtual machine lost VM network accessibility
com.vmware.vc.vcp.VmPowerOffHangEvent VM power off hang
com.vmware.vc.vcp.VmRestartEvent Restarting VM due to component failure
com.vmware.vc.vcp.VmRestartFailedEvent Virtual machine affected by component failure failed to restart
com.vmware.vc.vcp.VmWaitForCandidateHostEvent No candidate host to restart
com.vmware.vc.vm.VmStateFailedToRevertToSnapshot Failed to revert the virtual machine state to a snapshot
com.vmware.vc.vm.VmStateRevertedToSnapshot The virtual machine state has been reverted to a snapshot
com.vmware.vc.vmam.AppMonitoringNotSupported Application Monitoring Is Not Supported
com.vmware.vc.vmam.VmAppHealthMonitoringStateChangedEvent vSphere HA detected application heartbeat status change
com.vmware.vc.vmam.VmAppHealthStateChangedEvent vSphere HA detected application state change
com.vmware.vc.vmam.VmDasAppHeartbeatFailedEvent vSphere HA detected application heartbeat failure
esx.audit.agent.hostd.started VMware Host Agent started
esx.audit.agent.hostd.stopped VMware Host Agent stopped
esx.audit.dcui.defaults.factoryrestore Restoring factory defaults through DCUI.
esx.audit.dcui.disabled The DCUI has been disabled.
esx.audit.dcui.enabled The DCUI has been enabled.
esx.audit.dcui.host.reboot Rebooting host through DCUI.
esx.audit.dcui.host.shutdown Shutting down host through DCUI.
esx.audit.dcui.hostagents.restart Restarting host agents through DCUI.
esx.audit.dcui.login.failed Login authentication on DCUI failed
esx.audit.dcui.login.passwd.changed DCUI login password changed.
esx.audit.dcui.network.factoryrestore Factory network settings restored through DCUI.
esx.audit.dcui.network.restart Restarting network through DCUI.
esx.audit.esxcli.host.poweroff Powering off host through esxcli
esx.audit.esxcli.host.reboot Rebooting host through esxcli
esx.audit.esximage.hostacceptance.changed Host acceptance level changed
esx.audit.esximage.install.novalidation Attempting to install an image profile with validation disabled.
esx.audit.esximage.install.securityalert SECURITY ALERT: Installing image profile.
esx.audit.esximage.profile.install.successful Successfully installed image profile.
esx.audit.esximage.profile.update.successful Successfully updated host to new image profile.
esx.audit.esximage.vib.install.successful Successfully installed VIBs.
esx.audit.esximage.vib.remove.successful Successfully removed VIBs
esx.audit.host.boot Host has booted.
esx.audit.host.maxRegisteredVMsExceeded The number of virtual machines registered on the host exceeded limit.
esx.audit.host.stop.reboot Host is rebooting.
esx.audit.host.stop.shutdown Host is shutting down.
esx.audit.lockdownmode.disabled Administrator access to the host has been enabled.
esx.audit.lockdownmode.enabled Administrator access to the host has been disabled.
esx.audit.maintenancemode.canceled The host has canceled entering maintenance mode.
esx.audit.maintenancemode.entered The host has entered maintenance mode.
esx.audit.maintenancemode.entering The host has begun entering maintenance mode.
esx.audit.maintenancemode.exited The host has exited maintenance mode.
esx.audit.net.firewall.config.changed Firewall configuration has changed.
esx.audit.net.firewall.disabled Firewall has been disabled.
esx.audit.net.firewall.enabled Firewall has been enabled for port.
esx.audit.net.firewall.port.hooked Port is now protected by Firewall.
esx.audit.net.firewall.port.removed Port is no longer protected with Firewall.
esx.audit.net.lacp.disable LACP disabled
esx.audit.net.lacp.enable LACP eabled
esx.audit.net.lacp.uplink.connected uplink is connected
esx.audit.shell.disabled The ESXi command line shell has been disabled.
esx.audit.shell.enabled The ESXi command line shell has been enabled.
esx.audit.ssh.disabled SSH access has been disabled.
esx.audit.ssh.enabled SSH access has been enabled.
esx.audit.usb.config.changed USB configuration has changed.
esx.audit.uw.secpolicy.alldomains.level.changed Enforcement level changed for all security domains.
esx.audit.uw.secpolicy.domain.level.changed Enforcement level changed for security domain.
esx.audit.vmfs.lvm.device.discovered LVM device discovered.
esx.audit.vmfs.volume.mounted File system mounted.
esx.audit.vmfs.volume.umounted LVM volume un-mounted.
esx.clear.coredump.configured A vmkcore disk partition is available and/or a network coredump server has been configured.  Host core dumps will be saved.
esx.clear.coredump.configured2 At least one coredump target has been configured. Host core dumps will be saved.
esx.clear.net.connectivity.restored Restored network connectivity to portgroups
esx.clear.net.dvport.connectivity.restored Restored Network Connectivity to DVPorts
esx.clear.net.dvport.redundancy.restored Restored Network Redundancy to DVPorts
esx.clear.net.lacp.lag.transition.up lag transition up
esx.clear.net.lacp.uplink.transition.up uplink transition up
esx.clear.net.lacp.uplink.unblocked uplink is unblocked
esx.clear.net.redundancy.restored Restored uplink redundancy to portgroups
esx.clear.net.vmnic.linkstate.up Link state up
esx.clear.scsi.device.io.latency.improved Scsi Device I/O Latency has improved
esx.clear.scsi.device.state.on Device has been turned on administratively.
esx.clear.scsi.device.state.permanentloss.deviceonline Device that was permanently inaccessible is now online.
esx.clear.storage.apd.exit Exited the All Paths Down state
esx.clear.storage.connectivity.restored Restored connectivity to storage device
esx.clear.storage.redundancy.restored Restored path redundancy to storage device
esx.problem.3rdParty.error A 3rd party component on ESXi has reported an error.
esx.problem.3rdParty.information A 3rd party component on ESXi has reported an informational event.
esx.problem.3rdParty.warning A 3rd party component on ESXi has reported a warning.
esx.problem.apei.bert.memory.error.corrected A corrected memory error occurred
esx.problem.apei.bert.memory.error.fatal A fatal memory error occurred
esx.problem.apei.bert.memory.error.recoverable A recoverable memory error occurred
esx.problem.apei.bert.pcie.error.corrected A corrected PCIe error occurred
esx.problem.apei.bert.pcie.error.fatal A fatal PCIe error occurred
esx.problem.apei.bert.pcie.error.recoverable A recoverable PCIe error occurred
esx.problem.application.core.dumped An application running on ESXi host has crashed and a core file was created.
esx.problem.boot.filesystem.down Lost connectivity to the device backing the boot filesystem
esx.problem.coredump.capacity.insufficient The storage capacity of the coredump targets is insufficient to capture a complete coredump.
esx.problem.coredump.unconfigured No vmkcore disk partition is available and no network coredump server has been configured.  Host core dumps cannot be saved.
esx.problem.coredump.unconfigured2 No coredump target has been configured. Host core dumps cannot be saved.
esx.problem.cpu.amd.mce.dram.disabled DRAM ECC not enabled. Please enable it in BIOS.
esx.problem.cpu.intel.ioapic.listing.error Not all IO-APICs are listed in the DMAR. Not enabling interrupt remapping on this platform.
esx.problem.cpu.mce.invalid MCE monitoring will be disabled as an unsupported CPU was detected. Please consult the ESX HCL for information on supported hardware.
esx.problem.cpu.smp.ht.invalid Disabling HyperThreading due to invalid configuration: Number of threads: {1} Number of PCPUs: {2}.
esx.problem.cpu.smp.ht.numpcpus.max Found {1} PCPUs but only using {2} of them due to specified limit.
esx.problem.cpu.smp.ht.partner.missing Disabling HyperThreading due to invalid configuration: HT partner {1} is missing from PCPU {2}.
esx.problem.dhclient.lease.none Unable to obtain a DHCP lease.
esx.problem.dhclient.lease.offered.noexpiry No expiry time on offered DHCP lease.
esx.problem.esximage.install.error Could not install image profile.
esx.problem.esximage.install.invalidhardware Host doesn't meet image profile hardware requirements.
esx.problem.esximage.install.stage.error Could not stage image profile.
esx.problem.hardware.acpi.interrupt.routing.device.invalid Skipping interrupt routing entry with bad device number: {1}. This is a BIOS bug.
esx.problem.hardware.acpi.interrupt.routing.pin.invalid Skipping interrupt routing entry with bad device pin: {1}. This is a BIOS bug.
esx.problem.hardware.ioapic.missing IOAPIC Num {1} is missing. Please check BIOS settings to enable this IOAPIC.
esx.problem.host.coredump An unread host kernel core dump has been found.
esx.problem.hostd.core.dumped Hostd crashed and a core file was created.
esx.problem.iorm.badversion Storage I/O Control version mismatch
esx.problem.iorm.nonviworkload Unmanaged workload detected on SIOC-enabled datastore
esx.problem.migrate.vmotion.default.heap.create.failed Failed to create default migration heap
esx.problem.migrate.vmotion.server.pending.cnx.listen.socket.shutdown Error with migration listen socket
esx.problem.net.connectivity.lost Lost Network Connectivity
esx.problem.net.dvport.connectivity.lost Lost Network Connectivity to DVPorts
esx.problem.net.dvport.redundancy.degraded Network Redundancy Degraded on DVPorts
esx.problem.net.dvport.redundancy.lost Lost Network Redundancy on DVPorts
esx.problem.net.e1000.tso6.notsupported No IPv6 TSO support
esx.problem.net.fence.port.badfenceid Invalid fenceId configuration on dvPort
esx.problem.net.fence.resource.limited Maximum number of fence networks or ports
esx.problem.net.fence.switch.unavailable Switch fence property is not set
esx.problem.net.firewall.config.failed Firewall configuration operation failed. The changes were not applied.
esx.problem.net.firewall.port.hookfailed Adding port to Firewall failed.
esx.problem.net.gateway.set.failed Failed to set gateway
esx.problem.net.heap.belowthreshold Network memory pool threshold
esx.problem.net.lacp.lag.transition.down lag transition down
esx.problem.net.lacp.peer.noresponse No peer response
esx.problem.net.lacp.policy.incompatible Current teaming policy is incompatible
esx.problem.net.lacp.policy.linkstatus Current teaming policy is incompatible
esx.problem.net.lacp.uplink.blocked uplink is blocked
esx.problem.net.lacp.uplink.disconnected uplink is disconnected
esx.problem.net.lacp.uplink.fail.duplex uplink duplex mode is different
esx.problem.net.lacp.uplink.fail.speed uplink speed is different
esx.problem.net.lacp.uplink.inactive All uplinks must be active
esx.problem.net.lacp.uplink.transition.down uplink transition down
esx.problem.net.migrate.bindtovmk Invalid vmknic specified in /Migrate/Vmknic
esx.problem.net.migrate.unsupported.latency Unsupported vMotion network latency detected
esx.problem.net.portset.port.full Failed to apply for free ports
esx.problem.net.portset.port.vlan.invalidid Vlan ID of the port is invalid
esx.problem.net.proxyswitch.port.unavailable Virtual NIC connection to switch failed
esx.problem.net.redundancy.degraded Network Redundancy Degraded
esx.problem.net.redundancy.lost Lost Network Redundancy
esx.problem.net.uplink.mtu.failed Failed to set MTU on an uplink
esx.problem.net.vmknic.ip.duplicate A duplicate IP address was detected on a vmknic interface
esx.problem.net.vmnic.linkstate.down Link state down
esx.problem.net.vmnic.linkstate.flapping Link state unstable
esx.problem.net.vmnic.watchdog.reset Nic Watchdog Reset
esx.problem.ntpd.clock.correction.error NTP daemon stopped.  Time correction out of bounds.
esx.problem.pageretire.platform.retire.request Memory page retirement requested by platform firmware.
esx.problem.pageretire.selectedmpnthreshold.host.exceeded Number of host physical memory pages selected for retirement exceeds threshold.
esx.problem.scratch.partition.size.small Size of scratch partition is too small.
esx.problem.scratch.partition.unconfigured No scratch partition has been configured.
esx.problem.scsi.apd.event.descriptor.alloc.failed No memory to allocate APD Event
esx.problem.scsi.device.close.failed Scsi Device close failed.
esx.problem.scsi.device.detach.failed Device detach failed
esx.problem.scsi.device.filter.attach.failed Failed to attach filter to device.
esx.problem.scsi.device.io.bad.plugin.type Plugin trying to issue command to device does not have a valid storage plugin type.
esx.problem.scsi.device.io.inquiry.failed Failed to obtain INQUIRY data from the device
esx.problem.scsi.device.io.invalid.disk.qfull.value Scsi device queue parameters incorrectly set.
esx.problem.scsi.device.io.latency.high Scsi Device I/O Latency going high
esx.problem.scsi.device.io.qerr.change.config QErr cannot be changed on device. Please change it manually on the device if possible.
esx.problem.scsi.device.io.qerr.changed Scsi Device QErr setting changed
esx.problem.scsi.device.is.local.failed Plugin's isLocal entry point failed
esx.problem.scsi.device.is.pseudo.failed Plugin's isPseudo entry point failed
esx.problem.scsi.device.is.ssd.failed Plugin's isSSD entry point failed
esx.problem.scsi.device.limitreached Maximum number of storage devices
esx.problem.scsi.device.state.off Device has been turned off administratively.
esx.problem.scsi.device.state.permanentloss Device has been removed or is permanently inaccessible.
esx.problem.scsi.device.state.permanentloss.noopens Permanently inaccessible device has no more opens.
esx.problem.scsi.device.state.permanentloss.pluggedback Device has been plugged back in after being marked permanently inaccessible.
esx.problem.scsi.device.state.permanentloss.withreservationheld Device has been removed or is permanently inaccessible.
esx.problem.scsi.device.thinprov.atquota Thin Provisioned Device Nearing Capacity
esx.problem.scsi.scsipath.badpath.unreachpe vVol PE path going out of vVol-incapable adapter
esx.problem.scsi.scsipath.badpath.unsafepe Cannot safely determine vVol PE
esx.problem.scsi.scsipath.limitreached Maximum number of storage paths
esx.problem.scsi.unsupported.plugin.type Storage plugin of unsupported type tried to register.
esx.problem.storage.apd.start All paths are down
esx.problem.storage.apd.timeout All Paths Down timed out, I/Os will be fast failed
esx.problem.storage.connectivity.devicepor Frequent PowerOn Reset Unit Attention of Storage Path
esx.problem.storage.connectivity.lost Lost Storage Connectivity
esx.problem.storage.connectivity.pathpor Frequent PowerOn Reset Unit Attention of Storage Path
esx.problem.storage.connectivity.pathstatechanges Frequent State Changes of Storage Path
esx.problem.storage.iscsi.discovery.connect.error iSCSI discovery target login connection problem
esx.problem.storage.iscsi.discovery.login.error iSCSI Discovery target login error
esx.problem.storage.iscsi.isns.discovery.error iSCSI iSns Discovery error
esx.problem.storage.iscsi.target.connect.error iSCSI Target login connection problem
esx.problem.storage.iscsi.target.login.error iSCSI Target login error
esx.problem.storage.iscsi.target.permanently.lost iSCSI target permanently removed
esx.problem.storage.redundancy.degraded Degraded Storage Path Redundancy
esx.problem.storage.redundancy.lost Lost Storage Path Redundancy
esx.problem.syslog.config System logging is not configured.
esx.problem.syslog.nonpersistent System logs are stored on non-persistent storage.
esx.problem.vfat.filesystem.full.other A VFAT filesystem is full.
esx.problem.vfat.filesystem.full.scratch A VFAT filesystem, being used as the host's scratch partition, is full.
esx.problem.visorfs.failure An operation on the root filesystem has failed.
esx.problem.visorfs.inodetable.full The root filesystem's file table is full.
esx.problem.visorfs.ramdisk.full A ramdisk is full.
esx.problem.visorfs.ramdisk.inodetable.full A ramdisk's file table is full.
esx.problem.vm.kill.unexpected.fault.failure A VM could not fault in the a page. The VM is terminated as further progress is impossible.
esx.problem.vm.kill.unexpected.forcefulPageRetire A VM did not respond to swap actions and is forcefully powered off to prevent system instability.
esx.problem.vm.kill.unexpected.noSwapResponse A VM did not respond to swap actions and is forcefully powered off to prevent system instability.
esx.problem.vm.kill.unexpected.vmtrack A VM is allocating too many pages while system is critically low in free memory. It is forcefully terminated to prevent system instability.
esx.problem.vmfs.ats.support.lost Device Backing VMFS has lost ATS Support
esx.problem.vmfs.error.volume.is.locked VMFS Locked By Remote Host
esx.problem.vmfs.extent.offline Device backing an extent of a file system is offline.
esx.problem.vmfs.extent.online Device backing an extent of a file system came online
esx.problem.vmfs.heartbeat.recovered VMFS Volume Connectivity Restored
esx.problem.vmfs.heartbeat.timedout VMFS Volume Connectivity Degraded
esx.problem.vmfs.heartbeat.unrecoverable VMFS Volume Connectivity Lost
esx.problem.vmfs.journal.createfailed No Space To Create VMFS Journal
esx.problem.vmfs.lock.corruptondisk VMFS Lock Corruption Detected
esx.problem.vmfs.lock.corruptondisk.v2 VMFS Lock Corruption Detected
esx.problem.vmfs.nfs.mount.connect.failed Unable to connect to NFS server
esx.problem.vmfs.nfs.mount.limit.exceeded NFS has reached the maximum number of supported volumes
esx.problem.vmfs.nfs.server.disconnect Lost connection to NFS server
esx.problem.vmfs.nfs.server.restored Restored connection to NFS server
esx.problem.vmfs.resource.corruptondisk VMFS Resource Corruption Detected
esx.problem.vmsyslogd.remote.failure Remote logging host has become unreachable.
esx.problem.vmsyslogd.storage.failure Logging to storage has failed.
esx.problem.vmsyslogd.storage.logdir.invalid The configured log directory cannot be used.  The default directory will be used instead.
esx.problem.vmsyslogd.unexpected Log daemon has failed for an unexpected reason.
esx.problem.vpxa.core.dumped Vpxa crashed and a core file was created.
hbr.primary.AppQuiescedDeltaCompletedEvent Application consistent delta completed.
hbr.primary.ConnectionRestoredToHbrServerEvent Connection to VR Server restored.
hbr.primary.DeltaAbortedEvent Delta aborted.
hbr.primary.DeltaCompletedEvent Delta completed.
hbr.primary.DeltaStartedEvent Delta started.
hbr.primary.FSQuiescedDeltaCompletedEvent File system consistent delta completed.
hbr.primary.FSQuiescedSnapshot Application quiescing failed during replication.
hbr.primary.FailedToStartDeltaEvent Failed to start delta.
hbr.primary.FailedToStartSyncEvent Failed to start full sync.
hbr.primary.HostLicenseFailedEvent vSphere Replication is not licensed replication is disabled.
hbr.primary.InvalidDiskReplicationConfigurationEvent Disk replication configuration is invalid.
hbr.primary.InvalidVmReplicationConfigurationEvent Virtual machine replication configuration is invalid.
hbr.primary.NoConnectionToHbrServerEvent No connection to VR Server.
hbr.primary.NoProgressWithHbrServerEvent VR Server error: {reason.@enum.hbr.primary.ReasonForNoServerProgress}
hbr.primary.QuiesceNotSupported Quiescing is not supported for this virtual machine.
hbr.primary.SyncCompletedEvent Full sync completed.
hbr.primary.SyncStartedEvent Full sync started.
hbr.primary.SystemPausedReplication System has paused replication.
hbr.primary.UnquiescedDeltaCompletedEvent Delta completed.
hbr.primary.UnquiescedSnapshot Unable to quiesce the guest.
hbr.primary.VmLicenseFailedEvent vSphere Replication is not licensed replication is disabled.
hbr.primary.VmReplicationConfigurationChangedEvent Replication configuration changed.
vim.event.LicenseDowngradedEvent License downgrade
vim.event.SystemSwapInaccessible System swap inaccessible
vim.event.UnsupportedHardwareVersionEvent This virtual machine uses hardware version {version} which is no longer supported. Upgrade is recommended.
vprob.net.connectivity.lost Lost Network Connectivity
vprob.net.e1000.tso6.notsupported No IPv6 TSO support
vprob.net.migrate.bindtovmk Invalid vmknic specified in /Migrate/Vmknic
vprob.net.proxyswitch.port.unavailable Virtual NIC connection to switch failed
vprob.net.redundancy.degraded Network Redundancy Degraded
vprob.net.redundancy.lost Lost Network Redundancy
vprob.scsi.device.thinprov.atquota Thin Provisioned Device Nearing Capacity
vprob.storage.connectivity.lost Lost Storage Connectivity
vprob.storage.redundancy.degraded Degraded Storage Path Redundancy
vprob.storage.redundancy.lost Lost Storage Path Redundancy
vprob.vmfs.error.volume.is.locked VMFS Locked By Remote Host
vprob.vmfs.extent.offline Device backing an extent of a file system is offline.
vprob.vmfs.extent.online Device backing an extent of a file system is online.
vprob.vmfs.heartbeat.recovered VMFS Volume Connectivity Restored
vprob.vmfs.heartbeat.timedout VMFS Volume Connectivity Degraded
vprob.vmfs.heartbeat.unrecoverable VMFS Volume Connectivity Lost
vprob.vmfs.journal.createfailed No Space To Create VMFS Journal
vprob.vmfs.lock.corruptondisk VMFS Lock Corruption Detected
vprob.vmfs.nfs.server.disconnect Lost connection to NFS server
vprob.vmfs.nfs.server.restored Restored connection to NFS server
vprob.vmfs.resource.corruptondisk VMFS Resource Corruption Detected

Ну а вот так вот будет выглядеть сработавший кастомный аларм в интерфейсе VMware vSphere Web Client:


Таги: VMware, vSphere, Troubleshooting, ESXi

Вышел VMware vSAN 6.6 - что нового? Да много всего!


Осенью прошлого года компания VMware на конференции VMworld Europe 2016 представила новую версию продукта VMware Virtual SAN 6.5, которая была приведена в соответствие с версией vSphere 6.5. На днях, спустя полгода после этого релиза, была представлена обновленная версия этого продукта для создания кластеров хранилищ - VMware vSAN 6.6 (обратите внимание, что он теперь называется не Virtual SAN, а vSAN).

Несмотря на малое продвижение версии, в VMware vSAN 6.6 появилось весьма много новых возможностей:

1. Шифрование.

В vSAN 6.6 появился механизм DARE – Data At Rest Encryption. Несмотря на то, что для ВМ на платформе vSphere 6.5 есть собственное шифрование, ранее для такого сценария не были доступны дедупликация и компрессия. Теперь за счет того, что шифрование vSAN работает на более позднем уровне - эти механизмы экономии дискового пространства теперь поддерживаются.

Кроме того, эта возможность использует механизм AESNI (Advanced Encryption Standard Native Instruction), который есть во всех современных процессорах, что увеличивает производительность. Также появились новые healthchecks касающиеся того, что сервер KMS доступен (не забудьте обеспечить его резервирование), а также хосты поддерживают AESNI.

2. Механизм локальной защиты для растянутых кластеров (vSAN Stretched Clusters).

Теперь средствами политик можно определить уровень защиты как на уровне локального сайта, так и на уровне межсайтового кластера. Для этого теперь есть 2 политики: Primary level of failures to tolerate (PFTT) и Secondary level of failures to tolerate (SFTT). Для растянутого кластера PFTT определяет защиту между площадками, реализуемую по схеме RAID-1. А политика SFTT для растянутого кластера определяет защиту на уровне локального сайта, которая может быть реализована по схеме RAID-1, RAID-5 или RAID-6.

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

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

3. Возможность Site Affinity для растянутых кластеров.

Теперь машину можно привязать к определенной площадке для растянутого кластера, но только в том случае, если у нее установлено Primary level of failures to tolerate в значение 0 (то есть она не защищена на уровне кластера vSAN, а администратор сам заботится о средствах ее защиты).

4. Режим Unicast Mode.

Теперь вместо мультикаста используется юникаст для коммуникации между узлами кластера. Как только вы обновите все хосты кластера vSAN да версии 6.6 - он сам переключится на режим Unicast:

Вот этой командой можно проверить режим Ubnicast на узлах кластера:

[root@esxi-dell-j:~] esxcli vsan cluster unicastagent list
NodeUuid IsWitness Supports Unicast IP Address Port Iface Name
------------------------------------ --------- ---------------- ------------ ----- ----------
58d29c9e-e01d-eeea-ac6b-246e962f4ab0 0 true 172.4.0.121 12321
58d8ef12-bda6-e864-9400-246e962c23f0 0 true 172.3.0.123 12321
58d8ef61-a37d-4590-db1d-246e962f4978 0 true 172.3.0.124 12321
00000000-0000-0000-0000-000000000000 1 true 147.80.0.222 12321
[root@esxi-dell-j:~]

5. Больше информации об объектах в интерфейсе.

Если раньше можно было просматривать только объекты VMDK и VM Home, то теперь добавился Swap и объекты дельта-дисков ВМ для снапшотов (см., например, диск с именем Hard disk 9 -vcsa-06.rainpole.com_8.vmdk):

6. Возможности Smart Rebuilds.

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

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

Также при высоком заполнении дискового пространства (более 80%) дисковые объекты могут разбиваться на более мелкие чанки, чтобы можно было отбалансировать распределение этих кусочков по хостам кластера в целях более эффективного использования дискового пространства.

7. Механизм Partial Repairs.

В прошлых релизах vSAN, если все компоненты объекта не могли быть восстановлены в результате сбоя, то vSAN не начинал процедуру восстановления (Repair). Теперь же процедура восстановления начнется, даже если компоненты объекта доступны лишь частично - это позволяет частично защититься от дальнейших сбоев в кластере, так как часть восстановленных компонентов будет снова задублирована.

8. Функция Resync Throttling.

Это давно ожидаемая фича - она позволяет задать ширину канала для ресинхронизации в Mbps:

Кроме того, был улучшен сам механизм ресинхронизации - раньше он мог начинаться сначала, если был прерван до завершения. Теперь же он всегда продолжается с последнего прерванного момента.

9. Новые пречеки для режима обслуживания.

Теперь перед переводом кластера в режим обслуживания vSAN делает предпроверки на доступную емкость, чтобы не попасть в ситуацию нарушения политик на время обслуживания:

10. Новые пречеки для удаления дисковых групп и дисков.

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

Такая же штука доступна для отдельных дисков. Это можно оказаться очень полезным при апгрейде хранилищ на хостах ESXi:

11. Новый помощник установки и развертывания.

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

А для проверки конфигурации кластера vSAN появилась утилита "Configuration Assist", которая позволяет убедиться, что все настроено правильно:

12. Средства для проактивного предупреждения ошибок.

Теперь за счет механизма CEIP (Customer Experience Improvement Program) информация о кластере vSAN посылается в VMware, облачные системы которой могут выдавать предварительные предупреждения о возможных проблемах в инфраструктуре хранилищ и рекомендации по их настройке.

13. Интеграция с HTML5 Host Client.

Теперь для кластера vSAN появилась интеграция с клиентом для управления серверами ESXi, где можно, среди прочего, посмотреть состояние различных компонентов узла vSAN:

Также, например, можно прямо из клиента HTML5 управлять средствами дедупликации vSAN.

14. Новые команды ESXCLI.

Были добавлены следующие пространства команд для управления кластером vSAN и его новыми фичами:

  • esxcli vsan debug
  • esxcli vsan health cluster
  • esxcli vsan resync bandwidth
  • esxcli vsan resync throttle

15. Возможность заменить компонент Witness прямо из GUI.

Теперь в интерфейсе для этого появилась специальная кнопка:

Скачать VMware vSAN 6.6 можно по этой ссылке.


Таги: VMware, vSAN, Update

Вышел VMware vCenter Server 6.5b - новый vSphere Client.


Компания VMware выпустила обновление сервера управления виртуальной инфраструктурой - VMware vCenter Server 6.5b. Новых возможностей там три:

  • Последние обновления по временным зонам (time zones) при кастомизации гостевых операционных систем Linux и Windows.
  • Обновленный пакет Oracle (Sun) JRE package версии 1.8.0_12 с поддержкой турецкой временной зоны.
  • Значительно обновленный VMware vSphere Client (бывший HTML5 Client).

Последний пункт как раз и заслуживает внимания. В состав vCenter Server 6.5b вошел vSphere Client версии 6.5 (Build 5178943). Судя по версии билда - это нечто среднее между vSphere Client 3.7 (Build 5168275) и vSphere Client 3.8 (Build 5204615), которые доступны на сайте проекта VMware Labs. То есть, это практически самый свежий клиент.

Тем не менее, у vSphere Client 6.5 на сегодняшний день отсутствует следующая функциональность (подробнее тут):

Функциональная область Рабочий процесс / возможность Не поддерживается в vSphere Client
Cluster Configuration
  • DRS/HA virtual machine overrides
  • Proactive HA
Cluster Datastore
  • Configure SDRS rules and VM overrides
Cluster Monitor
  • Overview performance charts

Content Library

Deploy from template

  • Advanced deploy options
  • Advanced networking template customization

Datastore

Management

  • Datastore default policy read-only view
  • Create NFS 4.1 with Kerberos authentication
  • Create VVOL datastore wizard
  • VVOL datastore default profiles
  • VVOL capability profiles capacity summary portlet
  • Mount and unmount existing VVOL datastore to hosts
  • Register virtual machine
  • Copy, move, rename, and inflate datastore files
  • Change datastore default policy
  • Datastore protocol endpoints
  • Datastore selector advanced mode
  • Datastore capability sets
Distributed Switch Management
  • Add and manage hosts
  • Create new distributed switch
  • Remove distributed switch
  • Manage port groups for batch operations
  • Edit distributed port settings
  • Advanced features: NIOC, NetFlow, port mirror, traffic filtering, LACP, private VLAN
  • Import and export distributed switch and distributed port group
  • Manage physical network adapters for distributed switch

Fault Tolerance

Displays and Operations

  • Fault tolerance operations
  • Fault tolerance summary portlet
  • Migrate secondary workflow
Host Management Host Configuration
  • ESXi two-factor authentication
  • Configure host profiles
Host Management Network Configuration
  • Health checks
  • Edit TCP/IP stacks
  • Migrate VMs to another network

Host Management

Settings

  • Host VVOL protocol endpoints

Host Management

Storage Devices

  • Erase partition
  • Turn locator LED on and off
  • Mark and unmark flash disk

Host Management

Storage Policy

  • Global view
  • Summary view
  • Monitor view
  • Manage view
  • Related items view
  • VM storage policy assignments read-only view
  • Create and edit storage policy wizard
  • Integrate storage policies in deploy OVF wizard
  • Storage policy delete, check compliance, and reapply
  • Reset VSAN default policy
  • Delete storage policy component

Host Storage

iSCSI

  • Hardware iSCSI to IPv6 support
  • Edit advanced options

Host Storage

Management
  • Edit host cache configuration
  • Protocol endpoint properties, paths, and datastores
  • I/O filters

Host Storage

Virtual Flash

  • Resource management
  • Host swap cache configuration
  • Add virtual flash resource capacity
Performance Charts Advanced
  • Select full range of metrics in advanced performance charts
Performance Charts Overview
  • View overview performance charts
  • Select full range of metrics in advanced performance charts
Platform 508 Compliance
  • Initial support

Platform

Actions

  • Action button bar

Platform

Advanced search

  • Search for VMs by compliance status
Platform Docking
  • Drag and drop, close, and restore panes

Platform

Inventory Tree

  • Drag and drop
  • Inline rename
  • Aggregated nodes

Platform

Live Refresh

  • Object navigator live refresh
  • Related lists live refresh
Platform Object Selector
  • Show recent objects

Platform

Portlets

  • Close portlets
Platform Recent Objects View
  • View recent object pane
Platform Related Items Lists
  • Action button bar
  • Filter list
  • Quick filter lists

Platform

Selection Widget

  • Search
Platform Wizards
  • TIWO (Things I am Working On) wizard
  • Sticked workflows (wizard over wizard)

vApp

 

  • All edit and display settings
  • All workflows

VCHA

Management and Deployment

  • All workflows

VM Administration

Compliance

  • Check VM compliance
  • SPBM compliance column in VM list

VM Administration

Deployment

  • Deploy VM from content library wizard

VM Administration

Global Permissions

  • Read only view of global permissions details
  • Create permission
  • Edit existing role of a permission
  • Right click on object to add permission

VM Administration

Profiles

  • Manage VM profiles (including RGs)
  • Batch manage VM profiles

VM Administration

Single Sign-on

  • SSO users and groups
  • SSO configuration

VM Administration

Storage Policies

  • Reapply storage policies for out-of-date VMs
  • Storage policy components view
  • Create and edit storage policy component dialog
  • Delete storage policy component

VM Administration

Summary

  • VM compliance summary portlet

VM Configuration

VM Edit Settings

  • Device configuration options
  • Adding the hardware devices: exist hard disk, RDM disk, floppy drive, serial port, parallel port, host USB device, USB controller, SCSi device, PCI device, SATA controller
  • SDRS rules
  • vApp options
  • Boot options power management
  • Edit advanced settings
  • Remote console options
  • Fibre channel NPIV

VM Configuration

VM Summary

  • Advanced configuration portlet
  • Virtual machine storage policies portlet
  • vApp details portlet
  • Update manager compliance portlet
  • Video card details in hardware portlet

VM Crypt

All

  • All workflows

VM Customization

Image Customization

  • All workflows

VM Deployment

Deploy OVF/OVA

  • Advanced storage
  • Advanced networking
  • Customize template

VM Lists

VMs

  • VM list on vApp
  • Sorting and filtering by column

VM Migration

Drag & Drop

  • Tree to list
  • To and from datastore and datastore cluster
  • To and from standard network, opaque network, or distributed port group

VM Migration

Migrate VM

  • Migration of compute and storage
  • Migration to another VMware vCenter cluster
  • Migration of multiple virtual machines at once

VM Migration

Move To

  • All workflows

VM Operations

Remote Console

  • Changing preferred console from the gear icon

VM Provisioning

New VM

  • Missing devices for hardware customization

VM Provisioning

Register VM

  • UI validations
  • Customize text on page when registering VM template

VM Snapshot

Snapshot Operations

Скачать VMware vCenter Server 6.5b можно по этой ссылке, а Release Notes доступны тут.

Кроме того были выпущены обновления следующих продуктов:

  • VMware Fusion 8.5.5
  • VMware Workstation 12.5.4 для Linux и Windows

Таги: VMware, vCenter, Update, vSphere, Client

Готовый виртуальный модуль VMware ESXi 6.5 Virtual Appliance для тестирования и обучения.


Мы уже немало писали о платформе виртуализации VMware vSphere 6.5, которая стала доступна для загрузки недавно. Оказывается известный блоггер Вильям Лам регулярно создает и поддерживает готовый виртуальный модуль на базе ESXi, а недавно он обновил его до последней версии платформы - VMware ESXi 6.5 Virtual Appliance.

Этот виртуальный модуль в формате OVA создан для того, чтобы развернуть хост-серверы ESXi в виде виртуальных машин на платформе vSphere в целях обучения и тестирования. Помните, что VMware не поддерживает вложенную (nested) виртуализацию в производственной среде.

Вот конфигурация виртуального модуля:

  • GuestType: ESXi 6.5[новое]
  • Virtual Hardware 11 [новое]
  • 2 vCPU
  • 6 GB памяти
  • 2 x VMXNET vNIC
  • 1 x PVSCSI Adapter [новое]
  • 1 x 2GB HDD (под установку самого ESXi)
  • 1 x 4GB SSD (для использования с vSAN, по умолчанию пустой)
  • 1 x 8GB SSD (для использования с vSAN, по умолчанию пустой)
  • Добавлены параметр VHV (подробнее)
  • Добавлены параметры dvFilter Mac Learn в VMX-файл (подробнее)
  • Добавлены параметр disk.enableUUID в VMX-файл
  • VSAN-трафик тэгируется на интерфейсе vmk0
  • Отключенный VSAN device monitoring для целей тестирования (подробнее)
  • При создании нового тома VMFS будет использоваться новая версия VMFS 6 [новое]
  • Включенный sparse swap (подробнее) [новое]

Для запуска виртуального ESXi 6.5 вам потребуется как минимум VMware vSphere 6.0 Update 2. Кстати, а вот какие улучшения появились для виртуального ESXi, которые можно опробовать в версии 6.5:

  • Поддержка Paravirtual SCSI (PVSCSI)
  • GuestOS Customization
  • Поддержка ESXi 6.5 со стороны vSphere 6.0 Update 2
  • Поддержка Virtual NVMe

Скачать виртуальный модуль VMware ESXi 6.5 Virtual Appliance можно по этой ссылке.


Таги: VMware, vSphere, Nested, Blogs, ESXi, VMachines, Virtual Appliance

Размеры разделов и дисков VMDK в VMware vCenter Server Appliance (vCSA) и способ их увеличения.


Как мы уже писали, в новой версии VMware vSphere 6.5 компания VMware существенно улучшила функции виртуального модуля VMware vCenter Server Appliance (vCSA). В частности, в него был добавлен VMware Update Manager (VUM), который по традиции также идет отдельным разделом и диском VMDK, как и остальные сервисы. Расскажем ниже об увеличении раздела диска vCSA, которое описано в статье Вильяма Лама.

Давайте взглянем на таблицу разделов vCSA 6.5, каждому из которых соответствует диск VMDK, в сравнении с vSphere 6.0:

Disk 6.0 Size 6.5 Size Назначение Mount Point
VMDK1 12GB 12GB / and Boot  / and Boot
VMDK2 1.2GB 1.8GB Temp Mount /tmp
VMDK3 25GB 25GB Swap SWAP
VMDK4 25GB 25GB Core  /storage/core
VMDK5 10GB 10GB Log  /storage/log
VMDK6 10GB 10GB DB  /storage/db
VMDK7 5GB 15GB DBLog  /storage/dblog
VMDK8 10GB 10GB SEAT (Stats Events and Tasks)  /storage/seat
VMDK9 1GB 1GB Net Dumper  /storage/netdump
VMDK10 10GB 10GB Auto Deploy  /storage/autodeploy
VMDK11 N/A (Previously InvSrvc 5GB) 10GB Image Builder /storage/imagebuilder
VMDK12 N/A 100GB Update Manager  /storage/updatemgr

Как мы видим, кое-где изменились размеры стандартных разделов, для Image Builder поменялась точка монтирования, а также добавился отдельный раздел VUM на 100 гигабайт, которого не было раньше.

Размер каждого из разделов можно менять на горячую в настройках ВМ, ну а потом нужно из гостевой ОС vCSA расширить раздел на образовавшееся свободное пространство диска. Вот какие изменения произошли в версии vSphere 6.5 на эту тему:

  • Теперь вместо команды vpxd_servicecfg для расширения логического тома нужно использовать следующий скрипт:
    /usr/lib/applmgmt/support/scripts/autogrow.sh
  • Помимо расширения раздела из SSH, это можно сделать через интерфейс Virtual Appliance Management Interface (VAMI) REST API, который можно вызвать удаленно методом POST /appliance/system/storage/resize.

Посмотрим на расширение раздела с Net Dumper (VMDK9) с помощью нового VAMI API.

Выполним команду df -h, чтобы вывести таблицу разделов на vCSA:

Теперь в vSphere Client идем в настройки виртуальной машины vCSA и переходим в раздел управления дисками, где увеличиваем размер девятого виртуального диска с 1 ГБ до 5 ГБ:

Затем идем в браузере по адресу https://[VCSA-HOSTNAME]/apiexplorer, где выбираем пункт "appliance" в разделе Select API и нажимаем кнопку Login, после чего вводим логин/пароль от vCenter Server:

Скроллим до операции POST /appliance/system/storage/resize и раскрываем ее, чтобы увидеть детали:

Теперь нажимаем кнопку "Try it out!" и, в случае успешного выполнения, код ответа (Response Code) будет 200. Также эту же операцию можно выполнить и через PowerCLI:

Connect-CisServer -Server 192.168.1.150 -User administrator@vghetto.local -Password VMware1!
$diskResize = Get-CisService -Name 'com.vmware.appliance.system.storage'
$diskResize.resize()

В итоге, результат будет виден в выводе команды df: раздел, как и виртуальный диск VMDK, увеличился до 5 ГБ:


Таги: VMware, vCSA, VAMI, VMDK, Storage, vCenter, Обучение, Blogs

Возможность Sparse Swap в VMware Virtual SAN 6.2 - как сэкономить кучу байтов


Среди возможностей решения для создания отказоустойчивых хранилищ VMware Virtual SAN 6.2 мы забыли упомянуть о нововведении в части обработки файлов подкачки - Sparse Swap.

Как вы знаете при создании виртуальной машины в обычной инфраструктуре под нее резервируется файл *.vswp, который равен по размеру объему сконфигурированной оперативной памяти виртуальной машины (либо объему незарезервированной памяти, то есть разнице между сконфигурированной и зарезервированной памятью, если она указана в настройке reservation). Это нужно на случай, когда машине не хватает свободной физической памяти (в ситуации, если уже не спасают техники memory overcommit), и она начинает сбрасывать страницы памяти в своп-файл на диске.

То есть, если вы создали ВМ с оперативной памятью 4 ГБ, то столько же займет и файл подкачки для этой ВМ. А теперь посмотрим на инфраструктуру Virtual SAN: если у вас задан параметр FTT=1, то каждый дисковый объект (в том числе и файл *.vswp) будет задублирован (если у вас mirror-конфигурация).

Теперь посчитаем, сколько места съест своп 100 виртуальных машин, у каждой из которых 4 ГБ оперативной памяти и которые размещены в кластере VMware Virtual SAN с FTT=1 в зеркальной конфигурации:

100 ВМ * 4 ГБ * 2 (FTT равен 1) = 800 ГБ

Да, именно так - почти терабайт только под своп. Кому-то это покажется расточительством, поэтому в Virtual SAN сделали такую штуку, как Sparse Swap. Эта функция позволяет создавать файлы подкачки vswp как тонкие, то есть растущие по мере наполнения данными, диски.

Для того, чтобы включить опцию Sparse Swap, нужно выполнить следующую команду на хосте VMware ESXi:

esxcfg-advcfg -s 1 /VSAN/SwapThickProvisionDisabled

Ну а вот тут вы можете найти PowerCLI-скрипт для автоматизации применения этой настройки и отката назад.


Таги: VMware, vSphere, Virtual SAN, VSAN, Storage, VMachines

Что будет, если изменять Memory Reservation работающей виртуальной машины?


Как вы знаете, после запуска виртуальной машины на платформе VMware vSphere, в папке с машиной создается файл *.vswp, который предназначен для свопирования памяти ВМ в критической ситуации. Если у машины проявляется нехватка памяти на хосте VMware ESXi, и она не получает ее через механизм Memory Ballooning, то страницы памяти начинают сбрасываться в этот vswp-файл. Это самая плохая ситуация, так как структурная организация этого файла и то, как понимает своп операционная система, две большие разницы, а значит скорость работы существенно замедляется не только из-за того, что работа идет с диском вместо RAM, но еще и уходит время на поиск нужных страниц.

Соответственно, если у машины 4 ГБ оперативной памяти, то размер vswp-файла также 4 ГБ:

Если мы меняем Memory Reservation для виртуальной машины, то ее файл подкачки уменьшается на величину этого резерва - так как физическая память закрепляется за машиной и не возникнет условий, когда эту часть потребуется свопировать.

Но если сделать Memory Reservation для работающей ВМ (в данном случае 2 ГБ), то размер файла подкачки останется прежним:

Для того, чтобы vswp-файл уменьшился на величину Memory Reservation, надо перезагрузить ВМ - тогда он станет размером 2 ГБ:

Напомним, что у выключенной машины vswp-файла нет.

Но что если у включенной машины убрать (или изменить) Memory Reservation? Все просто - он автоматически увеличится до размера незарезервированной памяти ВМ. Убираем резерв в 2 ГБ и файл вырастает до 4 ГБ:

Ну и напомним формулу:

Swap (.vswp) file size = VM Configured Memory – VM reserved memory


Таги: VMware, vSphere, Memory, VMachines, Blogs

Небольшой гайд по использованию VMware Virtual Flash в vSphere 5.5.


Некоторое время назад мы писали о технологии VMware vFlash (она же Virtual Flash), которая позволяет использовать высокопроизводительные накопители SSD (вот тут - о производительности) для решения двух важных задач:

  • Предоставление виртуальным машинам дополнительного места, в которое будут свопиться страницы памяти в случае недостатка ресурсов на хосте (это намного более производительно, чем свопить на обычный HDD-диск). Эта техника называется Virtual Flash Host Swap и пришла на смену механизму Swap to SSD.
  • Прозрачное встраивание в поток ввода-вывода на хосте между виртуальными машинами и хранилищами, что позволяет существенно ускорить операции чтения данных виртуальных дисков. Называется это VMware Flash Read Cache (vFRC).

Ниже мы вкратце расскажем о настройке этих двух механизмов через VMware vSphere Web Client (в обычном C#-клиенте этого, к сожалению, нет). Если что, более подробно о технике vFRC можно почитать по этой ссылке.

Итак, в vSphere Web Client переходим на вкладку "Manage" для нужного хоста, далее в разделе "Settings" выбираем пункт "Virtual Flash Resource Management". Это кэш, который мы добавляем для того, чтобы в случае нехватки места, его могли использовать виртуальные машины, чтобы не свопить данные на медленный магнитный диск, кроме того он же будет использоваться для целей vFRC.

Нажимаем Add Capacity:

Выбираем диски, которые мы будем использовать как Host Swap и нажимаем "Ок" (все данные на них будут стерты):

Всего под нужды Virtual Flash может быть выделено до 8 дисков суммарной емкостью до 32 ТБ. Видим, что ресурс добавлен как Virtual Flash Resource (его емкость отдельно учитывается для vFRC и Host Cache):

Настройка Virtual Flash Host Swap

Первым делом рекомендуется настроить именно этот кэш, а остаток уже распределять по виртуальным машинам для vFRC.

Выбираем пункт "Virtual Flash Host Swap Cache Configuration" в левом меню, а далее в правой части мы нажимаем кнопку "Edit":

Указываем необходимый объем, который планируется использовать, и нажимаем "Ок":

После того, как мы настроили нужное значение - в случае недостатка ресурсов на хосте виртуальные машины будут использовать высокоскоростные диски SDD для своих нужд внутри гостевой ОС (файлы подкачки прочее).

Настройка VMware Flash Read Cache (vFRC)

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

Сам кэш vFRC можно настроить на уровне отдельных виртуальных машин на хосте VMware ESXi, а также на уровне отдельных виртуальных дисков VMDK.

Чтобы выставить использование нужного объема vFRC для отдельной виртуальной машины, нужно выбрать пункт "Edit Settings" из контекстного меню ВМ и на вкладке "Virtual Hardware" в разделе "Virtual Flash Read Cache" установить нужное значение для соответствующего виртуального диска:

Если этого пункта у вас нет, то значит у вас версия виртуального "железа" (Virtual Machine Hardware) ниже, чем 10, и ее нужно обновить.

По ссылке "Advanced" можно настроить размер блока для кэша (значение Reservation, установленное тут, обновит значение на предыдущем скрине):

Чтобы понять, какие значения SSD-кэша можно и нужно выставлять для виртуальных машин, рекомендуется почитать документ "Performance of vSphere Flash Read Cache in VMware vSphere 5.5".

 


Таги: VMware, Cache, vFRC, vSphere, Performance, VMachines, Storage, SSD

Самообслуживание с помощью Cisco UCS Director: как дать пользователям возможность самостоятельно создавать виртуальные сервера.


В этом посте специалисты компани ИТ-ГРАД расскажут о решении Cisco UCS Director и покажут как сделать так, чтобы конечные пользователи могли самостоятельно сформировать запрос на портале самообслуживания Cisco UCS Director и автоматически получить готовую виртуальную машину.

Для этого мы с вами научимся создавать наборы политик и объединять несколько политик в группу в рамках vDC, а также создадим каталог (шаблон) на базе этих политик, чтобы предоставить пользователям доступ к этому каталогу через портал самообслуживания.

Начнем с инфраструктуры. Инфраструктура, на базе которой мы будем выполнять все настройки, состоит из:

  • NetApp Clustered DataONTAP 8.2 Simulator в качестве дискового массива;
  • виртуальной инфраструктуры развернутой на базе:
  • ESXi appliance 5.5.0;
  • vCenter appliance 5.5.0a.

Выглядит это примерно так:

Сразу отмечу, что все настройки политик и параметров для шаблона(ов) виртуальных машин в нашем посте будут относиться к VMWare vSphere инфраструктуре..Читать статью далее


Таги: IT-Grad, Cisco, UCS, Hardware, Cloud, Cloud Computing, Обучение, VMware, vSphere

Как вернуть SSD-накопитель, который был создан как устройство vFlash, хосту VMware ESXi.


Достаточно давно мы писали о технологии VMware vFlash (теперь она называется vSphere Flash Read Cache), которая пришла на смену технологии Swap-to-SSD - она позволяет использовать локальные SSD-диски хостов VMware ESXi для задач кэширования. Напомним, что Flash Read Cache позволяет использовать кэширование данных только на чтение для дисков VMDK виртуальных машин, работает она на уровне гипервизора и существенно улучшает производительность виртуальных машин, которые интенсивно используют подсистему ввода-вывода для операций на чтение.

Очевидно, что SSD-кэш, который по производительности находится между оперативной памятью и обычными дисками, существенно повышает быстродействие в системах, где периодически наблюдается недостаток ресурсов RAM. Все это дело работает в кластере до 32 хостов ESXi.

Однако, иногда вам может понадобиться вернуть SSD-накопитель хосту ESXi, чтобы использовать его для других задач. Можно попробовать отключить использование ресурсов vFlash для всех виртуальных машин хоста, затем пойти в раздел "Virtual Flash Resource Management" и выбрать опцию "Remove All" - но это не сработает. Появятся следующие ошибки:

Host’s virtual flash resource is inaccessible.
The object or item referred to could not be found.

Чтобы вернуть диск SSD снова в строй понадобится удалить специальный раздел - vFlash File System partition. Для этого нужно сначала его найти. Выполняем команду:

ls /vmfs/devices/disks

Тут мы видим нашу SSD-партицию (видим в середине буквы "SSD" - не ошибитесь - нам нужен раздел без ":1"):

disk ID “t10.ATA_____M42DCT032M4SSD3__________________________00000000121903600F1F”

Сносим эту партицию с помощью утилиты partedutil, используя найденный Disk ID:

partedutil delete "/vmfs/devices/disks/t10.ATA_____M42DCT032M4SSD3__________________________00000000121903600F1F" 1

Что-то вроде этого:

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

Источник.


Таги: VMware, ESXi, SSD, Storage, vFlash, Blogs

3D-ускорение VDI на практике (NVIDIA GRID). ТЕСТЫ. Часть 1.


Отсутствие аппаратного ускорения графики является существенным препятствием при внедрении технологий виртуализации в компаниях, работающих в сфере дизайна, проектирования, конструкторских разработок и пр. Рассмотрим, какие новые возможности появились с выходом адаптеров, предназначенных специально для работы с 3D-графикой NVIDIA GRID. Классный пост компании ИТ-ГРАД - с реальными тестами.


Таги: NVIDIA, GRID, VDI, IT Grad, VMware, Citrix, Performance

Сайзинг кластеров хранилищ VMware VSAN в VMware vSphere и их отказоустойчивость.


Как многие знают, в VMware vSphere 5.5 появились возможности Virtual SAN, которые позволяют создать кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бета этого решения, кроме того мы не так давно писали о производительности VSAN тут и тут.

Сегодня же мы поговорим о том, как нужно сайзить хранилища Virtual SAN в VMware vSphere, а также немного затронем тему отказоустойчивости. Более детальную информацию можно найти в VMware Virtual SAN Design & Sizing Guide, а ниже мы расскажем о подходе к планированию хранилищ VSAN вкратце.

Объекты и компоненты Virtual SAN

Начнем с простого ограничения по объектам (objects) и компонентам (components), которое есть в VSAN. Виртуальные машины, развернутые на vsanDatastore, могут иметь 4 типа объектов:

  • Домашняя директория виртуальной машины Virtual Machine ("namespace directory").
  • Объект файла подкачки - swap object (для включенной ВМ).
  • Виртуальный диск VMDK.
  • Дельта-диски для снапшотов. Каждый дельта-диск - это отдельный объект.

Каждый объект, в зависимости от типа RAID, рождает некоторое количество компонентов. Например, один VMDK, размещенный на двух томах страйпа (RAID 0) рождает два объекта. Более подробно об этом написано вот тут.

Так вот, ограничения тут следующие:

  • Максимальное число компонентов на 1 хост ESXi: 3000.
  • Максимальное число компонентов для одного объекта: 64 (это включает в себя тома страйпов и также реплики VMDK с других хостов).

На практике эти ограничения вряд ли актуальны, однако о них следует знать.

Сколько дисков потребуется для Virtual SAN

Во второй бета-версии VSAN (и, скорее всего, так будет в релизной версии) поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп. Таким образом, на хосте поддерживается до 5 SSD-дисков и до 35 HDD-дисков. Надо убедиться, что контроллеры хоста поддерживают необходимое количество дисков, а кроме того нужно проверить список совместимости VSAN HCL, который постоянно пополняется.

Также надо учитывать, что кластер хранилищ Virtual SAN поддерживает расширение как путем добавления новых дисков, так и посредством добавления новых хостов в кластер. На данный момент VMware поддерживает кластер хранилищ максимум из 8 узлов, что суммарно дает емкость в дисках в количестве 40 SSD (1*5*8) и 280 HDD (7*5*8).

Сколько дисковой емкости нужно для Virtual SAN (HDD-диски)

Необходимая емкость под размещение VMDK зависит от используемого параметра FailuresToTolerate (по умолчанию 1), который означает, какое количество отказов хостов может пережить кластер хранилищ. Если установлено значение 1, то реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно сказать о том, как работает отказоустойчивость кластера Virtual SAN. Если отказывает хост, на котором нет виртуальной машины, а есть только VMDK или реплика, то виртуальная машина продолжает работу с основной или резервной копией хранилища. В этом случае начнется процесс реконструкции реплики, но не сразу - а через 60 минут, чтобы дать время на перезагрузки хоста (то есть если произошел не отказ, а плановая или внеплановая перезагрузка), а также на короткие окна обслуживания.

А вот если ломается хост, где исполняется ВМ - начинается процедура восстановления машины средствами VMware HA, который перезапускает ее на другом хосте, взаимодействуя при этом с Virtual SAN.

Более подробно этот процесс рассмотрен вот в этой статье и вот в этом видео:

Однако вернемся к требующейся нам емкости хранилищ. Итак, если мы поняли, что значит политика FailuresToTolerate (FTT), то требуемый объем хранилища для кластера Virtual SAN равняется:

Capacity = VMDK Size * (FTT + 1)

Что, в принципе, и так было очевидно.

Сколько дисковой емкости нужно для Virtual SAN (SSD-диски)

Теперь перейдем к SSD-дискам в кластере VSAN, которые, как известно, используются для вспомогательных целей и не хранят в себе данных виртуальных машин. А именно, вот для чего они нужны (более подробно об этом тут):

  • Read Cache - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
  • Write Buffering - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Так каковы же рекомендации VMware? Очень просты - под SSD кэш и буфер неплохо бы выделять 10% от емкости HDD-дисков хоста. Ну и не забываем про значение FailuresToTolerate (FTT), которое в соответствующее число раз увеличивает требования к емкости SSD.

Таким образом, необходимая емкость SSD-хранилищ равна:

Capacity = (VMDK Size * 0.1) * (FTT + 1)

Ну и напоследок рекомендуем отличнейший список статей на тему VMware Virtual SAN:


Таги: VMware, Virtual SAN, VSAN, vSphere, ESXi, Storage, Sizing, Blogs

Новые возможности VMware vSphere 5.5 - официально.


Не так давно мы уже писали о планируемых новых возможностях VMware vSphere 5.5, однако большинство новых функций были описаны в общих чертах, кроме того, до последнего момента так и не было окончательно известно, что же еще нового появится в vSphere 5.5. На проходящей сейчас конференции VMworld 2013 компания VMware наконец-то объявила о выходе обновленной платформы VMware vSphere 5.5, которая стала еще более мощным средством для построения виртуальных инфраструктур.


Таги: VMware, vSphere, Update, ESXi, vCenter, vNetwork, Storage, VMachines, VMFS

Очередные таблицы сравнения VMware vSphere 5.1 и Microsoft Hyper 2012 R2.


Вот и стали появляться первые сравнения платформ виртуализации VMware vSphere 5.1 и еще невышедшего Microsoft Hyper 2012 R2 (в составе Windows Server 2012 R2). О сильных и слабых сторонах продуктов мы уже давно не спорим, так как дело это пустое, а вот таблички из статьи, содержащие немало фактического материала, спорщикам пригодятся.

Итак, что мы имеем в плане максимальных параметров, вычислительных ресурсов и масштабирования:

System Resource Microsoft Hyper-V 2012 VMware vSphere 5.1
Free Hypervisor Essential Plus Enterprise Plus
Host Logical Processors 320 160 160 160
Physical Memory 4 TB 32 GB 2 TB 2 TB
Virtual CPUs per Host 2048 2048 2048 2048
Nested Hypervisor No Yes Yes Yes
VM Virtual CPUs per VM 64 8 8 64
Memory per VM 1 TB 32 GB 1 TB 1 TB (max 64GB with FT)
Maximum Virtual Disk 64 TB 2 TB 2 TB 2 TB
Hot-Add Only disks Disks/vNIC/USB Disks/vNIC/USB All
Active VMs per Host 1024 512 512 512
Cluster Maximum Nodes 64 N/A 32 32
Maximum VMs 8000 N/A 4000 4000

Сравнение vSphere 5.1 и Hyper-V 2012 R2 в плане хранилищ (Storage):

Capability Microsoft Hyper-V 2012 VMware vSphere 5.1
Free Hypervisor Essential Plus Enterprise Plus
Thin disks Yes (dynamic disks) Yes Yes Yes
Differential disks Yes No (only with API) No (only with API) No (only with API)
SAN
iSCSI/FC iSCSI/FC iSCSI/FC iSCSI/FC
NAS SMB 3.0 NFS 3 over TCP NFS 3 over TCP NFS 3 over TCP
Virtual Fiber Channel Yes Yes Yes Yes
3rd Party Multipathing (MPIO) Yes No No Yes
Native 4-KB Disk Support Yes No No No
Maximum Virtual Disk Size 64TB VHDX 2TB VMDK 2TB VMDK 2TB VMDK
Maximum Pass Through Disk Size 265TB+ 64TB 64TB 64TB
Storage Offload Yes (ODX) No No Yes (VAAI)
Storage Virtualization
No (only 3rd part) No (only 3rd part) VSA VSA (limited to 3 nodes)
Storage Encryption Yes No No No
Caching Yes (CSV read-only cache) Swap to host cache Swap to host cache Swap to host cache

В плане сетевого взаимодействия различия следующие:

Capability Microsoft Hyper-V 2012 VMware vSphere 5.1
Free Hypervisor Essential Plus Enterprise Plus
NIC Teaming Yes Yes Yes Yes
Extensible Switch Yes No No Replaceable
PVLAN Support Yes No No Yes (only with DVS)
ARP/ND Spoofing Protection Yes No No vCNS/Partner
DHCP Snooping Protection Yes No No vCNS/Partner
Virtual Port ACLs Yes No No vCNS/Partner
Trunk Mode to Virtual Machines Yes No No No
Port Monitoring Yes Per Port Group Per Port Group Yes
Port Mirroring Yes Per Port Group Per Port Group Yes
Dynamic Virtual Machine Queue Yes NetQueue NetQueue NetQueue
IPsec Task Offload Yes No No No
SR-IOV Yes Yes (No Live Migration support) Yes (No Live Migration support) Yes (No Live Migration support)
Network Virtualization Yes No No VXLAN
Quality of Service Yes No No Yes
Data Center Bridging (DCB) Yes Yes Yes Yes

О том, что лучше - VMware vSphere или Microsoft Hyper-V, можно рассуждать бесконечно, но однозначно можно сказать только одно - Hyper-V год от года становится значительно функциональнее, а вот VMware основные усилия по улучшению продукта направляет только на издание Enterprise Plus, купить которое не каждой компании по средствам.


Таги: VMware, vSphere, Microsoft, Hyper-V, Сравнение, Server

Почти бесполезно, но интересно - параметр Mem.MinFreePct в конфигурации VMware vSphere и оптимизация памяти.


Недавно Duncan Epping опубликовал интересную статью о параметре Mem.MinFreePct, который есть в настройках сервера VMware ESXi из состава vSphere. По-сути, этот параметр определяет, какое количество оперативной памяти VMkernel должен держать свободным на хосте, чтобы всегда были доступные ресурсы под нужды системы, и хост не вывалился в PSOD.

В VMware vSphere 4.1 параметр Mem.MinFreePct составлял 6% и его можно было изменять с помощью следующей команды:

vsish -e set /sched/freeMemoryState/minFreePct <Percentage>

Например, вот так можно было установить Mem.MinFreePct в значение 2%:

vsish -e set /sched/freeMemoryState/minFreePct 2

Этак команда, кстати, не требует перезагрузки, но зато после перезагрузки значение Mem.MinFreePct не сохраняется. Поэтому данную команду, если требуется, нужно занести в /etc/rc.local (подробнее в KB 1033687).

Параметр этот очень важный, поскольку от него зависят пороги использования различных механизмов оптимизации памяти хоста ESXi. При этом, если памяти на хосте много (например, десятки гигабайт), то держать постоянно 6% свободной памяти может быть для кого-то расточительством. Поэтому, начиная с VMware vSphere 5.0, параметр Mem.MinFreePct является "плавающим" и устанавливается в зависимости от объема физической памяти на хосте ESXi.

Вот какие значения принимает Mem.MinFreePct в зависимости от того, сколько RAM есть на вашем физическом хост-сервере:

Процент необходимой свободной памяти
Объем памяти хоста ESXi
6% 0-4 ГБ
4% 4-12 ГБ
2% 12-28 ГБ
1% Больше 28 ГБ

А вот какие механизмы оптимизации памяти на хосте работают, если свободной памяти становится все меньше и меньше:

Состояние свободной памяти хоста Пороговое значение Какие механизмы оптимизации памяти используются
High 6% -
Soft 64% от значения MinFreePct Balloon, Compress
Hard 32% от значения MinFreePct Balloon, compress,swap
Low 16% от значения MinFreePct Swap

Интересно, конечно, но как-то бесполезно. Зачем загонять хост в такие лимиты? Лучше как минимум процентов 10 всегда держать свободными и своевременно покупать новые серверы.


Таги: VMware, vSphere, Memory, ESXi, Blogs

Memory Overhead виртуальных ПК на платформе VMware Horizon View 5.2.


Не так давно мы уже писали о накладных расходах на виртуализацию по памяти для виртуальных машин на платформе VMware vSphere, а сегодня поговорим о виртуальных ПК, которые предъявляют дополнительные требования к объему памяти сверх выделенного на обеспечение работы различных графических режимов в гостевой ОС.

Для начала отметим, что на платформе VMware Horizon View 5.2 появились следующие изменения по сравнению с предыдущими версиями в плане графических режимов виртуальных ПК:

  • Horizon View 5.2 не позволяет установить 24-битную цветовую палитру, теперь используется только 32-битная.
  • Horizon View 5.2 позволяет устанавливать разрешения только 1680×1050, 1920×1200 и 2560×1600. Дефолтным является 1920×1200.

Теперь о накладных расходах по памяти для виртуальных машин.

3D Software Rendering отключен

В этом случае расходы дополнительной памяти сервера на виртуальный ПК зависят от используемого разрешения и количества мониторов для виртуальной машины (значения приведены в мегабайтах):

Затраты памяти Число мониторов
Разрешение/Мониторы 1 2 3 4
1680×1050 6.73 21.54 32.30 43.07
1920×1200 8.79 28.13 42.19 56.25
2560×1600 31.25 62.5 93.75 125

Как вы знаете, в ESXi 5.0 появились возможности VMX Swap, которые позволяют создать swap-файл для сегментов данных процесса vmx, куда сбрасываются страницы памяти, но только в случае нехватки физической оперативной памяти на хосте. Он в разы уменьшает использование физической памяти на Overhead виртуальных машин в случае недостатка ресурсов.

Затраты хранилищ (в мегабайтах) на создание второго *.vswp файла для механизма VMX Swap рассчитываются следующим образом:

VMX SWAP Число мониторов
Разрешение/Мониторы 1 2 3 4
1680×1050 107 163 207 252
1920×1200 111 190 248 306
2560×1600 203 203 461 589

Как мы видим, для некоторых виртуальных ПК может потребоваться более полугигабайта дополнительного дискового пространства.

3D Software Rendering включен

Для виртуальных ПК отдельно или в пределах пула можно установить объем видеопамяти (VRAM, не путать с vRAM) доступный гостевой системе, что влияет на накладные расходы на виртуализацию.

В этом случае дополнительно требуемая физическая память будет рассчитываться как 64 МБ + 16 дополнительных МБ на каждый монитор.

Что касается SWAP-файла, то требуемый для него объем существенно выше, чем в первом случае. Он зависит от выделенной видеопамяти:

VRAM .vswp (МБ)
64 MB 1076
128MB 1468
256MB 1468
512MB 1916

То есть, в некоторых случаях дополнительные затраты на хранилище отдельной виртуальной машины могут достигать 2 ГБ. Чтобы это все учитывать при планировании инфраструктуры виртуальных ПК, можно воспользоваться калькулятором от Andre Leibovici, по материалам которого и написана эта заметка.


Таги: VMware, View, Memory, Enterprise, Blogs, vSphere, ESXi, VMachines

Технология Virtual Flash (vFlash) для SSD-накопителей в VMware vSphere.


Как многие знают, с выходом VMware vSphere 5.1 компания VMware объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, таких как концепция vVOL для хранилищ vSphere и сервисы распределенного хранения VMware Distributed Storage (концепция vSAN).

Кроме того, не так давно были воплощены в жизнь такие полезные службы vSphere для работы с SSD-накопителями, как SSD Monitoring (реализуется демоном smartd) и Swap to SSD (использование локальных дисков для файлов подкачки виртуальных машин). Однако функции кэширования на SSD реализованы пока совсем в базовом варианте, поэтому сегодня вам будет интересно узнать о новой технологии Virtual Flash (vFlash) для SSD-накопителей в VMware vSphere, которая была анонсирована совсем недавно.

Эта технология, находящаяся в стадии Tech Preview, направлена на дальнейшую интеграцию SSD-накопителей и других flash-устройств в инфраструктуру хранения VMware vSphere. Прежде всего, vFlash - это средство, позволяющее объединить SSD-ресурсы хост-серверов VMware ESXi в единый пул, используемый для задач кэширования, чтобы повысить быстродействие виртуальных машин. vFlash - это фреймворк, позволяющий сторонним вендорам SSD-накопителей и кэш-устройств использовать собственные алгоритмы для создания модулей обработки кэшей виртуальных машин (плагины vFlash Cache Modules). Будет реализован и собственный базовый алгоритм VMware для работы с кэшем.

Основная мысль VMware - предоставить партнерам некий API для их flash-устройств, за счет которого виртуальные машины будут "умно" использовать алгоритмы кэширования. Для этого можно будет использовать 2 подхода к кэшированию: VM-aware caching и VM-transparent caching:

VM-aware Caching (vFlash Memory)

В этом режиме обработки кэширования флэш-ресурс доступен напрямую для виртуальной машины, которая может использовать его на уровне блоков. В этом случае на уровне виртуального аппаратного обеспечения у виртуальной машины есть ресурс vFlash Memory определенного объема, который она может использовать как обычный диск в гостевой ОС. То есть, приложение или операционная система должны сами думать, как этот высокопроизводительный ресурс использовать. Можно вообще использовать его не как кэш, а как обычный диск, хотя идея, конечно же, не в этом.

VM-transparent Caching (vFlash Cache)

В этом случае виртуальная машина и ее гостевая ОС не знают, что на пути команд ввода-вывода находится прослойка в виде flash-устройств, оптимизирующих производительность за счет кэширования. В этом случае задача специализированного ПО (в том числе от партнеров) - предоставить оптимальный алгоритм кэширования. В этом случае будет доступна настройка следующих параметров кэша:

  • Гарантированный объем (Reservation size)
  • Выбор программного модуля-обработчика (vFlash Cache Module)
  • Режим работы кэша (write-back или write-thru)
  • Размер блока (настраивается в зависимости от гостевой ОС)
  • Что делать с кэшем при перемещении виртуальной машины посредством vMotion (перенести вместе с ней или удалить)

При vMotion сервер vCenter будет проверять наличие необходимых ресурсов кэширования для виртуальной машины на целевом хосте ESXi. Для совместимости с технологией VMware HA, виртуальная машина должна будет иметь доступные vFlash-ресурсы на хранилищах хостов в случае сбоя (соответственно, потребуется эти ресурсы гарантировать).

В целом vFlash в VMware vSphere обещает быть очень перспективной технологией, что особенно актуально на волне роста потребления SSD-накопителей, постепенно дешевеющих и входящих в повсеместное употребление.


Таги: VMware, vSphere, vFlash, SSD, Storage, ESXi

8 фактов о файлах подкачки виртуальных машин на платформе VMware vSphere (Virtual Machine Swap File - vswp).


Мы уже не раз затрагивали тему vswp-файлов виртуальных машин (файлы подкачки), которые используются для организации swap-пространства гипервизором VMware ESXi. Эти файлы выполняют роль последнего эшелона среди техник оптимизации памяти в условиях недостатка ресурсов на хосте. Напомним, что в гипервизоре VMware ESXi есть такие техники как Transparent Page Sharing, Memory Ballooning, a также Memory Compression, которые позволяют разбираться с ситуациями нехватки памяти, необходимой виртуальным машинам.

Напомним также, что первым эшелоном оптимизации памяти является техника Memory Ballooning. Она работает за счет использования драйвера vmmemctl.sys (для Windows), поставляемого вместе с VMware Tools. Он позволяет "надуть" шар внутри гостевой ОС (balloon), который захватывает физическую память, выделенную этой ОС (если ее много), и отдает ее другим гостевым операционным системам, которые в ней нуждаются. Этот balloon не позволяет гостевой ОС производить работу приложений с данной областью памяти, поэтому если им потребуется дополнительная память - она будет уходить в гостевой своп. Это более правильный подход, чем свопировать гостевую ОС в файл подкачки vswp на томе VMFS, поскольку операционная система сама лучше разбирается, что и когда ей класть и доставать из свопа (соответственно, быстродействие выше).

Однако, когда памяти у всех виртуальных машин совсем мало или отдельной ВМ ее требуется больше, чем сконфигурировано, а также происходит постоянное обращение к памяти (особенно, если в гостевых ОС нет 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 в недефолтной конфигурации (когда происходит активное копирование страниц и их репликация):

7. Если вы используете снапшоты на уровне хранилищ (Datastore или LUN), то лучше хранить vswp-файлы отдельно от этих хранилищ - так как в эти снапшоты попадает много ненужного, содержащегося в своп-файлах.

8. Нужно ли класть vswp-файлы на хранилища, которые развернуты на базе thin provisioned datastore (на уровне LUN)? Ответ на этот вопрос зависит от того, как вы мониторите свободное место на тонких лунах и устройствах своего дискового массива. При создании vswp-файла VMkernel определяет его размер и возможность его создания на уровне хоста ESXi, а не на уровне устройства дискового массива. Поэтому если vswp-файл активно начнет использоваться, а вы этого не заметите при неправильной конфигурации и отсутствии мониторинга тонких томов - то могут возникнуть проблемы с их переполнением, что приведет к сбоям в работе ВМ.


Таги: VMware, vSphere, VMachines, Storage, swap, VMFS, Blogs, ESXi

Список политик безопасности для серверов VMware ESX/ESXi в vGate R2 и рекомендации по их применению.


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


Таги: vGate, Security, VMware, vSphere, ESX, ESXi, vCenter

Memory Overhead виртуальных машин в VMware vSphere и возможности VMX Swap.


Как известно, виртуализация требует дополнительных ресурсов сверх тех, которые потребляет непосредственно виртуальная машина. Это называют накладными расходами на виртуализацию (так называемый virtualization overhead). Оверхэд есть как для процессора (примерно 3-5 процентов на хост-сервере), так и для оперативной памяти.

При этом для оперативной памяти накладные расходы гипервизора зависят от количества виртуальных процессоров (vCPU) и объема оперативной памяти, выделенных виртуальной машине. Мы уже писали о накладных расходах по RAM для виртуальных машин в VMware vSphere 4, где использовались следующие средние значения:

Информация эта взята из vSphere 4.0 Online Library.

В VMware vSphere 5 есть новая возможность, которая называется VMX Swap. При включении виртуальной машины гипервизор ESXi создает для нее vmx-процесс, управляющий различными структурами данных, под которые требуется физическая оперативная память. Ее объем, как было сказано, зависит от конфигурации ВМ - количества vCPU и RAM. Для снижения потребления этой памяти в ESXi 5.0 механизм VMX Swap создает swap-файл для сегментов данных процесса vmx, куда сбрасываются страницы памяти, но только в случае нехватки физической оперативной памяти на хосте.

VMX Swap создает файлы подкачки в директории с виртуальной машиной, через который и происходит загрузка и выгрузка страниц процесса vmx. Размещение этих файлов можно переопределить, добавив следующий параметр в расширенные настройки виртуальной машины:

sched.swap.vmxSwapDir

По умолчанию механизм VMX Swap включен и в критических ситуациях позволяет уменьшить overhead типичной виртуальной машины с 50 МБ до 10 МБ. Для виртуализации серверов такие порядки цифр может и не очень важны, зато для виртуализации настольных ПК (например, VMware View), где на одном сервере могут находиться десятки и даже сотни виртуальных машин, эта возможность может оказаться весьма кстати в условиях нехватки вычислительных ресурсов.

Если вы считаете, что ресурсов у вас достаточно и VMX Swap вам не нужен, можно его отключить, добавив значение FALSE в следующу расширенную настройку виртуальной машины:

sched.swap.vmxSwapEnabled

Ну а теперь посмотрим сколько оверхэда по памяти потребляет виртуальная машина уже в VMware vSphere 5 с включенным по умолчанию VMX Swap:

20.29 24.28 32.23 48.16
25.90 29.91 37.86 53.82
48.64 52.72 60.67 76.78
139.62 143.98 151.93 168.60

Эта информация уже из vSphere 5 Documentation Center. Как мы видим из таблицы, накладные расходы по памяти с учетом VMX Swap уже значительно меньше (в некоторых случаях до 8-9 раз). Как уверяют коллеги из VMware, в условиях недостатка ресурсов VMX Swap почти не влияет на производительность хост-сервера ESXi, ну а в условиях достатка - не влияет совсем.


Таги: VMware, vSphere, Memory, Performance, ESXi

Залоченные файлы виртуальной машины в VMware vSphere - Could not power on VM: Lock was not free.


При эксплуатации виртуальной инфраструктуры VMware vSphere иногда случается ситуация, когда виртуальную машину нельзя включить из-за того, что ее какой-нибудь из ее файлов оказывается залоченным. Происходит это при разных обстоятельствах: неудачной миграции vMotion / Storage vMotion, сбоях в сети хранения и прочих.

Наиболее распространенная ошибка при этом выглядит так:

Could not power on VM: Lock was not free

Встречаются также такие вариации сообщений и ошибок при попытке включения виртуальной машины, которое зависает на 95%:

  • Unable to open Swap File
  • Unable to access a file since it is locked
  • Unable to access a file <filename> since it is locked
  • Unable to access Virtual machine configuration

Ну а при попытке соединения с консолью ВМ получается вот такое:

Error connecting to <path><virtual machine>.vmx because the VMX is not started

Все это симптомы одной проблемы - один из следующих файлов ВМ залочен хост-сервером VMware ESXi:

  • <VMNAME>.vswp
  • <DISKNAME>-flat.vmdk
  • <DISKNAME>-<ITERATION>-delta.vmdk
  • <VMNAME>.vmx
  • <VMNAME>.vmxf
  • vmware.log

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

Поиск залоченного файла ВМ

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

Failed to initialize swap file : Lock was not free

Тут видно, что залочен .vswp-файл ВМ.

За логом на экране можно следить командой (запустите ее и включайте ВМ):

tail /vmfs/volumes/<UUID>/<VMDIR>/vmware.log

Проверка залоченности файла ВМ и идентификация владельца лока

После того, как залоченный файл найден, нужно определить его владельца. Сначала попробуем команду touch, которая проверяет, может ли бы обновлен time stamp файла, т.е. можно ли его залочить, или он уже залочен. Выполняем следующую команду:

# touch /vmfs/volumes/<UUID>/<VMDIR>/<filename>

Если файл уже залочен, мы получим вот такое сообщение для него:

cannot touch: Device or resource busy

Дальше выполняем такую команду:

# vmkfstools -D /vmfs/volumes/<UUID>/<VMDIR>/<filename>

В значении "owner" мы видим MAC-адрес залочившего файл хоста VMware ESXi (выделено красным). Ну а как узнать MAC-адрес хоста ESXi - это вы должны знать. Дальше просто делаем Cold Migration виртуальной машины на залочивший файл хост ESXi и включаем ее там.

Те, кто хочет дальше изучать вопрос, могут проследовать в KB 10051.

Источник: "Could not power on VM - lock was not free".


Таги: VMware, vSphere, Troubleshooting, Bugs, ESXi

Плакат VMware vSphere 5 Memory Management and Monitoring diagram.


Компания VMware в базе знаний опубликовала интересный плакат "VMware vSphere 5 Memory Management and Monitoring diagram", раскрывающий детали работы платформы VMware vSphere 5 с оперативной памятью серверов. Плакат доступен как PDF из KB 2017642:

Основные техники оптимизации памяти хостов ESXi, объясняемые на плакате:

Есть также интересная картинка с объяснением параметров вывода esxtop, касающихся памяти (кликабельно):

Пишут, что администраторы VMware vSphere скачивают его, распечатывают в формате A2 и смотрят на него время от времени, как на новые ворота. Таги: VMware, vSphere, Memory, ESX, esxtop, VMachines, Whitepaper, Diagram

Файлы снапшотов (snapshots) виртуальных машин VMware vSphere 5 и поддерживаемые операции.


О снапшотах виртуальных машин VMware vSphere мы уже много писали (например, можно пискать по тэгу "Snapshot"). Постараемся в этой заметке просуммировать информацию о том, что из себя представляют файлы снапшотов виртуальных машин vSphere 5 и как они обрабатываются.

Для того, чтобы снять снапшот виртуальной машины (virtual machine snapshot), можно кликнуть на ней правой кнопкой в vSphere Client и выбрать соответствующий пункт "Take Snapshot" из контекстного меню:

Далее появится окно снятия снапшота ВМ:

Обратите внимание на опцию "Snapshot the virtual machine's memory". Если эту галку убрать, то снапшот не будет содержать состояние памяти виртуальной машины, т.е. при откате к нему ВМ будет в выключенном состоянии. Плюс такого снапшота - он создается намного быстрее, поскольку не надо сохранять память машины в отдельный файл.

Вторая опция - это возможность "заморозки" файловой системы виртуальной машины на время создания снапшота. Она доступна только при условии установленных в гостевой ОС VMware Tools, в составе которых идет Sync Driver. Эта функциональность нужна для создания консистентного состояния виртуальной машины для снапшота на уровне файловой системы, что особенно необходимо при создании резервных копий (используют все системы резервного копирования для виртуализации, например, Veeam Backup and Replication). Данная возможность (quiesce) поддерживается не всегда - об условиях ее применения можно прочитать тут.

После создания снапшота заглянем в Datastore Browser на хосте VMware ESXi через vSphere Client:

Выделенные зеленым объекты - это абстрации двух снапшотов виртуальных машин. Чтобы понять, что собой представляют эти абстрации, откроем каталог с виртуальной машины в консоли (Putty по SSH):

Здесь мы уже видим, что снапшот на самом деле - это набор из четырех файлов:

  • <имя ВМ>-[шесть цифр]-delta.vmdk - файл данных диска отличий от базового диска
  • <имя ВМ>-[шесть цифр].vmdk - заголовочный файл
  • <имя ВМ>.vmsd - текстовый файл с параметрами снапшота (связи в дереве, SCSI-нода, время создания и т.п.)
  • <имя ВМ>.vmsn - файл с сохраненной памятью виртуальной машины

Самый главный файл - это, конечно, <имя ВМ>-[шесть цифр]-delta.vmdk. Он содержит блоки данных хранимые в формате так называемых redo-логов (он же дочерний диск - child disk). Он же sparse-диск, то есть диск, который использует технологию Copy-On-Write (COW) при работе с данными. Идея технологии copy-on-write — при копировании областей данных создавать реальную копию только когда ОС обращается к этим данным с целью записи. Таким образом, этот виртуальный диск содержит только измененные от родительского диска области данных (delta).

По умолчанию размер COW-операции составляет 64 КБ, что эквивалентно 128 секторам (подробнее). Но сам снапшот растет блоками данных по 16 МБ. То есть запись 64 КБ данных исходного диска может породить прирост 16 МБ данных в диске снапшота.

Следующий интересный тип файла - <имя ВМ>.vmsd. Это обычный текстовый файл, который можно открыть в редакторе и увидеть все отношения между родительским и дочерними дисками, а также другую интересную информацию:

Ну и последнее - это память виртуальной машины, хранящаяся в файле <имя ВМ>.vmsn. Его, понятное дело, может не быть, если вы создавали снапшот выключенной ВМ или убрали галку, о которой написано в самом начале.

По умолчанию снапшоты складываются в папку на VMFS-томе, где лежит виртуальная машина. Но это размещение можно сменить, поменяв рабочую папку (Working Directory) в настройках виртуальной машины через vSphere Client или в vmx-файле, для чего нужно добавить или поменять строчку:

workingDir="/vmfs/volumes/SnapVolume/Snapshots/"

Кстати, эта же папка задает и размещение файла подкачки ВМ (*.vswp). Если вы его хотите оставить на прежнем месте, нужно добавить строчку:

sched.swap.dir = "/vmfs/volumes/VM-Volume1/MyVM/"

Ну и напоследок, какие операции поддерживаются для виртуальных машин со снапшотами:

Операция Требования и комментарии
Storage vMotion Для хостов ESX/ESXi 4.1 или более ранних - не поддерживатся. Для ESXi 5.0 или более поздних - поддерживается.
vMotion Поддерживается. Файлы снапшотов должны быть доступны на целевом хосте. Необходима версия hardware version 4 или более поздняя (ESX/ESXi 3.5 и выше).
Cold migration Поддерживается для хостов ESX/ESXi 3.5 или более поздних.
Fault Tolerance Не поддерживается. Для создания снапшота нужно отключить FT.
Hot clone Поддерживается, но снапшотов не должно быть больше 31 штуки.
Cold clone Поддерживается. Однако целевая ВМ будет без снапшотов.

Более подробную информацию о снапшотах можно найти в KB 1015180.

Ну и небольшая подборка ссылок по траблшутингу снапшотов в VMware vSphere:

И отдельно выделим вот эту потрясающую библию снапшотов: Troubleshooting Virtual Machine snapshot problems.


Таги: VMware, vSphere, Snapshot, Обучение, ESX, ESXi, VMachines, Troubleshooting

vCheck 6 - утилита для отчетности о виртуальной инфраструктуре VMware vSphere перед началом рабочего дня.


Alan Renouf, автор множества полезных скриптов PowerCLI для администрирования инфраструктуры VMware vSphere, выпустил очередное обновление своей бесплатной утилиты vCheck 6.

vCheck 6 - это PowerCLI-скрипт, который готовит отчетность по объектам окружения VMware vSphere и отсылает результат на почту администратора, из которого можно узнать о текущем состоянии виртуальной инфраструктуры и определить потенциальные проблемы.

Пример получаемого отчета можно посмотреть тут (кликабельно):

Вот полный список того, что может выдавать скрипт vCheck 6:

  • General Details
    • Number of Hosts
    • Number of VMs
    • Number of Templates
    • Number of Clusters
    • Number of Datastores
    • Number of Active VMs
    • Number of Inactive VMs
    • Number of DRS Migrations for the last days
  • Snapshots over x Days old
  • Datastores with less than x% free space
  • VMs created over the last x days
  • VMs removed over the last x days
  • VMs with No Tools
  • VMs with CD-Roms connected
  • VMs with Floppy Drives Connected
  • VMs with CPU ready over x%
  • VMs with over x amount of vCPUs
  • List of DRS Migrations
  • Hosts in Maintenance Mode
  • Hosts in disconnected state
  • NTP Server check for a given NTP Name
  • NTP Service check
  • vmkernel warning messages ov the last x days
  • VC Error Events over the last x days
  • VC Windows Event Log Errors for the last x days with VMware in the details
  • VC VMware Service details
  • VMs stored on datastores attached to only one host
  • VM active alerts
  • Cluster Active Alerts
  • If HA Cluster is set to use host datastore for swapfile, check the host has a swapfile location set
  • Host active Alerts
  • Dead SCSI Luns
  • VMs with over x amount of vCPUs
  • vSphere check: Slot Sizes
  • vSphere check: Outdated VM Hardware (Less than V7)
  • VMs in Inconsistent folders (the name of the folder is not the same as the name)
  • VMs with high CPU usage
  • Guest disk size check
  • Host over committing memory check
  • VM Swap and Ballooning
  • ESXi hosts without Lockdown enabled
  • ESXi hosts with unsupported mode enabled
  • General Capacity information based on CPU/MEM usage of the VMs
  • vSwitch free ports
  • Disk over commit check
  • Host configuration issues
  • VCB Garbage (left snapshots)
  • HA VM restarts and resets
  • Inaccessible VMs

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

Скачать скрипт vCheck 6.0 можно по этой ссылке.


Таги: VMware, vSphere, Blogs, ESXi

Как получить бесплатную лицензию и ключ на VMware ESXi 5.0 (vSphere Hypervisor). Пошаговое руководство.


Для тех пользователей, кто только начинает свое знакомство с технологиями виртуализации, первым серверным гипервизором в большинстве случаев становится VMware ESXi. В этой статье мы приведем пошаговую инструкцию по получению лицензионного ключа на беcплатную платформу виртуализации VMware ESXi, которая официально называется VMware vSphere Hypervisor.


Таги: VMware, ESXi, Бесплатно, Обучение, vSphere

Новые возможности Veeam Backup and Replication 6.


Многие из вас знают продукт номер 1 для резервного копирования виртуальных машин VMware vSphere - Veeam Backup and Replication. Мы уже много писали как о функциональности Veeam Backup and Replication 5, так и о новых возможностях, которые появляются в Veeam Backup and Replication 6. В среду, 30 ноября, должен состояться релиз новой версии продукта, поэтому постараемся в этой статье собрать все новые функции, улучшения и нововведения Veeam Backup and Replication 6 (обратите также внимание на повышение цен на продукт с 1 декабря).

Приведенная ниже информация основана на документе "Veeam Backup & Replication. What's new in v6", который вы можете почитать в оригинале для понимания всех аспектов новых возможностей этого средства для резервного копирования виртуальных машин.

Новые ключевые возможности и улучшения Veeam Backup and Replication 6:

  • Enterprise scalability: улучшенная архитектура продукта позволяет производить развертывание в удаленных офисах и филиалах, а также для больших инсталляций. Теперь появилось несколько backup proxy серверов для крупных окружений (data movers), которые могут распределять между собой нагрузку в процессе резервного копирования, а управляет процессом сервер Veeam Enterprise Manager. Виртуальные машины динамически назначаются proxy-серверам с учетом алгоритма балансировки нагрузки, что снижает затраты на администрирование инфраструктуры РК. Также увеличена производительность для резервного копирования, репликации и восстановления по WAN-каналам.
  • Advanced replication: в некоторых случаях скорость репликации выросла до 10 раз, а также появится Failback (обратное восстановление виртуальной машины после возобновления работы отказавшего хоста с ВМ) с возможностью синхронизации дельты (различия данных с момента отказа основной машины на основном сервере и хранилище - Failover). Кроме того, поддерживается репликация в thin provisined-диски на целевой сервер. Это сильная заявка на победу над VMware SRM 5 (в издании Standard) для небольших компаний, где серверов не много и нужно укладываться в небольшие бюджеты. Появилась также возможность создания реплик базового образа для окружений VMware View.
  • Multi-hypervisor support: полная поддержка Windows Server с ролью Hyper-V и Microsoft Hyper-V Server, а также возможность управления резервным копированием для гипервизоров разных производителей из одной консоли. Одна и та же инсталляция Veeam Backup позволит делать резервные копии и с VMware vSphere, и с Microsoft Hyper-V. При этом лицензирование также единое - один пул лицензий Veeam вы можете распределить между лицензиями на процессоры для хостов ESXi и Hyper-V. Кроме того, появилась поддержка методики Changed Block Tracking для Hyper-V для ускорения процесса инкрементального резервного копирования (отслеживание изменившихся блоков с момента последнего бэкапа).
  • 1-Click File Restore - с помощью 1-Click File Restore можно зайти в Enterprise Manager, выбрать нужный файл и восстановить туда, откуда он был удален (это можно сделать также из результатов поиска файла по резервным копиям). При этом есть разделение ролей - есть тот, кто может файл восстановить (helpdesk), а есть тот, кто открыть. Данная возможность доступна только в Enterprise Edition.

Полный список новых возможностей:

Архитектура Veeam Backup and Replication 6

  • ESXi-centric processing engine - теперь архитектура продукта полностью опирается на архитектуру ESXi, но в поддержка гипервизора ESX остается в полной мере.
  • Backup proxy servers - один сервер Veeam Backup может контролировать несколько прокси-серверов, обеспечивающих передачу данных на целевые хранилища. Прокси-серверы не нуждаются в Microsoft SQL
    Server и содержат минимальный набор компонентов.
  • Backup repositories - новая концепция репозиториев резервного копирования (в традиционном РК известная как медиа-серверы), которые хранят настройки задач резервного копирования и параметры целевых хранилищ. Задачи по РК виртуальных машин с помощью медиа-серверов динамически назначаются proxy-серверам с учетом алогоритма балансировки нагрузки.
  • Windows smart target - в дополнение к Linux target agent, который помогает при резервном копировании в удаленные хранилища, появился также агент для Windows. Этот агент на целевой машине позволяет производить эффективную компрессию и обновлять синтетические резервные копии.
  • Enhanced vPower scalability - теперь можно использовать несколько серверов vPower NFS. Теперь можно запускать еще больше ВМ напрямую из резервных копий (например, если у вас много ВМ с большими дисками это очень может помочь). Любой сервер РК Veeam или Windows backup repository может быть таким сервером.

Ядро продукта Veeam Backup and Replication 6

  • Optimization of source data retrieval - теперь учитываются параметры дисковых хранилищ при обращении к виртуальным машинам. Это позволяет до 4-х раз увеличить производительность для одной операции, в зависимости от настроек дискового массива.
  • Reduced CPU usage - теперь в два раза меньше нагрузка задач на процессор, что позволяет запустить больше задач РК или репликации на одном сервере Veeam Backup или прокси-сервере.
  • Traffic throttling - теперь доступны опции по регулированию полосы пропускания, которые производятся на базе пары source/target IP. Эти правила могут быть основаны на времени операций - время дня или день недели.
  • Multiple TCP/IP connections per job - теперь агенты Data Movers могут инициировать соединение по нескольким IP-адресам, что существенно увеличивает скорость резервного копирования. Особенно это эффективно для репликации по WAN-каналам.
  • WAN optimizations - протокол передачи данных Veeam Backup был существенно доработан в плане производительности для передачи данных по соединениям с большими задержками в канале.
  • Exclusion of swap files - блоки, относящиеся к файлам подкачки, теперь исключаются из передачи в резервную копию, что существенно увеличивает производительность.
  • Enforceable processing window - теперь для каждой задачи можно задавать окно РК или репликации (все задачи, не попадающие в это окно завершаются). Также вне рамок окна не разрешается применение снэпшотов, что не позволяет оказывать влияние на производительность ВМ в рабочие часы.
  • Parallel backup and replication - теперь задачи, относящиеся к одной и той же ВМ, могут быть выполнены параллельно. Например, вы можете запускать ежедневную задачу Full Backup параллельно с работающей задачей репликации.

Улучшения резервного копирования в Veeam Backup and Replication 6

  • Backup mapping - при создании новой задачи резервного копирования ВМ, ее можно присоединить к уже имеющейся задаче (например, в ней есть уже файлы этой ВМ). В этом случае Full Backup этой ВМ может не потребоваться.
  • Enhanced backup file format - новый формат метаданных позволяет осуществлять быстрый импорт резервных копий, а также закладывает основу для поддержки новой функциональности в следующих релизах продукта.
  • Backup file data alignment - данные ВМ, сохраненные в бэкап-файле, могут быть размещены в пределах блоков по 4 КБ. Это увеличивает производительность дедупликации как самого Veeam Backup, так и сторонних технологий дедупликации (например, средствами дискового массива).
  • Improved compatibility with deduplicating storage - теперь механизм РК оказывает меньшее влияние на предыдущие файлы резервной копии, что улучшает производительность массивов, которые осуществляют пост-процессинг хранимых данных.

Репликация Veeam Backup and Replication 6

  • New replication architecture - теперь репликация использует двухагентную архитектуру, которая позволяет собирать данные хранилищ ВМ на исходном DR-сайте одним прокси-сервером РК и посылать их напрямую к прокси-серверу резервной площадки (и наоборот), минуя главный сервер Veeam Backup. Поэтому теперь не разницы, где размещать последний.
  • Replica state protection - теперь инкрементальные задачи репликации больше не обновляют последнюю точку восстановления ВМ. Это позволяет при прерывании задачи не перестраивать последнюю точку восстановления до того, как следующая задача откатит ее к последнему согласованному состоянию, как в прошлых версиях. В версии 6 последняя точка восстановления всегда согласована и ВМ может быть запущена в любой момент.
  • Traffic compression - за счет новой архитектуры репликации теперь не важно где находится основной сервер РК Veeam, а трафик сжимается намного более эффективно. Кроме того, появились настройки уровня компрессии для передаваемого трафика, что позволяет уменьшить требования к полосе пропускания до 5 раз.
  • Hot Add replication - теперь прокси-сервер на целевой площадке представляет диски реплики, используя технологию Hot Add. Это уменьшает поток трафика до 4 раз.
  • 1-click automated failback - позволяет произвести обратное восстановление (Failback) виртуальной машины после возобновления работы отказавшего хоста с ВМ с возможностью синхронизации только дельты с момента последнего отказа (Failover), т.е. различия данных с момента отказа основной машины на основном сервере и хранилище) . Перед завершением этого процесса можно проверить ВМ на работоспособность на основной площадке.
  • 1-click permanent failover - возможность в один клик провести все необходимые процедуры по завершению процесса превращения резервной машины в основную, когда в случае отказа основной ВМ она переместилась на резервный сайт.
  • Active rollbacks - репликация теперь хранит точки восстановления как обычные снапшоты ВМ. Это позволяет откатиться в любую точку на резервной площадке, даже без участия Veeam Backup.
  • Improved replica seeding - улучшения механизма организации репликации. Теперь репликация использует обычные бэкап-файлы, это позволяет уменьшить размер передаваемых данных, поддерживаются ВМ с тонкими (thin) дисками и многое другое.
  • Replica mapping - теперь реплицируемую виртуальную машину можно привязать к уже существующей ВМ на резервной площадке (например, ранее для нее использовалась репликация или на резервную площадку ее восстановили из резервной копии). Это позволяет не передавать весь объем данных для создания реплицируемой пары.
  • Re-IP - теперь можно задать правила автоматического назначения IP-адреса для восстанавливаемой ВМ. Это очень полезно, когда требуется восстановить ВМ на резервную площадку, где действует другая схема IP-адресации, в случае сбоя основной.
  • Cluster target - задачи репликации теперь поддерживают указание определенного хоста или кластера как целевого для репликации. Это позволяет убедиться в том, что при восстановлении ВМ она окажется доступной (например, на резервной площадке).
  • Full support for DVS - полная поддержка распределенных коммутаторов VMware Distributed Virtual Switches технологией репликации, что позволяет передавать состояние реплики без дополнительных ручных операций (например, в окружениях с VMware vCloud Director).
  • Automatic job update - операции failover и failback автоматически обновляют задачу репликации путем исключения из нее ВМ и повторного добавления.
  • Multi-select operations - в консоли теперь можно выбрать несколько ВМ для операций с репликацией. Например, при массовом выходе из строя хостов можно провести операции failover сразу с несколькими ВМ (аналогично и для failback).
  • Enhanced job configuration - теперь мастер создания реплицируемой пары поддерживает возможность настройки репликации на уровне vmdk-дисков, а также предоставляет возможность настроить целевые объекты: resource pool, VM folder и virtual network, где будет размещаться реплика и восстанавливаться ВМ.

Миграция виртуальных машин в Veeam Backup and Replication 6

  • Quick Migration - эта технология позволяет организовать миграцию виртуальной машины между хостами и/или хранилищами путем передачи данных ВМ в фоновом режиме (пока она запущена) и потом на время простоя (переключения) передается только дельта файлов vmdk. Переключение осуществляется с помощью технологии SmartSwitch или просто повторной загрузкой ВМ. По сути, эта функция - аналог vMotion и Storage vMotion, но с небольшим простоем ВМ.
  • SmartSwitch - эта технология позволяет передать текущее состояние ВМ от исходного хоста и хранилища к источнику на время переключения виртуальной машины между ними (с простоем). При этом процессоры исходного и целевого хостов должны быть совместимы по инструкциями.
  • Migration jobs - новый тип задач "миграция ВМ". С учетом имеющейся у вас лицензии на VMware vSphere, мастер миграции выполняет одну из следующих задач: VMware vMotion, VMware Storage vMotion, Veeam Quick Migration
    with SmartSwitch или Veeam Quick Migration with cold switch. Это позволяет быстро перевести ВМ с хостов, для которых требуется срочное обслуживание или останов (например, электричество выключили, а они на UPS'ах) или перенести ВМ в другой датацентр с минимальным влиянием на доступность сервисов в ВМ.
  • Instant VM Recovery integration - задачи миграции ВМ теперь оптимизированы для работы с функцией Instant VM Recovery. Если задача миграции обнаруживает, что ВМ переносится из состояния, когда она была мгновенно восстановлена (т.е. дельта размещается на vPower NFS datastore), то постоянная составляющая этой ВМ берется из бэкап-файла, а различия уже с NFS-хранилища для ускорения процесса миграции и оптимизации производительности.

Копирование файлов в Veeam Backup and Replication 6

  • Support for copying individual file - поддержка копирования отдельных файлов. Задача по копированию файлов теперь поддерживается так же, как и для каталогов.

Восстановление виртуальных машин в Veeam Backup and Replication 6

  • 1-click VM restore - при восстановлении ВМ в исходное размещение (самый частый случай), это может быть сделано в один клик.
  • Virtual Disk Restore wizard - новый режим восстановления позволяет восстановить отдельные vmdk-диски в их исходное размещение или присоединить к другой или новой ВМ. При этом мастер Virtual Disk Restore может восстанавливать диски как "thin" (т.е. растущими по мере наполнения данными), а также делает все необходимые настройки в заголовочном vmdk-файле.
  • Hot Add restores - Veeam Backup первым стал поддерживать технологию Hot Add не только для РК, но и для восстановления vmdk-дисков, что позволяет избежать проблем производительности.
  • Multi-VM restore - возможность восстановления сразу многих ВМ из графического интерфейса, что очень удобно для случаев массовых отказов хранилищ или хост-серверов.
  • Full support for DVS - полная поддержка распределенных коммутаторов VMware Distributed Virtual Switches и улучшения в интерфейсе по интеграции с ним (что удобно, например, при использовании совместно с vCloud Director).
  • Network mapping - при восстановлении виртуальных машин на сервер или площадку с другой конфигурацией виртуальных сетей, можно указать новые параметры сетевого взаимодействия.
  • moRef preservation - при восстановлении ВМ с заменой существующей копии, ее идентификатор сохраняется, что позволяет не перенастраивать задачи Veeam, а также стороннее ПО, работающее с виртуальными машинами по их идентификатору (почти все так и работают).

Восстановление на уровне файлов в Veeam Backup and Replication 6

  • Support for GPT and simple dynamic disks - теперь восстановление на уровне файлов поддерживает тома GPT и simple dynamic disks.
  • Preservation of NTFS permissions - опционально при восстановлении файлов Windows можно сохранить владельца и права на них в NTFS.

Индексирование и поиск файлов в резервных копиях Veeam Backup and Replication 6

  • Optional Search Server - теперь поиск по файлам гостевой ОС работает без Microsoft Search Server. Однако он рекомендуется для больших окружений с сотнями ВМ для лучшей производительности.
  • Reduced catalog size - размер каталога файловой системы гостевых ОС существенно уменьшился, что позволяет экономить место на сервере Veeam Backup.
  • User profile indexing - появилась поддержка индексации профиля пользователя в гостевой ОС.

Статистика и отчетность в Veeam Backup and Replication 6

  • Enhanced real-time statistics - теперь статистика в реальном времени по задачам РК улучшена в плане дизайна, чаще обновляется и более информативна для пользователя.
  • Improved job reports - отчеты о задачах РК лучше выглядят, имеют дополнительную информацию, включая количество изменившихся данных, уровень компрессии и коэффициент дедупликации.
  • Bottleneck monitor - в ответ на наиболее частые вопросы о низкой производительности в различных окружениях, Veeam сделала новый компонент, который позволяет выявить узкие места на различных стадиях РК и репликации. Все это отображается в статистике реального времени.
  • VM loss warning - история задач РК теперь оповещает пользователя о виртуальных машинах, которые раньше бэкапились, а потом задачи РК перестали существовать (например, случайно или намеренно удалили).

Интерфейс пользователя консоли Veeam Backup and Replication 6

  • Wizard improvements - все мастера были обновлены для возможности быстрой навигации при создании задач РК. Некоторые мастера стали динамическими - т.е. сфокусированными только на той задаче, которую вы хотите выполнить.
  • VM ordering - мастера резервного копирования и репликации теперь позволяют задать порядок, в котором ВМ должны обрабатываться.
  • Multi-user access - доступ нескольких пользователей к консоли теперь включен по умолчанию, позволяя нескольким пользователям получить доступ к консоли по RDP на одном сервере.

Веб-интерфейс Enterprise Manager в Veeam Backup and Replication 6

  • Job editing - в дополнение к управлению задачами, Enterprise Manager позволяет теперь менять их настройки для защищаемых ВМ, бэкап-репозитории, учетную запись гостевой ОС - все прямо из веб-интерфейса.
  • Job cloning - существующие задачи теперь могут быть клонированы прямо из веб-интерфейса с сохранением всех настроек.
  • Helpdesk FLR - появилась новая роль "File Restore Operator" в Enterprise Manager, которой делегированы полномочия по восстановлению отдельных файлов. Ее можно назначить персоналу службы help desk. При этом файлы восстанавливаются в их исходное размещение, а персоналу hepl desk можно ограничить возможности их скачивания, и, соответственно, доступа к ним (есть настройки касательно типов файлов и прочее).
  • FIPS compliance - веб-интерфейс теперь полностью совмести с стандартом FISP.
  • Design improvements - веб-интерфейс имеет множество улучшений в плане юзабилити и дизайна.

Улучшения технологии SureBackup в Veeam Backup and Replication 6

  • Improved DC handling - теперь улучшена работа с контроллерами домена в ситуациях, когда он оказывается изолированным в окружениях с несколькими DC.
  • Support for unmanaged VMware Tools - задачи SureBackup теперь поддерживают виртуальные машины с пакетами VMware Tools, которые установлены вручную.

Остальные улучшения Veeam Backup and Replication 6

  • Enhanced PowerShell support - расширены возможности PowerShell API, что позволяет управлять всеми настройками Veeam Backup. Все командлеты PowerShell были упрощены в плане синтаксиса (старый синтаксис также поддерживается). Появились маски в именах объектов, поиск объектов - все аналогично возможностям в консоли.
  • Log collection wizard - новый мастер, который собирает лог-файлы с защищенных хостов и подготавливает пакет, необходимый при обращении в техподдержку Veeam.
  • 1-click automated upgrade - все компоненты продукта, включая те, что установлены на удаленной площадке (backup
    proxy servers и backup repositories), могут быть просто обновлены с использованием мастера Upgrade wizard. При открытии консоли, Veeam Backup & Replication автоматически определяет компоненты решения, которые следует обновить.

Продукт Veeam Backup and Replication 6 должен быть доступен для скачивания с сайта Veeam ориентировочно в среду на странице загрузки продукта.

Несколько скриншотов. Восстановление файла резервной копии из результатов поиска в Enterprise Manager:

Настройки Traffic Throttling:

Мастер восстановления виртуальной машины Microsoftc Hyper-V:

Настройка бэкап-репозиториев:

Настройки Re-IP при восстановлении на резервной площадке:


Таги: Veeam, Backup, Update, VMware, vSphere, DR, ESXi, Storage, VMachines

1 | 2    >   >>
Реклама





Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

02/12/2017:  AZURE DAY 2017 (Минск)
06/03/2018:  ИТ-стратегия 2018
24/05/2018:  IT&SECURITY FORUM (Казань)

Быстрый переход:
VMware StarWind Veeam IT-Grad vGate Microsoft Cloud SDRS Parallels IaaS Citrix 5nine HP VeeamON VMFS RVTools PowerCLI VM Guru Oracle Red Hat Azure KVM VeeamOn Security Code 1cloud Docker Storage Offtopic NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo Nutanix vRealize VirtualBox Symantec Gartner Softline EMC Login VSI Xen Enterprise Teradici Amazon NetApp VDI Linux Hyper-V IBM Cisco Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Hardware Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell vSphere IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V VVols HA Tools Backup vSAN Book Photon vCloud VMworld Horizon vROPs Labs Fusion Cloud Computing vCSA SSD Client DRS OpenStack Comparison Workstation Blast SRM App Volumes Performance Manager Nested AWS Log Insight XenDesktop VSA vNetwork SSO LSFS Workspace Host Client VMDK VTL Update iSCSI SDDC NSX Agent Virtual Appliance Whitepaper PowerShell Appliance VUM V2V Cache Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance DR Vanguard SaaS Connector Event Free Datacenter SQL VSAN Lifecycle Sponsorship Finance FT Converter XenApp esxtop Snapshots VCP Auto Deploy SMB RDM Mirage XenClient MP Video Operations SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo Visio Intel vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Networking Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Forum Reporter vShield ACE Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Director Diagram Bug Troubleshooting Air API CLI Plugin DPM Memory Upgrade SIOC Flex Mac Open Source SSH VAAI Chargeback Heartbeat Android MSCS Ports SVMotion Storage DRS Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Сравнение Oracle VirtualBox и VMware Workstation.

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Как использовать возможности VMware vSphere Management Assistant (vMA).

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2017, Александр Самойленко. Правила перепечатки материалов.