* Florian Weimer <fweimer@xxxxxxxxxx> [2019-11-21 02:40]: > * Cole Robinson: > > > 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. > > This is also my use case. 8-/ > > > 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 > > This goes probably in a different direction of what has been implement > so far, but would it actually harm to enable the network-based > instance-data injection by default? The advantage would be that it also > blocks these requests from leaking to untrusted parties, which could > then serve bogus data to compromise the virtual machine. cloud-init, since 17.1, will not attempt to query network end points for datasources unless it detects that it us running on such a platform. -- Ryan Harper Canonical, Ltd.
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
