[pve-devel] [PATCH v5 0/3] RFC: cloud-init update

[Alexandre DERUMIER]

>>3) do we really to define a special storage for hosting qcow2 ? maybe always store it in local storage and rsync it on live migration.
>>   (everybody don't have a nfs shared storage)

or,do you plan to use any storage instead qcow2 ? 
(we need snapshot feature on this cloud-init drive, if user make a vm snapshot ?)


----- Mail original -----
De: "aderumier" <aderumier at odiso.com>
À: "Wolfgang Bumiller" <w.bumiller at proxmox.com>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Mardi 30 Juin 2015 09:47:43
Objet: Re: [pve-devel] [PATCH v5 0/3] RFC: cloud-init update

also, 

I can compress cloud-init qcow2 to around 5K with compression and small cluster_size 

qemu-img convert -c vm-100-cloudinit.qcow2 -f qcow2 -O qcow2 test.qcow2 -o cluster_size=512b 

-rw-r--r-- 1 root root 5120 Jun 30 09:43 test.qcow2 



----- Mail original ----- 
De: "aderumier" <aderumier at odiso.com> 
À: "Wolfgang Bumiller" <w.bumiller at proxmox.com> 
Cc: "pve-devel" <pve-devel at pve.proxmox.com> 
Envoyé: Mardi 30 Juin 2015 08:44:17 
Objet: Re: [pve-devel] [PATCH v5 0/3] RFC: cloud-init update 

Hi Wolfgang, 

I begin to test your patches, 
seem to works fine here. 

I have some questions: 

1)-does it work with windows ? (as we expose the config drive as drive and not cdrom) 

2)-as we put it as ide3, it could break some guest disk drive order, if we don't use disk uuid in /etc/fstab 
for example : 
user have 2 virtio-scsi disk 
/dev/sda 
/dev/sdb 

with /etc/fstab 
/dev/sda / 
/dev/sdb /var 

now, with ide3, it's going to /dev/sda , as AFAIK, they are assigned by pci slots order. 

Maybe create a sata controller on the lastest pcislot/bridge could avoid that. (need to test qemu 2.4 sata migration) 

3) do we really to define a special storage for hosting qcow2 ? maybe always store it in local storage and rsync it on live migration. 
(everybody don't have a nfs shared storage) 


----- Mail original ----- 
De: "aderumier" <aderumier at odiso.com> 
À: "Wolfgang Bumiller" <w.bumiller at proxmox.com> 
Cc: "pve-devel" <pve-devel at pve.proxmox.com> 
Envoyé: Vendredi 26 Juin 2015 14:17:38 
Objet: Re: [pve-devel] [PATCH v5 0/3] RFC: cloud-init update 

Hi, 

>>For the UI enabling and disabling cloudinit would then be 
>>adding/removing a cloudinit device. It would then also not have to be 
>>hardcoded to ide3 but be configurable to any block device like when 
>>adding a hard disk. 

I'm not sure but I think than sata/ahci controller are now migratable in qemu master (so for qemu 2.4) 

http://git.qemu.org/?p=qemu.git;a=commit;h=04329029a8c539eb5f75dcb6d8b016f0c53a031a 

maybe we could add a dedicated sata controller for cloudinit drive ? 



----- Mail original ----- 
De: "Wolfgang Bumiller" <w.bumiller at proxmox.com> 
À: "pve-devel" <pve-devel at pve.proxmox.com> 
Envoyé: Vendredi 26 Juin 2015 12:36:52 
Objet: Re: [pve-devel] [PATCH v5 0/3] RFC: cloud-init update 

We just talked this over a bit again. 

If we keep going with this approach we could actually remove the 
cloudinit config parameter and, similar to what Alexandre did in the 
first patches, have an `ideX: cloudinit,storage=STOREID` parameter 
enable cloudinit (but have it fix in the config rather than added after 
doing `cloudinit: 1`). 
For the UI enabling and disabling cloudinit would then be 
adding/removing a cloudinit device. It would then also not have to be 
hardcoded to ide3 but be configurable to any block device like when 
adding a hard disk. 

We'd then still need a parameter for templates. (Either a new one like 
`cloudinit-template: xyz` or if we plan on adding more cloud-init 
parameters we could keep `cloudinit: variouts,comma=separated,args`. 

Another TODO before I forget about it again: physical cdrom drives 
probably don't need `media=cdrom` in the code. should check that. 

On Fri, Jun 26, 2015 at 12:06:31PM +0200, Wolfgang Bumiller wrote: 
> Changes since [PATCH v4]: 
> 
> Instead of generating a separate ISO image file we now generate the 
> ISO into a qcow2 device which is storage-managed. 
> This does not only mean we don't need to rsync the file for 
> live-migrations, but we can also use the live-snapshot feature out of 
> the box. 
> 
> It also allowed me to remove the code to generate the commandline 
> parameters by simply making foreach_drive include the cloud-init drive 
> (if it exists). 
> In order to do that I had to add a $vmid parameter to it. Since it 
> already takes the VM's config as parameter this seemed like a sane 
> thing to do. I grepped the rest of the repositories for code affected 
> by this change. It seemed to be all isolated in qemu-server. 
> 
> Please test and comment. 
> 
> Alexandre Derumier (1): 
> implement cloudinit v2 
> 
> Wolfgang Bumiller (2): 
> cloud-init changes 
> cloudinit: use qcow2 for future snapshot support 
> 
> PVE/API2/Qemu.pm | 16 +-- 
> PVE/QemuMigrate.pm | 8 +- 
> PVE/QemuServer.pm | 364 +++++++++++++++++++++++++++++++++++++++++++---- 
> PVE/VZDump/QemuServer.pm | 2 +- 
> control.in | 2 +- 
> 5 files changed, 353 insertions(+), 39 deletions(-) 
> 
> -- 
> 2.1.4 
> 
> 
> _______________________________________________ 
> pve-devel mailing list 
> pve-devel at pve.proxmox.com 
> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 
> 

_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 
_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 

_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 
_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel