+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Миграция не всегда показывает варианты хранения., Proxmox Виртуальная Среда

Korishan

Guest

08.05.2025 21:30:00

Переезжаю с одного pve-узла на другой. Запускаю миграцию, всё успешно переносит. А потом нужно перенести хранилище с одного узла на другой. Хранилище Node-A: Storage_PVE_1, хранилище Node-B: Storage_PVE_2. Так что после миграции приходится делать Volume Action -> Move Storage с Storage_PVE_1 на Storage_PVE_2. Но это не всегда так. Если возникает ошибка с доступным пространством, во время миграции появляется опция переместить на другое хранилище, Target Storage.

Почему опция выбора хранилища во время миграции не всегда отображается??? Есть ли способ, чтобы Target Storage всегда отображался?

fabian Guest	#2 0 09.05.2025 08:56:00 Пожалуйста, выложи содержимое storage.cfg и конфигурации VM для обеих виртуальных машин.

Korishan

Guest

09.05.2025 13:49:00

storage.cfg: Code: zfspool: storage1
disable
pool raid_storage
content rootdir,images
mountpoint /raid/storage1
sparse 0

dir: storage2
path /raid/storage1/storage2
content images,rootdir,iso,vztmpl
prune-backups keep-all=1
shared 0

dir: raid_storage
path /raid/storage1
content images,iso,vztmpl,backup,rootdir,snippets
prune-backups keep-all=1
shared 0

dir: hp2_proxmox
path /pools/pool_hp2_1/proxmox
content snippets,rootdir,vztmpl,iso,images,backup
prune-backups keep-all=1
shared 1
2011.conf (pihole): Code: agent: 1
boot: order=scsi0;ide2;net0
cores: 2
cpu: x86-64-v2-AES
ide2: none,media=cdrom
memory: 2048
meta: creation-qemu=9.2.0,ctime=1743868524
name: pihole-11
net0: virtio=BC:24:11:48:A2:FC,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: storage2:2011/vm-2011-disk-0.qcow2,iothread=1,size=32G
scsihw: virtio-scsi-single
smbios1: uuid=33d8e838-7187-4bb5-967c-8993828bedfd
sockets: 1
vmgenid: 263ab691-3596-4f9e-bd96-1f0f2cf8d43c
101.conf (Truenas): Code: gent: 1
boot: order=scsi0;ide2;net0
cores: 2
cpu: x86-64-v2-AES
ide2: none,media=cdrom
memory: 12288
name: TrueNAS
net0: virtio=BE:BC:D7:51:A2:C2,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: l26
scsi0: storage2:101/vm-101-disk-0.qcow2,size=32G
scsi1: storage2:101/vm-101-disk-1.qcow2,size=32G
scsi10: /dev/disk/by-id/wwn-0x5000c50085e8b5cf,size=3907018584K
scsi12: /dev/disk/by-id/wwn-0x5000c50085e895f3,size=3907018584K
scsi13: /dev/disk/by-id/wwn-0x5000c50085e828f7,size=3907018584K
scsi14: /dev/disk/by-id/scsi-35000c50085e90d73,size=3907018584K
scsi3: /dev/disk/by-id/ata-HGST_HDN726040ALE614_K7J1LGUL,size=3907018584K
scsi4: /dev/disk/by-id/wwn-0x5000c500c4c9db57,size=3907018584K
scsi5: /dev/disk/by-id/wwn-0x5000c500cf68bd87,size=3907018584K
scsihw: virtio-scsi-pci
smbios1: uuid=eb006c18-4cfd-4346-9088-5dc2eaf29085
sockets: 1
startup: order=2
vmgenid: 8b31d22b-05b8-43f1-b319-65a9d0f9f71a

fabian

Guest

09.05.2025 13:53:00

Второй гость использует pass-through диски, поэтому их нужно скопировать на другое хранилище. Ты уверен, что остальная твоя конфигурация верна? Потому что в твоем первом сообщении были другие названия хранилищ. В частности, если диски Pi-hole на самом деле находятся на hp2_proxmox, который помечен как общий, это объяснит, почему у тебя нет выбора целевого хранилища.

Korishan

Guest

09.05.2025 14:47:00

Это был просто пример. Был ещё один случай, где предлагались те же варианты, что и в 101. Названия хранилищ в исходном сообщении были примерами, а не реальными, потому что я писал очень быстро. Дело в том, что если размер ВМ больше доступного размера "по умолчанию" хранилища узла, к которому она переносится, у нас появляется опция выбрать "где" хранить диски. Но если это не так, этой опции вообще нет. У меня несколько хранилищ на Node 1 (pve-hp1), и если я пытаюсь перенести ВМ с Node 2 (pve-hp2) на Node 1, опция выбора места хранения дисков не появляется. "storage2" физически находится на pve-hp1. Когда я переношу ВМ/КТ на pve-hp2, диски "остаются" на storage2 вместо перемещения на "hp2_proxmox", который физически находится на pve-hp2. Посмотрев в GUI для получения большего количества деталей, я заметил, что pve-hp2 копирует имена хранилищ. Код: zfspool: storage1
disable
pool raid_storage
content rootdir,images
mountpoint /raid/storage1
sparse 0

dir: storage2
path /raid/storage1/storage2
content images,rootdir,iso,vztmpl
prune-backups keep-all=1
shared 0

dir: raid_storage
path /raid/storage1
content images,iso,vztmpl,backup,rootdir,snippets
prune-backups keep-all=1
shared 0

dir: hp2_proxmox
path /pools/pool_hp2_1/proxmox
content snippets,rootdir,vztmpl,iso,images,backup
prune-backups keep-all=1
shared 1 Не только это, но и хранит их на основном диске, из-за чего я заканчивал место. Папка "/raid" — точка монтирования zfs пулов на pve-hp1, но это не так на pve-hp2. Они хранятся под "/pools". Это добавляет к вопросу, почему мы не можем выбрать местоположение хранилища для переноса? И почему оно просто использует то же имя, из которого осуществляется перенос?

fabian

Guest

12.05.2025 08:36:00

Если хранилище доступно только на одном узле, нужно сообщить об этом PVE. Особенно это касается хранилищ типа "директория", иначе PVE просто создаст эти директории на всех узлах и будет использовать их как хранилище.

Korishan

Guest

12.05.2025 12:26:00

Хранилище доступно на обоих узлах. При миграции с одного узла на другой, система должна спрашивать, где хранить данные, а не предполагать, что это то же самое хранилище. Папки/имена хранилищ были созданы на pve-hp2 автоматически, когда он присоединился к кластеру. Я узнал об этом недавно, когда начал миграцию. Оба сервера находились в одном кластере в течение нескольких месяцев. Я понятия не имел, что каждому узлу в кластере должна быть присуща "абсолютно" одинаковая структура хранилища, чтобы всё работало корректно. Я видел много видео, где несколько узлов использовали разное оборудование. Не очевидно, что нужно конкретно ограничивать хранилище для определенных узлов. Теперь я понимаю, в чем проблема. Во-первых, pve автоматически создает папки для кросс-нодового хранилища, не уведомляя об этом пользователя. Также он не позволяет пользователю изменять хранилище во время миграции, "если только" данные миграции слишком велики, чтобы поместиться на этом конкретном хранилище, и тогда показывает список доступных вариантов хранилища. Во время миграции система должна всегда спрашивать пользователя, где он хочет хранить данные, а не предполагать, что это может быть только в том же месте хранения. Я вижу, что теперь мне нужно вернуться к настройкам хранилища для кластера и вручную указать, что все локации ограничены для каждого варианта хранилища

И изменение всех вариантов хранилища для pve-hp1, чтобы они были ограничены только этим узлом, заставляет вариант Target Storage отображаться:

ОДНАКО, он отображается только для работающих виртуальных машин! Если ВМ/CT не работает, я не получаю этой опции. И, собственно, я получаю совершенно другое сообщение об ошибке:

ПОЧЕМУ?!?!?! Почему здесь эти ограничения?? Это совершенно не имеет смысла. Мы должны иметь возможность мигрировать с одного узла на другой независимо от того, работает он или нет.

fabian

Guest

12.05.2025 12:58:00

Потому что миграция работающей VM или остановленной использует совершенно другой механизм миграции. Вы продолжаете создавать новые проблемы, не предоставляя необходимых деталей о конфигурации. Если хотите получить объяснение, пожалуйста, публикуйте:
- полный storage.cfg
- конфигурацию VM
спасибо!

Korishan

Guest

12.05.2025 13:26:00

Я уже выложил оба конфигурационных файла. Не думаю, что тебе нужны *все* мои файлы конфигурации VM. И единственное, чего нет в storage.cfg — это local и local-lvm хранилища. Я посчитал, что они довольно общие. Я не использую эти хранилища для VM/CT и отключаю их после установки PVE. Мне удалось мигрировать VM Pi-hole, но она работала. Странно, но это удалось сделать только после того, как я ограничил варианты хранилища в разделе Cluster Storage. Раньше миграция постоянно падала, потому что диск не существовал:

После ограничения хранилища до конкретных узлов появилась опция выбора места хранения, и я смог успешно мигрировать VM. Предыдущее изображение, показывающее варианты хранилища во время миграции, взято из этой миграции. Ты утверждаешь, что Live Migration и Offline Migrate — это разные методы. Ну да, я понимаю. Но обе опции миграции все равно должны предлагать возможность выбрать, где хранить мигрированные файлы. Не просто "предполагать" единственное место и не спрашивать пользователя, куда эти файлы отправляются. Target Storage всегда должен отображаться, даже если он автоматически заполнен местом по умолчанию.

fabian

Guest

#10

12.05.2025 13:46:00

Ты не выложил конфиг VM 2002. Это потому, что ты неправильно отметил хранилище как общее, как я тебе уже говорил в начале треда. Диск на общем хранилище вообще не мигрируется, отсюда и нет целевого хранилища для выбора. Кажется, твоё хранилище на самом деле не общее, значит, конфиг неверный. Опция появится, когда это будет иметь смысл. Если твои конфиги не позволяют миграцию с целевым хранилищем, то тебе и опцию не дадут.

Korishan

Guest

#11

12.05.2025 14:05:00

Все мои ВМ практически идентичны по конфигурации и аппаратному обеспечению. Единственное различие – ID, объем хранилища и распределение памяти/CPU. В остальном всё одинаково (если не считать ВМ Truenas, конечно). Проблемы возникают со всеми ВМ/CT, а не только с конкретными.

Я вынужден не согласиться. Единственным хранилищем, отмеченным как общее, было "hp2_proxmox". Остальные не были отмечены как общие. Значит, если "hp2_proxmox" было общим хранилищем, то оно должно было быть предпочтительным местом хранения.

Это не имеет смысла. Когда я изменил все места хранения и ограничил их для конкретного узла, опции хранилища появились. Но они отображаются только для Live Migration. Где находится настройка, чтобы включить Offline Migration??

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

Вот 2002.cfg, хотя он практически идентичен тому, что я публиковал ранее.

Code:
agent: 1
boot: order=sata0;ide2;net0
cores: 4
cpu: x86-64-v2-AES
ide2: none,media=cdrom
memory: 6144
name: guac
net0: virtio=C2:C0:F6:4F:F7:11,bridge=vmbr0,firewall=1
numa: 1
ostype: l26
sata0: raid_storage:2002/vm-2002-disk-0.qcow2,size=64G,ssd=1
scsihw: virtio-scsi-pci
smbios1: uuid=ee34b83d-e8e6-4208-8a13-4a647898bbaa
sockets: 1
vmgenid: dab660dd-c0c6-4e13-abe2-48d49abdf2c1

fabian

Guest

#12

12.05.2025 14:30:00

Снова-снова ты пометил хранилище как общее, хотя оно таковым не является. Ты нарушил инварианты, на которых работает PVE. Диск на общем хранилище вообще не мигрируется, потому что предполагается, что он уже существует на целевой стороне с тем же содержимым (иначе это не общее хранилище). Целевое хранилище показалось после того, как ты ограничил общее хранилище для исходного узла, потому что само хранилище больше недоступно на целевой стороне, и теперь диск нужно мигрировать. Мне кажется, у тебя фундаментальное недопонимание того, как работает конфигурация хранилищ в PVE, может быть, поможет, если это прояснить. У тебя есть два типа хранилищ: локальные и общие. Локальные хранилища имеют контент, специфичный для каждого узла (например, локальная директория, локальный пул ZFS), общие хранилища имеют идентичное содержимое на всех узлах, где они активированы (например, NFS-шара или распределённое хранилище, такое как Ceph). Общее хранилище обычно игнорируется для целей миграции. Использование локального хранилища означает, что диски должны быть мигрированы. Обычно у тебя есть одна запись storage.cfg для локального хранилища на каждом узле (например, у тебя есть одна запись local-lvm storage.cfg, даже если диск и VG на каждом узле отдельные). Так ты можешь мигрировать без необходимости "изменять" том. У тебя не должно быть X разных локальных хранилищ одного типа, ограниченных одним узлом каждый, если ты не хочешь указывать целевые хранилища для каждой операции.

Теперь вернёмся к твоему примеру: твой ВМ 2002 - не запущен - имеет один диск на локальном хранилище, ограниченном исходным узлом (если я правильно понял твои изменения - ты всё-таки не выложил текущий storage.cfg). Это означает, что требуется миграция диска в автономном режиме на другое хранилище. Это не отображается в UI (потому что использует другой механизм миграции, менее гибкий, чем живой), поэтому UI говорит тебе запустить ВМ, чтобы использовать живую миграцию, или проверить, есть ли у другого узла соответствующее хранилище (миграция в автономном режиме на то же хранилище). Ты можешь выполнить миграцию в автономном режиме с помощью API или CLI (если твоё исходное и целевое хранилище — это допустимая комбинация для данной конфигурации ВМ, то есть не все комбинации поддерживают все форматы дисков или снимки), что даёт тебе полный спектр опций без какой-либо "помощи".

fabian

Guest

#13

13.05.2025 15:05:00

Нет, это не так. Селектор целевого хранилища появится, если ВМ работает и имеет локальные диски. Он не появится, если одно из этих условий не выполнено (поскольку опция target-storage недоступна в UI для офлайн-миграций). Кроме того, целевой узел считается недействительным, если ВМ не работает, но используются локальные диски, и их хранилище недоступно на целевом узле (потому что опять же, это потребует офлайн-миграции с target-storage, который недоступен в UI). Как я уже говорил, сначала появилась живая миграция. Офлайн-миграция с локальными дисками и переключение хранилищ появились позже и никогда не были добавлены как функция в UI. Вероятно, сейчас она достаточно стабильна, чтобы ее можно было представить в качестве опции в UI, но этого шага еще не было сделано. Это относится к контейнерам, для которых живой миграции вообще нет. Ваши примеры, как и мои ответы, были все для ВМ. Код UI используется для обоих. Я попробую еще раз все для вас: вам следует реструктурировать ваш storage.cfg так, чтобы у вас был один "логический" пункт для вашего локального каталога хранения, который действителен для обоих/всех узлов. Содержимое этого хранилища будет отличаться на узлах, но это нормально — PVE знает, как с этим работать. Если вы используете ZFS для обоих узлов, то то же самое применимо и там (создайте ту же структуру пула/набора данных на обоих узлах и определите одно хранилище для этого). Тогда и онлайн, и офлайн-миграция должны работать и сохранять диски на том же хранилище. Если вы хотите изменить хранилище, вы можете использовать живую миграцию или функцию перемещения диска (или использовать qm migrate с --targetstorage ...).

Korishan

Guest

#14

12.05.2025 15:33:00

Хранилище не является общим. Я показал конфигурацию и скриншот хранилищ, и они не являются общими. ВМ/КТ были перенесены в папку с тем же именем, что и на pve-hp1. Они не хранились больше нигде. Да, я не понимаю, как происходит перенос хранилища. Это не имеет смысла, это не последовательно. Я пробовал несколько раз, и ни разу это не имело смысла. Хранилища, с которых я переношу, не являются общими. Хранилище, на которое я изначально переносил, было общим, однако я отключил эту настройку, и все равно не мог перенести на него. Возможность выбора пункта назначения миграции появилась только после того, как я изменил настройки хранилища для каждого контейнера хранилища на "Ограниченный" для каждого из узлов. И тогда она появилась только для ВМ/КТ, которые работали.

Исходный storage.cfg

Примечание: Storage2 не является общим.

Код: zfspool: storage1
disable
pool raid_storage
content rootdir,images
mountpoint /raid/storage1
sparse 0

dir: storage2
path /raid/storage1/storage2
content iso,images,vztmpl,rootdir
prune-backups keep-all=1
shared 0

dir: raid_storage
path /raid/storage1
content rootdir,snippets,backup,images,iso,vztmpl
prune-backups keep-all=1
shared 0

dir: hp2_proxmox
path /pools/pool_hp2_1/proxmox
content iso,vztmpl,rootdir,backup,snippets,images
prune-backups keep-all=1
shared 1

Измененный storage.cfg

Примечание: Ни одно из хранилищ не является общим.

Код: zfspool: storage1
disable
pool raid_storage
content rootdir,images
mountpoint /raid/storage1
nodes pve-hp1
sparse 0

dir: storage2
path /raid/storage1/storage2
content iso,images,vztmpl,rootdir
nodes pve-hp1
prune-backups keep-all=1
shared 0

dir: raid_storage
path /raid/storage1
content rootdir,snippets,backup,images,iso,vztmpl
nodes pve-hp1
prune-backups keep-all=1
shared 0

dir: hp2_proxmox
path /pools/pool_hp2_1/proxmox
content iso,vztmpl,rootdir,backup,snippets,images
nodes pve-hp2
prune-backups keep-all=1
shared 0

Единственное отличие сейчас в том, что к каждому хранилищу добавлено ограничение узла. До ограничения узла эти хранилища не отображались как возможный пункт назначения миграции. И вот что не имеет смысла. Интерфейс пользователя просто выполняет CLI для пользователя. Если он может сделать это для онлайн-миграции, почему он не может добавить это для оффлайн-миграции? В логах указано, что используется CLI. Интерфейс пользователя мог бы хотя бы сообщить нам об этих небольших деталях и сказать, что оффлайн-миграцию необходимо выполнять в CLI, если она не будет выполнена в интерфейсе. Единственная причина, по которой я установил одно из хранилищ как общее, была в том, что я думал, что это необходимо для разрешения единственной точки доступа, но разделенной между узлами. Т.е.: диск(ы) хранятся на узле-A, а конфигурация находится на узле-B. Она запускается с узла-B, извлекает необходимую информацию через сеть и выполняется на узле-B, но основное хранилище находится на узле-A. Я все еще не понимаю цель "Общий", даже не общие хранилища отображались на моем втором узле, когда он присоединился к кластеру. Папки создаются в корневой системе PVE-HP2 и разделяют емкость этого диска.

fabian

Guest

#15

13.05.2025 09:41:00

Понимаете, UI не выполняет CLI, он делает API-вызовы. И да, мы не выкладываем всё, что может API, на UI (из соображений удобства использования, или потому что некоторые API могут быть "опасны" для неопытных пользователей, или потому что мы ещё не считаем их достаточно стабильными для такого рода экспозиции). Миграция оффлайн-хранилища попадает в последнюю категорию – её изначально добавили как своего рода эксперимент, а потом постепенно она стала более стабильной. Сейчас она включена на UI, если вы не меняете хранилище. Вот что я пытался вам объяснить в своём предыдущем ответе.

Совместное хранилище требует, чтобы базовое хранилище представляло контент одинаково на всех узлах, где оно включено. Локальное хранилище – нет. Если вы настраиваете директорию на своём хосте как совместное хранилище, которое на самом деле локальное, вы обманываете PVE, и всё сломается (именно это вы и сделали, и из-за этого миграция не удалась, "потому что диск не существовал").

Что вы обычно делаете, если у вас есть совместное хранилище:
- Настраиваете совместное хранилище (например, настраиваете кластер Ceph, создаёте экспорт NFS/CIFS, и т.д.)
- Создаёте одну запись хранилища для этого хранилища
- Вы теперь увидите это хранилище на каждом узле, и содержимое и использование должны быть идентичными
- Теперь вы можете мигрировать, используя это хранилище, и PVE пропустит диски на нём, так как они уже "существуют" на целевом узле.

Что вы обычно делаете, если у вас нет совместного хранилища:
- Настраиваете директорию/LVM VG/ZFS pool/… на каждом узле (например, на локальном диске, смонтированном на /mnt/pve/foobar на каждом узле, или ZFS pool + dataset с одинаковым именем на каждом узле, или LVM VG с одинаковым именем на каждом узле)
- Создаёте одну запись хранилища для этих директорий/…
- Вы теперь "увидите" это хранилище на каждом узле, но содержимое и использование будут разными на каждом узле
- Теперь вы можете мигрировать, используя это хранилище, и PVE скопирует диски в качестве части миграции с одного узла на другой.

Если вы хотите переключить хранилище во время миграции (что нужно только если у вас разные записи storage.cfg для каждого узла!), вам нужно использовать API или CLI, или живую миграцию, где эта функция уже представлена на UI. Мы также представим выбор целевого хранилища для оффлайн-миграции в какой-то момент, но это не меняет того, что ваша текущая конфигурация была сломана и всё ещё нестандартна и неоптимальна.

Korishan

Guest

#16

13.05.2025 13:25:00

Но дело не в общем хранилище, в которое оно пыталось установить. Вот что я пытался объяснить. Хранилище, на котором оно находится (pve-hp1), не является общим. Я не знаю, почему вы постоянно об этом забываете и продолжаете утверждать, что это причина поломки. Ладно, теперь понятно. Проблема в том, что все хранилища отобразились на добавленном узле кластера. Неважно, были они общими или нет. Это одна из главных причин, почему все было так запутанно. Это также сбивает с толку, потому что целевое хранилище иногда отображается как доступное при определенных условиях, например, когда целевое хранилище по умолчанию не хватает места. Теперь я понимаю это гораздо лучше, спасибо, что все разобрали. Просто я бы хотел, чтобы все было немного понятнее, что происходит. Я не понимал, почему иногда отображался вариант целевого хранилища, а иногда нет. Это было не очень ясно.

fabian

Guest

#17

13.05.2025 13:59:00

В одном из ваших примеров диск находился на этом хранилище, из-за чего попытка завершилась неудачей — я же вам говорил, что это не проблема, так работают хранилища в PVE. Если вы явно не ограничиваете хранилище (неважно, локальное или общее), оно настроено для всех нод. Это настройка по умолчанию, и так вы должны настраивать хранилище, если нет причины отступать от этого (например, если у вас медленное локальное хранилище на всех нодах, а быстрое локальное хранилище на части нод, то это быстрое хранилище, очевидно, нужно ограничить только теми нодами, где оно существует. Или если половина вашего кластера использует LVM, а другая половина использует ZFS). Думаю, вы запутались из-за всех экспериментов и изменений конфигурации, ведь это не так. Есть API endpoint, который определяет, куда можно переносить ВМ: https://pve.proxmox.com/pve-docs/api-viewer/index.html#/nodes/ {node}/qemu/{vmid}/migrate он покажет, какие локальные диски или ресурсы настроены, и какие ноды разрешены или не разрешены в качестве целей миграции (и почему). Вы можете посмотреть здесь код, который реализует эту проверку: https://git.proxmox.com/?p=qemu-ser...98f6e858dcc475937d3e112793384ef;hb=HEAD#l4821 https://git.proxmox.com/?p=qemu-ser...d8ee180b21bef3636d2c0dab20e1bdb;hb=HEAD#l2632 обратите внимание, что там вообще нет проверок размера.. и вот здесь вы можете видеть, где в UI принимается решение о том, разрешена ли целевая нода или нет: https://git.proxmox.com/?p=pve-mana...5ce581168ffe7c2f254bfdf796255420;hb=HEAD#l226 и вот здесь вы можете видеть, как селектор целевого хранилища скрывается или становится видимым: https://git.proxmox.com/?p=pve-mana...d5ce581168ffe7c2f254bfdf796255420;hb=HEAD#l48

Korishan Guest	#18 0 13.05.2025 14:39:00 Storage2 оказался не общим хранилищем. Направляющее хранилище – то, на которое я переключил, чтобы проверить, позволит ли это отправить данные туда. Я не вносил больших изменений, если честно. Вот в чем дело. Я переключал хранилище на общий, это не работало, возвращал все обратно. Пытался мигрировать во время работы, опции не было. Пытался мигрировать во время выключения, опции тоже не было. Потом я наткнулся на VM, которая была слишком большой для хранилища по умолчанию, Storage2, и тогда опция появилась, и я понял, что выбор целевого хранилища вообще возможен. Самое большое, что я пока не понимаю, почему "Target Destination" не всегда отображается. Если она появляется, когда хранилище по умолчанию заполнено, то почему она не отображается всегда?? Это была самая большая проблема, которая привела меня сюда, чтобы спросить об этом. Даже если на бэкенде используются 2 разных API-вызова для выполнения работы, и даже если разница между Online/Offline существует, почему она не отображалась всегда? Похоже, что UI уже выполняет правильные вызовы в любом случае, проверяя наличие достаточного места или его отсутствие. Поэтому я был в замешательстве. Учитывая, что несколько проверок определяют, "работает" ли VM или нет, чтобы определить, можно ли ее мигрировать, я не понимаю, почему это должно быть ограничивающим фактором для отображения или отсутствия селектора хранилища. В чем разница между Online и Offline VM, кроме того, что одна использует активные ресурсы? Я бы подумал, что Offline было бы легче перемещать. В вызове "formulas" есть строка: "return gettext('Restart Mode');". Значит, в этом случае VM выключается, перемещается, а затем перезагружается. Фактически, VM временно переводится в режим Offline, а затем возвращается в Online после успешного перемещения. Просто хочу добавить, что я не пытаюсь досаждать, прошу прощения, если так кажется. Я пытаюсь лучше понять все это, плюс чтобы, если кто-нибудь еще столкнется с этой же ситуацией, они получили как можно больше информации в одной теме о том, что происходит, вместо того чтобы судорожно искать различные обрывки информации из других тем. Я ценю время, потраченное на показ фактического кода (даже если это немного моей "линии древа" для моего полного понимания).

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры