[virt-tools-list] virt-install and cloud-init, feedback wanted

[Dusty Mabe]

On 11/21/19 7:44 PM, Cole Robinson wrote:
> 
> How to handle ssh keys kinda makes my head spin. I've shrunk the CC list
> on this mail to just the folks that mentioned ssh in some way in their
> replies
> 
> If I'm thinking of the ideal interactive virt-install UI, it would be:
> 
> $ virt-install --name MYVM --disk Fedora-Cloud-...qcow2 --cloud-init
> INFO: SSH keys added to MYVM
> INFO: Connecting to MYVM with: ssh fedora at 192.168.122.XXX
> ...
> [fedora at localhost:~] $
> 
> 
> If all the pieces come together, that's pretty nice. But there's a lot
> of missing pieces needed for that, and some unclear bits:
> 
> * What is the cloud-init user name? Passing in an ssh key gives access
> to the default cloud-init configured username, which is different
> depending on the distro (might be fedora, ubuntu, etc). To properly
> handle this, we either need libosinfo distro detection, or use
> libguestfs to fish the default user out of /etc/cloud/cloud.cfg in the
> VM. And root account is typically locked, and ssh access disabled, and
> even if we could hack things to give root ssh access it seems like going
> against the grain WRT cloud images.

Another option is to add enough cloud config that adds a new user (call
it `virt`) with the specified ssh key. This can be slightly problematic
as it might not have the exact defaults that the distro would have provided
their user.

> 
> So best I can think of for an immediate solution for SSH is to print
> something explanatory:
> 
> INFO: you can ssh to the VM using the distro's default username. This is
> usually one of: fedora, ubuntu, ...

I think that's reasonable. We're already making the user experience much better
than it was in the past. This slight inconvenience isn't that much.

> 
> Or something along those lines. Maybe we can tie that into --os-variant
> as well so the user can inform us what distro it is. Still it will take
> some work.
> 
> * Where to get ssh keys from? You mention ssh-add -l which is nice, I
> didn't know about that. There's the issue with running virt-install
> under sudo, but not sure there's anything we can do about that to make
> it 'just work'. Sounds like `ssh-add -l` is the way though for some sort
> of ssh-key=auto mode
> 
> * What to do if we can't find any ssh-keys to add? I guess explicitly
> fail, and print a descriptive error: We didn't find any SSH keys to add.
> Maybe you are running under sudo. You can manually specify a key with
> XXX or generate root password with YYY. (something better than that of
> course)

I almost think that less magic here is better. Add the option to specify
where the pubkey file is. Also add an env var VIRT_INSTALL_SSH_PUBKEY that
one can use to specify that without having to do it on the command line
every time.

I guess detecting where keys are and using them is OK, but could get
confusing. Especially if you start to try to log in from another node
and you aren't sure what SSH key was used (I currently have 4 or 5 loaded
in my agent).

> 
> * virt-install support for launching an ssh session as the UI. This is
> probably worth doing regardless. I'd like to add an explicit
> --autoconsole none|graphical|text anyways, adding ssh to that seems
> reasonable. Requires waiting for VM IP address to pop up, but that
> shouldn't be too bad to implement. The main problem for the --cloud-init
> case is that I don't know if it makes sense to use this if we are just
> guessing about the what the default username is?
> 
> 
> So, to get that ideal UI, or at least point the user in the right
> direction, we need to:
> 
> * determine the default user name for the disk image, which we don't
> have a solution for presently
> * successfully inject a relevant ssh key, which may not be available
> like under sudo
> 
> So there's missing non-trivial work, and there's ways it can fail.
> 
> The current UI, with root-password-generate=on (plus some work to
> default to '--console text' when --cloud-init is passed), is more
> reliable as it should work in all situations, but even when it works
> it's not as friendly as the working ssh case (need to copy the printed
> password and paste it into a terminal). And it doesn't sound like it's
> what people expect the default to be. And giving root access seems to be
> against the spirit of the cloud images, but maybe that's just for ssh access
> 
> Maybe we shoot for the `--cloud-init ssh-key=auto` behavior as default,
> but just fail as descriptively as possible if all the pieces aren't in
> place. We can use the error to point people to manual cli workarounds,
> like specifying an ssh-key path, some cli way to specify the ssh
> username (--autoconsole ssh-user=FOO ?), or the root-generate-password=on
> 
> But I'm still kinda confused :) Ideas welcome.
> 
> Thanks,
> Cole
> 
> _______________________________________________
> virt-tools-list mailing list
> virt-tools-list at redhat.com
> https://www.redhat.com/mailman/listinfo/virt-tools-list
>