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

[Wolfgang Bumiller]

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

I'm just worried that if they're not 100% the same on the destination
that qemu might choke on it?

--
On Mon, Jun 15, 2015 at 02:52:53PM +0200, Alexandre DERUMIER wrote:
> >>-) 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). 
>