[pve-devel] RFC: qemu-server : add cloudinit support

[Alexandre DERUMIER]

Hi,

>>I suppose that would work. But you might want to reinitialize a guest
>>with old settings if you screwed them up inside the guest. Maybe a
>>user-configurable ID or name of some sort? (The instance id needs to
>>change in order for cloud-init to pull the configuration. It does seem
>>to load some user-data even when the id doesn't change, but not the
>>configuration and meta-data.)

I would like to known when do you want to generate the cloudinit iso.

If user change settings (ips,hostname,...), do we want to apply them directly to configuration ?
or do we want to put them as pending ?  (for ip can be ok, for hostname that seem strange if user want to rename his vm).

Advantage to pending, is that we can simply regenerate the iso at vmstart if pending changes exist.
and user can also revert with if wrong settings.



----- Mail original -----
De: "Wolfgang Bumiller" <w.bumiller at proxmox.com>
À: "dietmar" <dietmar at proxmox.com>
Cc: "aderumier" <aderumier at odiso.com>, "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Mardi 16 Juin 2015 07:56:36
Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support

> > -) 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.) 
> 
> Can't we simply generate a digest including all cloudinit configuration values? 

I suppose that would work. But you might want to reinitialize a guest 
with old settings if you screwed them up inside the guest. Maybe a 
user-configurable ID or name of some sort? (The instance id needs to 
change in order for cloud-init to pull the configuration. It does seem 
to load some user-data even when the id doesn't change, but not the 
configuration and meta-data.) 

On Mon, Jun 15, 2015 at 04:55:57PM +0200, Dietmar Maurer wrote: 
> > 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. 
> 
> re-thought this, and I think this is an unrelated feature. But we also want 
> to integrate this in new 4.0 release. 
> 
> > -) Similar to the MAC firewall rules the host can then activate IP 
> > firewall rules for the guest system when the VM is booted with 
> > cloud-init support. 
> 
> We already have special 'ipfilter' ipsets: 
> 
> https://pve.proxmox.com/wiki/Proxmox_VE_Firewall 
> 
> So we can just add those IPs to the 'ipfilter' ipset (automatically). 
> 
> > -) 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 
> > magic IP.). 
> 
> Yes, we need a way to configure some behavioral cloud-init option, 
> for example: 
> 
> cloudinit: mode=[never|always|once],template=/etc/pve/cloudinit/test 
> 
> 
> > -) From the CLI and configuration side: cloning would need an option to 
> > change the IP by network-interface. 
> 
> yes, but this looks challenging to me - it will be difficult to provide 
> a nice GUI for that. 
> 
> > -) 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 
> > network configuration.) 
> > -) 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.) 
> 
> Can't we simply generate a digest including all cloudinit configuration values?