Вы смешиваете два разных соединения.
Параметр libvirtd.conf относится к IP-адресу, который прослушивает демон libvirtd. По умолчанию это 16514 для соединений TLS, 16509 для простых соединений TCP и включается путем передачи флага --listen в libvirtd.
.
Учитывая, что ваш URI указывает протокол qemu+ssh://, вам не нужно libvirtd для прослушивания любого сетевого порта. Соединение libvirtd будет туннелироваться через соединение SSH с использованием netcat.
Ошибка, которую вы можете получить, на самом деле исходит от самого QEMU. Когда libvirt запускает миграцию, она должна выделить порт для QEMU узла назначения, чтобы принять входящую миграцию из QEMU узла источника. Они выделяются из диапазона 49152 -> 49252.
Учитывая, что сообщение от исходного QEMU о том, что он не может подключиться к целевому QEMU, наиболее вероятной проблемой является то, что у вас есть правила брандмауэра, блокирующие порты TCP 49152 -> 49252.
Вы можете открыть брандмауэр, чтобы разрешить эти порты. В качестве альтернативы вы можете указать libvirt туннелировать поток данных миграции QEMU через соединение libvirtd, что устраняет необходимость в открытых портах. Это можно сделать с помощью --tunnelled arg до virsh migrate
Также помните, что ваши настройки хранилища не поддерживаются libvirt. Нельзя, чтобы один хост обращался к хранилищу как к локальной файловой системе, а другой хост обращался к хранилищу как к файловой системе NFS. Это приведет к разрешению проблем, которые могут привести к сбою миграции в конце.
Либо оба хоста должны обращаться к образу через NFS, либо ни один из хостов не должен использовать NFS. Если вы не используете NFS, вы можете передать аргументы в virsh migrate, чтобы указать ему копировать содержимое файла хранилища.