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-non-cloud-boots/

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