VM migration: It's not intuitive with what user SSH key exchange should be set up

[skobyda]

Before migrating a VM between source and destination, an SSH key exchange between source and destination needs to be done in order to allow the transition of data between the 2 points. However, it's not really intuitive if you should set up SSH key exchange with other users (who is a sudoer) or root.

Example of a problem: 1) Have source and destination systems. 2) Both have cockpit installed. On both systems, you have user "sysadmin", who has administrative access, so you do SSH key exchange between both users. 3) Login to to cockpit as "sysadmin" with privileges. 4) When yoo attempt to migrate VM from source to destination host using URI qemu+ssh://[destination_IP]/system, you get: Cannot recv data: Host key verification failed: Connection reset by peer

The root of the problem: With URI qemu+ssh://[destination_IP]/system, libvirt tries to communicate with root, since system connection, which is specified in URI, is defaultly spawned by root. This is conflicting with a usual behavior of ssh, where if you try to connect with ssh [destinationIP] without specifying user on the destination, ssh will automatically assume there is the user with the same name as the one spawning ssh [destinationIP] on the source.

Some ideas what can we do about this problem:

• After user clicks on "Migrate", we can firstly check if host key verification is setup with correct user on the destination, and if not warn user about it, or even better: offer to set up it up for them
• We can remind user that with a URI qemu+ssh://[destination_IP]/system, they need to have key set upexchange with the root.

[skobyda]

@garrett mind giving your opinion here?

[garrett]

So, you're right: we need to make this friendlier, for sure.

• We need to make the requirements clear. That might mean we need a (?) icon with a popover explaining it. I don't think it does a very good job at explaining things as-is.
• If the protocol will always be the same, then we shouldn't require the user to type it. It should just be the host (hostname or address)
• I agree that we need to check that it is set up correctly and guide the user to success by helping them set up anything they might be missing.
• Alert errors should be at the top, not the bottom of a modal. This is a quick cosmetic fix we can handle in a PR that fixes the other issues.

Are the VMs always going to be system (and root), or will some be session (and user)? We can abstract the URL to have the correct protocol, the user@host, and system/session.

This means I think we probably want something like

• Host: hostname / ip address
• Connection type: system/user session
  • with a user field when user session is selected

If we can verify that things are set up properly on the host without having to submit, then we can also have a second set of setting up necessary configuration if it's not correct, otherwise skip it and migrate if it is set up. Kind of like a hybrid wizard concept, where there's only this modal when things are correct, otherwise, it's a two-step modal.

[kaechele]

In an ideal world, the Destination URI should be an editable dropdown that is pre-populated with any of the other hosts that are configured in Cockpit (and have cockpit-machines installed). Here is how virt-manager handles it utilizing the connections I have set up in it: