Hi all. The purpose of this mail is to get some feedback on pending cloud-init support in virt-install. If you're on the CC list here, I either pulled your email from a cloud-init discussion on the the virt-tools-list mailing list, or from the CC list of this virt-install bug: RFE: Provide cloud-init integration for VMs https://bugzilla.redhat.com/show_bug.cgi?id=981693 For GSOC 2019 Athina Plaskasoviti completed some cloud-init integration work in virt-install. You can read her wrap up here: https://athinapl.home.blog/2019/08/25/gsoc-2019-cloud-init-configuration-for-virt-manager-virt-install/ Right now the code is sitting in a virt-manager.git branch, not yet pushed to master: https://github.com/virt-manager/virt-manager/tree/cloudinit I'll summarize the current behavior, and then ask some questions. The branch adds a new 'virt-install --cloud-init' argument with several sub options. When specified, virt-install generates an empty meta-data file, a user-data file with the requested changes, stuffs them both into a cidata iso, which is used for the first VM boot and then deleted. This behavior is only triggered when --cloud-init is specified in some form, there's no automagic invocation of this support. The command sub options are: $ ./virt-install --cloud-init=help --cloud-init options: disable root-password-file root-password-generate ssh-key user-data Their behavior: * disable=yes: boolean option to disable cloud-init in the VM for subsequent boots. Adds this block to user-data: runcmd: - [ sudo, touch, /etc/cloud/cloud-init.disabled ] * root-password-file=/MY/PATH: set the desired root password from the content of /MY/PATH on the host * root-password-generate=yes: boolean option, generate a random root password, set it in user-data, print it to the host text console and pause for a bit for the user to see and copy it. sorta inspired by virt-builder * ssh-key=/MY/KEY.pub: inject the ssh key from /MY/KEY.pub on the host into the cloud-init user-data * user-data=/PATH/TO/user-data: ignore all other options and copy this file to the .iso as user-data When bare '--cloud-init' is specified, we default to generating a random root password and disabling cloud-init for subsequent boots: --cloud-init root-password-generate=yes,disable=yes We've explicitly rejected something like root-password=MY-PASSWORD because of the security implications of encouraging a password to end up in command line history. We've already had a CVE for something similar in virt-install. Also, I don't want virt-install to be in the business of specifying every cloud-init option under the sun, there's gotta be a better tool for that already. So I'd like to keep --cloud-init suboptions specifically targeted to expected virt use cases, and anything else can be served with custom user-data= One more point: my main interaction with cloud-init has historically been by grabbing a Fedora/RHEL cloud image, passing it to virt-install/virt-manager, and watching the boot hang, because there's no data provider and cloud-init times out talking to the network, and then I can't log in. I expect many people have hit this issue before. I've always worked around this by using 'virt-customize' to disable cloud-init and reset the root password. That's about the extent of my usage here, which is broadly why the bare `--cloud-init` is the way it was. I'm also thinking to the future, if one day virt-install can detect that it was passed a distro cloud-init image, perhaps we can invoke some default behavior that gives the user a better chance of this config being usable out of the box. I figure that will match whatever we choose for the bare '--cloud-init' behavior So, my questions are: * What are the usecases you see for virt-install cloud-init support? * Does the above meet your expectations? * Are we missing anything vital? * Do you have an opinion of what behavior bare '--cloud-init' should give? * Any other ideas, thoughts, feedback? Thanks, Cole _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
