>>Yes, because of the second condition: >>«2. Must be a un-partitioned block device (/dev/vdb, not /dev/vdb1)» >> >>Qemu's vvfat includes an MBR with the filesystem being the first partition. >>In my tests the second condition doesn't apply if it has a label, at least on >>linux.
Ok. with cdrom it seem to work without label (tested with debian) the code is here: https://github.com/number5/cloud-init/blob/74e61ab27addbfcceac4eba254f739ef9964b0ed/cloudinit/sources/DataSourceConfigDrive.py I don't have read it yet. can you send qemu patch and qemu-server patches ? I would like to test it with windows. ----- Mail original ----- De: "Wolfgang Bumiller" <w.bumil...@proxmox.com> À: "aderumier" <aderum...@odiso.com> Cc: "pve-devel" <pve-devel@pve.proxmox.com>, "dietmar" <diet...@proxmox.com> Envoyé: Vendredi 19 Juin 2015 08:02:07 Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support > "The following criteria are required to as a config drive: > Must be formatted with vfat or iso9660 filesystem or have a filesystem label > of config-2 > " > > so, does it need to be really labelled config-2 ? Yes, because of the second condition: «2. Must be a un-partitioned block device (/dev/vdb, not /dev/vdb1)» Qemu's vvfat includes an MBR with the filesystem being the first partition. In my tests the second condition doesn't apply if it has a label, at least on linux. -- > On June 19, 2015 at 7:55 AM Alexandre DERUMIER <aderum...@odiso.com> wrote: > > > also cloud-init windows seem to support vfat configdrive > > "Add support for VFAT ConfigDrive" > https://github.com/stackforge/cloudbase-init/commit/2026ee8e0f766f91cf62904ceca3de7382eea787 > > > > and cloud-init documentation say: > http://cloudinit.readthedocs.org/en/latest/topics/datasources.html > > "The following criteria are required to as a config drive: > Must be formatted with vfat or iso9660 filesystem or have a filesystem label > of config-2 > " > > so, does it need to be really labelled config-2 ? > > > ----- Mail original ----- > > De: "Wolfgang Bumiller" <w.bumil...@proxmox.com> > À: "aderumier" <aderum...@odiso.com> > Cc: "dietmar" <diet...@proxmox.com>, "pve-devel" <pve-devel@pve.proxmox.com> > Envoyé: Jeudi 18 Juin 2015 15:16:34 > Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support > > Hey Alexandre, > I don't know if you're already tinkering with rsyncing the iso images, > and wanted to let you know that I'm currently experimenting with qemu's > vvfat drive option. According to the source it should work across > migrations as long as it's used read-only. I tested migrating in a > virtual testcluster and it seemed to work. > It basically takes a directory, loads the list of contained files and > presents the guest OS with a fat16 formatted partition on a block device. > The downside of it is that we need the qemu patch I posted earlier to > label the partition, as cloud-init needs it to be labeled "config-2", > but qemu's vvfat default is hardcoded to "QEMU VVFAT". > The change is small enough though, so maybe they even accept it > upstream... > > On Wed, Jun 17, 2015 at 12:58:53PM +0200, Alexandre DERUMIER wrote: > > >>I would generate a Digest using all cloud-init related values, and > > >>re-gererate > > >>the iso at VM start > > >>if the digest has changed. > > > > Ok. Maybe can be generate the cloudinit iso file with vmid-digest.iso ? > > Like this no need to store the dgest in vmid.conf ? > > > > Also, Do we need to set theses changed values in pending or not ? > > > > > > ----- Mail original ----- > > De: "dietmar" <diet...@proxmox.com> > > À: "Wolfgang Bumiller" <w.bumil...@proxmox.com>, "aderumier" > > <aderum...@odiso.com> > > Cc: "pve-devel" <pve-devel@pve.proxmox.com> > > Envoyé: Mercredi 17 Juin 2015 11:40:24 > > Objet: Re: [pve-devel] RFC: qemu-server : add cloudinit support > > > > > 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. > > > > I would generate a Digest using all cloud-init related values, and > > re-gererate > > the iso at VM start > > if the digest has changed. > > > > > _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel