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

[Alexandre DERUMIER]

>>-) 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, I think we can keep the configdrive mounted. (need to find a way for livemigration)
I don't known if we need to expose it in gui as a special cdrom?
Also Currently I'm usind ide3. I don't known if users would like to use it for hdd ?


>>-) 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.)

It could be great to get this working without shared storage
(For users with ceph/rbd, zfs iscsi shared storage for example).

I think that re-generate the configdrive on target host,with same config,should work.




----- Mail original -----
De: "Wolfgang Bumiller" <w.bumiller at proxmox.com>
À: "aderumier" <aderumier at odiso.com>
Cc: "dietmar" <dietmar at proxmox.com>, "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Lundi 15 Juin 2015 12:52:37
Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support

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). 
> 
> Ok. 
> 
> 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 
cloud-init support. 
-) 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.). 
-) 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 
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.) 

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 
above descrpition).