Our migration support in virt-manager needs some work. We are never going to be able to do this perfectly, since migration depends on external setup, and really isn't the focus of virt-manager. But there are a few easy-ish things we can do better: - Promote the 'tunnelled' option to above the 'Advanced options' fold. When properly configured, tunnelled migration can be easier for users, since it doesn't require opening any extra firewall ports. Then again, most virt-manager users use ssh for remote connections, and ssh doesn't play well with tunnelled migration. This all needs more thought. - If user selects tunnelled migration, and the remote connection is using ssh transport, show a small warning label explaining that the user libvirt is running as needs ssh keys configured for it to work. - Warn up front if libvirt is going to complain about CPU compat. Maybe point at the unsafe flag - True OFFLINE support: allow the migration dialog to launch when VM is offline, use the OFFLINE flag. - When the VM is migrated, if we were connected to the console/details view of the source VM, we should auto open the console/details of the destination VM. - We need to make sure the source VM is undefined by default. I don't think we even need to give a UI option to _not_ do this, since I'm not sure why anyone doesn't want to permanently migrate a VM, and anyways if we support OFFLINE migrate they can just move it back easy enough. - Warn if we know that networking will fail, and how it will fail. So, 'default' network will lose all active network connections for example.
*** Bug 733388 has been marked as a duplicate of this bug. ***
*** Bug 881092 has been marked as a duplicate of this bug. ***
Another thing to do would be to make sure that the storage is _actually_ available on both hosts. diskbackend.py:manage_path will auto setup a pool for a given path, so that could be used to introspect the remote host.
Also, I filed a separate bug to track wiring up storage migration: https://bugzilla.redhat.com/show_bug.cgi?id=1063027
Please, add two tick boxes: - One to keep the VM definition on source. When using virtlockd or sanlock, it's safe to have the VM defined on several hosts, and it makes it easier to restart the VM if one host crash - One to add --persistent (so the VM will be defined on the destination host, and not just transiant) Actually, I need both options, so I cannot use migration from the GUI and must use virsh instead. It'd even be better to have a way to set defaults for all migrations
(In reply to Cole Robinson from comment #0) > Our migration support in virt-manager needs some work. We are never going to > be able to do this perfectly, since migration depends on external setup, and > really isn't the focus of virt-manager. But there are a few easy-ish things > we can do better: > > - Promote the 'tunnelled' option to above the 'Advanced options' fold. When > properly configured, tunnelled migration can be easier for users, since it > doesn't require opening any extra firewall ports. Then again, most > virt-manager users use ssh for remote connections, and ssh doesn't play well > with tunnelled migration. This all needs more thought. > > - If user selects tunnelled migration, and the remote connection is using > ssh transport, show a small warning label explaining that the user libvirt > is running as needs ssh keys configured for it to work. > Upstream has a lot of warnings and suggestions in this area now, trying to detect when we know things will fail. > - Warn up front if libvirt is going to complain about CPU compat. Maybe > point at the unsafe flag > I didn't add this. It could be useful but I think libvirt's error here will be obvious enough that people can figure to go change their CPU model. > - True OFFLINE support: allow the migration dialog to launch when VM is > offline, use the OFFLINE flag. > Filed a separate bug to track this: bug 1214056 > - When the VM is migrated, if we were connected to the console/details view > of the source VM, we should auto open the console/details of the destination > VM. > Filed a separate bug to track this: bug 1214082 > - We need to make sure the source VM is undefined by default. I don't think > we even need to give a UI option to _not_ do this, since I'm not sure why > anyone doesn't want to permanently migrate a VM, and anyways if we support > OFFLINE migrate they can just move it back easy enough. > The new dialog defaults to using --undefine-source and --persist equivalents. There's an advanced option now 'temporary' which turns off those two flags. I think that covers the needed cases, but OFFLINE support might fill in the remaining gaps > - Warn if we know that networking will fail, and how it will fail. So, > 'default' network will lose all active network connections for example. If people are using the 'default' network for their VM, they aren't hosting any public services and therefore don't need really need consistent VM network connection, so I didn't add any explicit warning here. Closing this bug. If there's additional issues, we should track them individually