On Tue, Mar 10, 2015 at 9:57 AM, Karanbir Singh mail-lists@karan.org wrote:

On 09/03/15 19:55, Gianluca Cecchi wrote:

...

the web links of the two images referred above seem not valid any more... Was there any problem with them?

yes :( those images have a problem with cloud-init. I've since resolved the issue and pushed new images, you can find them with sha256's :

b08bad32dd68553750822ef9b769cd634aac1d0fd65f27c7d32257b47a6596b3 CentOS-7-x86_64-AtomicHost-20150228_01.qcow2

The new images are quite better, indeed ;-) I downloads the xz one and then unxz < CentOS-7-x86_64-AtomicHost.qcow2.xz | dd of=CentOS-7-x86_64-AtomicHost.qcow2 bs=1024k

From man page of unxz, it should manage sparse files automatically, but I

noticed with the other image that simply making unxz the uncompressed image didn't match the sha256sum of the original one given on the web site.

...

Do I have to pass any kernel command line when I start in virt-manager? I also found this "old" link to create the seed image:

https://rwmj.wordpress.com/2013/12/10/creating-a-cloud-init-config-disk-for-...

Couple of things to keep in mind, the cloud-init iso's volume id needs to be 'cidata' and the user-data + meta-data files need to be in the root of that iso. This is the geniofs line that I use : genisoimage -output configdrive.iso -volid cidata -joliet -rock user-data meta-data

OK. The volid suggested matches the one I found in the docs. And now it works. I see cloud-init phase in console, that I didn't see at all before, and the hostname of the system is indeed updated. I can connect without password from my system using the ssh key I generated. BTW: is it a limitation to use rsa keys or one can use dsa keys too? To verify that also the password passed through user-data is correctly gotten, I connect from inside the vm to itself via ssh with the centos user and using the password it works. And also directly using centos user in console it works

then just attach that to the machine instance as a CD drive and it should just work from there.

I've also had problems with instance setup, if I was using an image that had already been setup - so I tend to not use the downloaded file, I create a qemu snapshot of the qcow2 file and then consume that instead. This allows me to go back and refresh my image anytime without needing to re-download the image. Something like this should work :

qemu-img create -f qcow2 -b CentOS-7-x86_64-AtomicHost-20150228_01.qcow2 myatomic_snap-01.qcow2

then just use the myatomic_snap-01.qcow2 as your new image ( you can check this is a snapshot by qemu-img info myatomic_snap-01.qcow2 )

Thanks for the tip I also found that for further boots you have to regenerate the iso with a new instance-id in meta-data. And I verified it works. In new iso I put different passowrd for centos user and different hostname (and differenti instance-id of course). And after shutdown and connect of new iso, it starts without any problem with new hostname and password for centos user. The previous ssh key continues to work (I'm not asked for the key confirmation, as it is already there inside my known_hosts file.

...

but the virt-builder command is not able to extract kernel and initrd image from the qcow2 image.

I am not sure if virt-builder can parse an ostree payload, i suspect its looking for a generic filesystem inside the image. You might want to validate this with the virt-tools list.

I confirm that virt-builder fails with this image too, so I will redirect question/clarification to virt-tools as you suggested, even if it not strictly necessary now that the iso method works ok.

Thanks and keep on with the great work! Gianluca