We are having migration failures. The procedure was from section 3. “Migrate between hypervisors” (not a live migration). The error message is as follows:
# nova migrate --poll $u ERROR (BadRequest): No valid host was found. No valid host found for cold migrate (HTTP 400) (Request-ID: req-592d59db-9185-4775-b5e2-940aa657a62c)
* 0 : treated as unlimited. * Any positive integer representing maximum concurrent builds. """), # TODO(sfinucan): Add min parameter cfg.IntOpt('max_concurrent_live_migrations', default=1, help=""" Maximum number of live migrations to run concurrently. This limit is enforced to avoid outbound live migrations overwhelming the host/network and causing failures. It is not recommended that you change this unless you are very sure that doing so is safe and stable in your environment.
Live migration generates excessive network traffic. A live migration running at full speed can have a negative impact on the services that communicate over the same network; for example, the message queue. To set a lower maximum speed, use the following command:
# virsh migrate-setspeed domain speed_in_MBps
Alternatively, set the desired speed (again in MBps) beforehand. Example:
# openstack-config --set /etc/nova/nova.conf libvirt live_migration_bandwidth 50
libvirt改变vm 镜像的owner，除非监测到在共享存储上。libvirt有NFS, GFS2 and SMB/CIFS，但是没有Gluster。所以Gluster环境，libvirt不能检测出是在共享存储的环境，disk文件在成功迁移之后会被赋给back to root:root，然而destination host会将disk文件赋给libvirt-qemu:kvm。
stop your guests, then stop libvirt, and edit /etc/libvirt/qemu.conf - this contains a commented out entry ‘dynamic_ownership=1’, which is the default. Change this to 0, and remove the comment. Then do a chown to libvirt-qemu:kvm for all your stopped images. Then you can start the service libvirt-bin again, and bring up the guests. Repeat on the other half of your cluster, and test a live migration.
using libgfapi, giving libvirt direct access without having to go through the filesystem. This is the preferred setup for libvirt+gluster and should also result in better I/O performance.
When migrating an instance with multipathing configured, you need to ensure consistent multipath device naming between the source and destination nodes. The migration will fail if the instance cannot resolve multipath device names in the destination node.
You can ensure consistent multipath device naming by forcing both source and destination nodes to use device WWIDs. To do this, disable user-friendly names and restart multipathd by running these commands on both source and destination nodes:
# mpathconf --enable --user_friendly_names n # systemctl restart multipathd
原文发布于微信公众号 - 后端云（opnfv-tech）