[pve-devel] RFC: qemu-server : add cloudinit support
w.bumiller at proxmox.com
Mon Jun 15 12:52:37 CEST 2015
On Mon, Jun 15, 2015 at 12:07:34PM +0200, Alexandre DERUMIER wrote:
> >>Yes, but for firewall we want to force a specific IP (instead of reading them from guest).
> It's possible to use cloud-init to manage ip.
> generate a cloud-init config with different uuid, if the ip is changed in gui, on next reboot.
> Anyway, I don't think that cluster admin allow users to change ip on their host.
> And with pve-firewall, ip filtering should be enable by default if we have the ip defined.
There could be a button/option to apply ip changes to the firewall for a
running guest in case the guest doesn't want to reboot. But that can be
added later anyway.
Here's the current data I gathered:
-) From the UI perspective, the IP address configuration for cloud-init
could be done in the network device's configuration.
-) AFAIK there are ebtable patches to do filtering by mac address around
which are still pending.
-) Similar to the MAC firewall rules the host can then activate IP
firewall rules for the guest system when the VM is booted with
-) We don't really like the whole "rebooting after configuration"
option. It could be an optional flag, but ideally the user only needs to
boot once, and since the IP options are always available in the GUI it
also wouldn't be harmful to always include the cloud-init drive. This
also improves compatibility to "default installations" of cloud init
(like on ubuntu where it otherwise by default tries to connect to a
-) From the CLI and configuration side: cloning would need an option to
change the IP by network-interface.
-) For migration support: if we by default keep the config drives around
they need to be stored somewhere on a shared storage. So we need an
option to configure which storage the ISOs end up on. Then they'd appear
in the template/iso/ directory of the configured storage, which has to be a
shared one if you want to be able to migrate. The images are tiny anyawy
(more filesystem overhead than actual data when they only contain
-) Instance ID: VMs need a counter which is bumped at boot time when
there have been changes since the previous boot (or just bump on every
change, that's easier to implement :P). Cloning needs to reset or bump
the counter as well. (Reset if the source's counter is > 1, or bump to 2
if it's still 1 etc.)
Did I miss anything?
Once we all agree on the general course of action I would start pulling
patches together (firewall patch + cloud init + do the changes for the
More information about the pve-devel