Наиболее частые проблемы с VMmanager и их решение

Материал из ISPWiki
Перейти к: навигация, поиск

Иерархия: VMmanager KVM -> FAQ
VMmanager Cloud -> FAQ

Проблемы с панелью управления

  • Обновление ПО кластера VMmanager KVM до VMmanager Cloud.

Такое обновление не поддерживается.

  • VMmanager зависает и тормозит, в логе фигурирует ошибка - too many connections.

Наиболее частой причиной такой проблемы является зависание libvirt. Проверьте, что libvirt отвечает, попробуйте его перезапустить.

  • Какие процессы важны для VMmanager? Что можно мониторить?

Важен процесс ihttpd. Также на серверах должен быть запущен libvirt.

  • Какие единицы измерения используются в панели?

В панели используются KiB и MiB

  • KiB (кибибайт) 2 в степени 10 = 1024;
  • MiB (мебибайт) 2 встепени 20 = 1048576.

Что отлично от привычных KB и MB:

  • MB (мегабайт) 10 в степени 6 = 1000000;
  • KB (килобайт) 10 в степени 3 = 1000.

Как формировать виртуальную машину оперируя MB и GB:

  • Если требуется создать виртуальную машину c 2Gb оперативной памяти, то в форме редактирования необходимо указать 1907MiB (точное значение 2GB = 1907,35MiB);
  • Если требуется создать диск виртуальной машины размером 15GB, то в панели необходимо указать 14305Mib;
  • Калькулятор величин.

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

  • 2 GiB = 2048 MiB;
  • 15 GiB = 15360 MiB;

Подробнее по данному вопросу: Двоичные_приставки

Проблемы с узлами кластера

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

При выдаче IP-адресов виртуальным машинам из той же подсети, в которой выделены IP-адреса для узлов кластера, возможна выдача IP-адреса присвоенного узлу кластера, вследствие чего узел будет недоступен. Чтобы этого избежать, зарезервируйте адреса узлов кластера в локальной базе IP-адресов или в IPmanager, если настроена интеграция.

Для освобождение занятого адреса виртуальной машиной, необходимо выделить для нее новый IP-адрес. Перейдите в список виртуальных машин, выберите нужную виртуальную машину и перейдите в "IP-адреса" ("Управление" -> "Виртуальные машины" -> выделите необходимую виртуальную машину -> перейдите на вкладку "IP-адреса"). Далее необходимо создать новый IP-адрес и удалить адрес, который пересекается с адресом узла кластера. Для использования виртуальной машиной нового IP-адреса, необходимо изменить настройки сетевого интерфейса и перезапустить сеть командой systemctl restart network.

  • Ошибка при добавлении узла кластера: "Ошибка установки пакетов 'vmmanager-kvm-pkg-vmnode' на удаленном сервере. Дополнительная информация доступна в журнале панели управления"

Причина: пакет libguestfs устанавливается только в интерактивном режиме.

Решение: установите пакет vmmanager-kvm-pkg-vmnode из консоли.

  • Не добавляется узел с операционной системой CentOS

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

  • Не добавляется узел. Ошибка: "Невозможно применить правила брандмауэра: ошибка в синтаксисе iptables"

В логах vmmgr.log при этом видно ошибку запуска скрипта /etc/libvirt/hooks/firewall.sh

# /etc/libvirt/hooks/firewall.sh
# Generated by VMmanager KVM on Сбт Апр 18 21:31:18 CEST 2015 *filter
# ISPsystem firewall rules
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-F INPUT
-F FORWARD

COMMIT --------------------------------
ip6tables-restore v1.4.7: ip6tables-restore: unable to initialize table 'filter'

Error occurred at line: 2
Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information.

Для решения данной проблемы необходимо закомментировать строки в /etc/modprobe.d/ipv6.conf, перезапустить модуль ipv6.

  • Утилиты управления кластером

Выполнение команды на всех узлах кластера:

/usr/local/mgr5/sbin/nodectl --op exec --target all --cmd 'echo "Hello, world!"' 

Переход по SSH на узел кластера:

/usr/local/mgr5/sbin/nodectl login <id узла кластера>

Посмотр списка узлов кластера:

/usr/local/mgr5/sbin/nodectl list

Только для VMmanager Cloud. Изменение мастер-узла (при этом изменяются приоритеты серверов и VMmanager запускается на указанном сервере):

/usr/local/mgr5/sbin/cloudctl -c relocate -m <id узла кластера>

Восстановление работоспособности в VMmanager Cloud

Восстановление виртуальных машин

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

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

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

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

Процедура восстановления логируется в общем логе VMmanager - vmmgr.log, запись в логе при восстановлении машины:

Restore vm $id

где id - это номер виртуальной машины в базе данных VMmanager (база данных mysql - vmmgr, таблица vm).

Восстановление узла кластера

Узел кластера считается отказавшим и отсоединяется от кластера, если он не отвечает более 1 секунды. Обратите внимание, что перезагрузка сервера длится дольше. В связи с этим необходимо учитывать, что после перезагрузки узел кластера потребуется восстанавливать. Нельзя одновременно перезагружать узлы кластера таким образом, что количество продолжающих работать узлов будет меньше кворума.

После того, как узел кластера оказался недоступным, система corolistener изменяет файлы конфигурации на всех живых узлах кластера. Для последующего восстановления узла кластера необходимо:

  • Убедиться, что все сервисы на узле функционируют в штатном порядке;
  • Вернуть узел в кворум с помощью кнопки "Присоединить", доступной в разделе "Настройка кластера" -> "Узлы кластера":
  • Синхронизировать конфигурационный файл corosync с другими узлами:
/usr/local/mgr5/sbin/mgrctl -m vmmgr cloud.conf.rebuild
  • Запустить систему corosync:
/etc/init.d/corosync start
  • Запустить сервис corolistener:
/usr/local/mgr5/sbin/corolistener -c start

Восстановление кластера после потери кворума

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

Алгоритм восстановления кластера:

  • На мастер-узле необходимо:
1. Удалить опцию "Option ClusterEnabled" из файла /usr/local/mgr5/etc/vmmgr.conf;
2. Убедиться в наличии файла /tmp/.lock.vmmgr.service. Если файл отсутствует, его необходимо создать:
touch /tmp/.lock.vmmgr.service
3. Добавить IP-адрес лицензии на интерфейс vmbr0:
ip addr add <IP-адрес> dev vmbr0
  • На узлах кластера необходимо:
1. Убедиться в наличии файлов /usr/local/mgr5/var/disable. Если файл отсутствует, его необходимо создать:
touch /usr/local/mgr5/var/disable
2. Убедиться в отсутствии файла /tmp/.lock.vmmgr.service. Если файл присутствует, его необходимо удалить:
rm /tmp/.lock.vmmgr.service
3. Убедиться в отсутствии на интерфейсе vmbr0 IP-адреса лицензии.
  • Запустить панель управления;
  • Включить облачные функции в интерфейсе панели управления.

Проблемы с хранилищами

Проблемы с LVM-хранилищем

  • Невозможно создать хранилище с типом LVM

При попытке добавить новый узел в кластер иногда возникает ошибка "unsupported configuration: cannot find any matching source devices for logical volume group".

Убедитесь, что команды LVM показывают, что физические тома, которые планируется добавить, действительно существуют и хранилище работоспособно. Попробуйте удалить хранилище и узел кластера и добавить заново:

virsh pool-undefine название-хранилища.

Проблемы с сетевым LVM-хранилищем

  • Не удаётся обнаружить группу томов на узлах

Если команда vgs на узлах не отображает группу томов LVM с iSCSI-хранилища, необходимо проверить, работает ли с ней iscsi-target. Для этого на узле таргета выполнить следующую команду:

tgtadm -m target --op show

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

tgtadm -m logicalunit --op new --tid 1 -b /dev/sda2 --lun 1

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

  • Проблема при подключении нового узла кластера

Если после внесения изменений в файл /etc/tgt/targets.conf (например, требуется подключить еще один узел и был добавлен еще один initiator-address) узел не удается подключить (команда 'iscsiadm -m discovery -t st -p ...' возвращает iscsiadm: No portals found), причина, скорее всего, заключается в том, что сервис фактически не перезапускается и не перечитывает конфигурационный файл, пока к нему подключены клиенты.

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

service tgtd stop
killall -9 tgtd
service tgtd start

Внимание! Команда 'killall -9 tgtd' уничтожит процессы сервиса tgtd, при этом возможна потеря данных.

Проблемы с iSCSI-хранилищем

  • Requested operation is not valid: storage pool is not active

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

[root@free ~]# virsh  pool-list --all
Имя               Статус Автозапуск
-----------------------------------------
File                 активен yes       
iSCSI-UGLY_004       не активен yes

Если присутствует строка вида iSCSI-UGLY_004 не активен yes, то можно попробовать удалить это хранилище и добавить узел еще раз:

root@free ~]# virsh pool-undefine iSCSI-UGLY_004
Определение пула iSCSI-UGLY_004 удалено
  • internal error Child process (/sbin/iscsiadm --mode discovery --type sendtargets --portal xxx.xxx.xxx.xxx:3260,1) status unexpected: exit status 255

VMmanager не может подключиться к серверу с iscsi по 3260 порту. Причин может быть несколько:

1. SELinux должен быть отключен;

2. Нужный порт закрыт в файрволе.

  • operation failed: Storage source conflict with pool: '...'

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

Решение: Найти и удалить существующее хранилище на всех нодах:

virsh pool-list
virsh pool-dumpxml <pool-name>
virsh pool-destroy <pool-name>
virsh pool-undefine <pool-name>

Проблемы с RBD-хранилищем

  • Ошибка при добавлении хранилища на узел кластера:
# ceph auth get-or-create client.vmmgr mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=isptest'
key for client.vmmgr exists but cap osd does not match

Решение: Необходимо зайти на монитор и удалить пользователя client.vmmgr

# ceph auth del client.vmmgr
  • Требуется сменить IP-адрес Ceph-монитора

Для создаваемых виртуальных машин: Непосредственно на самом Ceph-мониторе IP-адрес может быть изменен вручную администратором ceph-хранилища. В базе MySQL vmmgr на мастере VMmanager в таблице metapool необходимо заменить поле srchostname на новый узел. В таблице rbdmonitor убедитесь, что значение "metapool" соответствует значению "id" из таблицы metapool. После правки базы удалите кэш:

rm -rf /usr/local/mgr5/var/.db.cache.vm*

и перезапустите панель

killall core

Для существующих виртуальных машин:

sed -i 's/old_IP/new_IP/g' /etc/libvirt/qemu/*.xml
virsh define /etc/libvirt/qemu/*.xml

Проблемы с GlusterFS-хранилищем

  • При размещении двух хранилищ VMmanager в одном и том же томе и директории GlusterFS, но с разными типами (QCOW2 и RAW) невозможно выполнить перемещение виртуального диска между этими хранилищами

Используйте разные директории на сетевом хранилище для избежания такой ситуации.

  • Импорт виртуальных машин из другого VMmanager или из другого сервера с libvirt напрямую в хранилище GlusterFS не работает, так как драйвер libvirt не поддерживает запись содержимого диска из потока

Для решения проблемы при определении параметров импорта укажите перенос в хранилище другого типа, а затем переместите диски импортированных машин в хранилище GlusterFS.

Проблемы с NFS-хранилищем

  • Проблема при создании виртуального диска

Если libvirt не может создать образ в хранилище, а в логе /var/log/syslog присутствуют подобные строки:

rpc.idmapd[706]: nss_getpwnam: name 'root@testers' does not map into domain 'ispsystem.net'.

Проблема решается путем указания в файле /etc/idmapd.conf на сервере и клиенте корректного и совпадающего параметра "Domain". После редактирования необходимо перезагрузить сервер и клиент и повторно добавить хранилище в VMmanager.

  • Проблема при удалении данных из хранилища

Если диски, созданные в хранилище NFS, не удаляются с ошибкой:

Ошибка libvirt при выполнении операции "VolDelete": "cannot unlink file '/nfs-pool/volume': Permission denied"

В /var/log/messages содержится подобное сообщение:

Sep 16 13:11:07 client nfsidmap[7340]: nss_getpwnam: name 'www-data@lan' does not map into domain 'localdomain'

Проблема решается путем указания в файле /etc/idmapd.conf на сервере и клиенте корректного и совпадающего параметра "Domain". После редактирования необходимо перезагрузить сервер и клиент и повторно добавить хранилище в VMmanager.

Проблемы с виртуальными дисками

  • Ошибка libvirt при изменении размера диска

Ошибка libvirt при выполнении операции "Grow": "unknown procedure: 260".

Данная ошибка чаще всего возникает из-за устаревшей версии libvirt. Обновите libvirt.

  • Ошибка "Не удалось примонтировать диски виртуальной машины" при смене пароля

Проблема проявляется при попытке сменить пароль для виртуальной машины с файловой системой XFS внутри, размещенной на хост-сервере с ext4 и ядром версии менее 3.10. Для более точной диагностики запустите вручную guestmount -v -x -a <образ_диска> -i <путь к точке монтирования>. Если в выводе видны сообщения "mount: wrong fs type, bad option, bad superblock", то работа с этой машиной с помощью libguestfs невозможна. Причина - неполная поддержка гостевой xfs в ядре RHEL/CentOS 6. Подробности по ссылке: virt-inspector can't obtain info from rhel7.3 guest image on rhel6.9 host. К сожалению, по заявлениям разработчиков libguestfs, это поведение не может быть исправлено.

Проблемы с настройкой сети

  • IPv6 на Ubuntu 12.04

При добавлении узла кластера с IPv6-адресом выводится ошибка:

"Невозможно подключиться к серверу XXX. Возможно, на сервере не работают службы ssh или libvirt-bin"

В логах:

Mar 13 13:26:09 [2157:0x95E700] virt TRACE ErrorCallback libvirt error code=38 message=Cannot recv data: ssh: external/libcrypto.so.1.0.0: 
no version information available (required by ssh)
: Connection reset by peertname [2a01:230:2:3::3]: Name or service not known
Mar 13 13:26:09 [2157:0x95E700] virt DEBUG vir_host.cpp:70 Connect to qemu+ssh://[2a01:230:2:3::3]/system?keyfile=etc/ssh_id_rsa
Mar 13 13:26:09 [2157:0x95E700] err ERROR Error: Type: 'vir_connection'
Mar 13 13:26:09 [2157:0x95E700] virt TRACE Fail libvirt message: 'Cannot recv data: ssh: external/libcrypto.so.1.0.0: no version 
information available (required by ssh)

Данная ошибка является багом Ubuntu 12.04. Ссылка на launchpad

Решение: Добавлять узел с IPv4 адресом.

Проблемы с виртуальными машинами

  • Ошибка при создании виртуальной машины: "ERROR: Exception 1: Insufficient RAM for VM creation", хотя в Swap еще достаточно оперативной памяти

Свободная оперативная память - это free + cached. Swap не учитывается.

  • Виртуальная машина недоступна после перезагрузки

Проверьте следующие моменты:

1. Узлы кластера должны иметь связь с мастер-сервером (сервером, где находится VMmanager);

2. Сервис vmwatch-master на мастер-сервере слушает нужный IP-адрес (ip адрес определяет параметр VmwatchListenIp. Только для VMmanager KVM). Если адрес не задан явно, используется адрес подключенного локального узла кластера, если локального узла кластера нет, используется первый IP первого интерфейса. После изменения конфигурации необходимо запустить переконфигурирование сервисов из консоли командой /usr/local/mgr5/sbin/mgrctl -m vmmgr vmwatch.configure.

  • При попытке создания виртуальной машины возникает ошибка

Ошибка libvirt при выполнении операции "Start": "internal error Process exited while reading console log output: qemu-kvm: -chardev pty,id=charserial0: Failed to create chardev"

Для решения проблемы нужно выполнить mount -n -t devpts -o remount,mode=0620,gid=5 devpts /dev/pts.

  • При попытке создания виртуальной машины возникает ошибка

Ошибка libvirt при выполнении операции "Start": "internal error cannot create rule since ebtables tool is missing."

Проверьте вывод команды lsmod |grep ebt - если нет результата, значит, в ядре нет поддержки ebtables. Нужно либо пересобрать ядро, либо скачать другое и правкой grub.conf изменить порядок загрузки.

Проблемы с установкой операционной системы

  • Установщик не может скачать файл ответов

Данная ошибка может быть обнаружена при подключении к виртуальной машине по VNC.

Причин может быть несколько:

1. IP-адрес виртуальной машины не может быть прикреплен к узлу кластера, на котором эта машина создана. Так бывает, например, если IP-адреса в дата-центре привязаны к MAC-адресам;

2. Не работает резолвер на виртуальной машине. В качестве резолвера прописывается первый резолвер с родительского сервера (файл /etc/resolv.conf);

3. VMmanager пытается предоставить файл ответов по внутреннему IP-адресу, который не доступен снаружи, а установщик скачивает файл ответов через внешнюю сеть;

4. В настройках ihttpd настроен redirect для http-соединений.

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

/usr/local/mgr5/sbin/ihttpd

Берется верхний из списка, подходящий по протоколу. Если эта команда показывает верхним внутренний IP-адрес, установщик не сможет получить файл ответов. Сконфигурируйте ihttpd согласно статье Настройка_встроенного_веб-сервера_(ihttpd), первым указав внешний IP-адрес.

  • Не удается полностью получить preseed-файл при установке Debian

Для решения необходимо убрать опцию "nocunked" в файле конфигурации ihttpd - /usr/local/mgr5/etc/ihttpd.conf

После этого перезапустить сервис ihttpd.

  • Проблемы с установкой Windows 2016 на виртуальной машине: В VNC наблюдается, что установка зависла на этапе загрузки

Встречается на серверах с версией QEMU 1.5, 0.12, 1.1.2.

Решение: при создании виртуальной машины включить режим эмуляции процессора host-passthrough. Для QEMU 2.6 установка этих шаблонов работает без необходимости изменения режима эмуляции, но иногда может потребоваться перезапуск службы libvirt (service libvirtd restart) (если было обновление системы).

  • При установке FreeBSD-amd64 на некоторых типах процессоров могут возникнуть проблемы:
  • Установка зависает;
  • При подключении по VNC наблюдается следующее:
Ошибка установки FreeBSD
  • Нет реакции на нажатие клавиш;

В таких случаях рекомендуется использовать образы FreeBSDx32. Также для решения проблемы помогает установка http://elrepo.org/tiki/kernel-lt.

Проблемы с миграцией виртуальных машин

  • Ошибка, возникающая при живой миграции: virt TRACE ErrorCallback libvirt error code=38 message=Unable to read from monitor: Connection reset by peer

Такая ошибка возникает в некоторых конфигурациях с версией libvirt 0.9.12.3 при выборе типа сетевого интерфейса виртуальной машины "virtio". Для успешной живой миграции в настройках сетевого интерфейса виртуальной машины требуется указывать модель эмулируемого сетевого устройства отличную от "virtio", например "e1000". Для изменения этого параметра у существующей виртуальной машины, потребуется ее перезагрузка.

  • internal error: unable to execute QEMU command 'migrate': this feature or command is not currently supported

Данная ошибка возникает при попытке мигрировать включенную виртуальную машина на кластере с CentOS-7. Это вызвано ошибкой QEMU на CentOS-7.

Возможные пути решения:

  1. . Отключить виртуальную машины и мигрировать в выключенном состоянии;
  2. . Установить QEMU из репозитория centos-release-qemu-ev:

Все команды выполняются в консоли каждого узла кластера от имени суперпользователя (root)

yum install centos-release-qemu-ev
yum update

Предупреждение: будут обновлены все установленные пакеты, для которых доступно обновление.

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

libcacard-ev
qemu-img-ev
qemu-kvm-common-ev
qemu-kvm-ev
qemu-kvm-tools-ev

После обновления QEMU/KVM следует перезапустить виртуальные машины и сервис libvirtd.

  • Ошибка миграции и резервного копирования для виртуальных машин с диском qcow2 на серверах с версией QEMU 2.6

Не создаются резервные копии и не выполняется миграция виртуальных машин с виртуальным диском qcow2 и созданным внутри снапшотом во включенном состоянии. Версия QEMU 2.6, версия libvirt 2.0.

Данная проблема является ошибкой QEMU 2.6. Исправление вошло в QEMU 2.7.

Возможные пути решения:

  • Перезагрузка виртуальной машины. После перезагрузки можно продолжать работу;
  • Обновление QEMU до версии 2.7. Этот вариант не тестировался и не гарантируется его эффективность. Используйте на свой страх и риск.
  • В процессе миграции виртуальной машины размер диска LVM незначительно изменяется в большую сторону

Данная проблема является ошибкой QEMU: https://bugs.launchpad.net/qemu/+bug/1449687 https://bugzilla.redhat.com/show_bug.cgi?id=1219541

Исправить ее можно только в QEMU. Варианта два: мигрировать выключенную машину или использовать qemu-img convert после миграции для уплотнения диска.

  • Attempt to migrate guest to the same host

Если миграция виртуальной машины не происходит и в логе var/migratevm.log появляется данная ошибка, то причины могут быть следующие:

  • На узлах кластера установлен один и тот же hostname.

Решение: Исправить hostname. Отредактируйте файлы /etc/hostname и /etc/hosts, замените в них старое имя сервера на новое.

  • Узлы кластера имеют одинаковый product_uuid.

Чтобы проверить, запустите

cat /sys/class/dmi/id/product_uuid 

на всех узлах. Если значения совпадают, то проблема действительно в одинаковом product_uuid.

Решение: На узлах кластера, у которых совпадают product_uuid, необходимо отредактировать файл /etc/libvirt/libvirtd.conf: раскомментируйте строку

#host_uuid = "00000000-0000-0000-0000-000000000000"

Значение host_uuid заполните самостоятельно. Значение не может состоять из всех одинаковых цифр. Для создания uuid можно использовать утилиту uuidgen.

После этого необходимо перезапустить Libvirt.

  • Ошибка libvirt при выполнении операции "Define": "unknown OS type hvm"

В большинстве случаев проблема решается перезагрузкой сервера. Также рекомендуется проверить: 1. Включена ли аппаратная виртуализация в BIOS:

modprobe kvm
egrep '^flags.*(vmx|svm)' /proc/cpuinfo
Если ответ пустой, то виртуализация отключена, необходимо включить.

2. Статус службы kvm (должна быть включена):

service kvm status
  • Миграция виртуальной машины <наименование vm> невозможна: происходит процесс резервного копирования

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