<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 10, 2015 at 9:57 AM, Karanbir Singh <span dir="ltr"><<a href="mailto:mail-lists@karan.org" target="_blank">mail-lists@karan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 09/03/15 19:55, Gianluca Cecchi wrote:<br>
> the web links of the two images referred above seem not valid any more...<br>
> Was there any problem with them?<br>
<br>
</span>yes :( those images have a problem with cloud-init. I've since resolved<br>
the issue and pushed new images, you can find them with sha256's :<br>
<br>
b08bad32dd68553750822ef9b769cd634aac1d0fd65f27c7d32257b47a6596b3<br>
CentOS-7-x86_64-AtomicHost-20150228_01.qcow2<br></blockquote><div><br></div><div>The new images are quite better, indeed ;-)</div><div>I downloads the xz one and then</div><div>unxz < CentOS-7-x86_64-AtomicHost.qcow2.xz | dd of=CentOS-7-x86_64-AtomicHost.qcow2 bs=1024k<br></div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
<br>
> Do I have to pass any kernel command line when I start in virt-manager?<br>
> I also found this "old" link to create the seed image:<br>
> <a href="https://rwmj.wordpress.com/2013/12/10/creating-a-cloud-init-config-disk-for-non-cloud-boots/" target="_blank">https://rwmj.wordpress.com/2013/12/10/creating-a-cloud-init-config-disk-for-non-cloud-boots/</a><br>
<br>
</span>Couple of things to keep in mind, the cloud-init iso's volume id needs<br>
to be 'cidata' and the user-data + meta-data files need to be in the<br>
root of that iso. This is the geniofs line that I use :<br>
genisoimage -output configdrive.iso -volid cidata -joliet -rock<br>
user-data meta-data<br></blockquote><div><br></div><div>OK. The volid suggested matches the one I found in the docs.</div><div>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.</div><div>I can connect without password from my system using the ssh key I generated.</div><div>BTW: is it a limitation to use rsa keys or one can use dsa keys too?</div><div>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</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
then just attach that to the machine instance as a CD drive and it<br>
should just work from there.<br>
<br>
I've also had problems with instance setup, if I was using an image that<br>
had already been setup - so I tend to not use the downloaded file, I<br>
create a qemu snapshot of the qcow2 file and then consume that instead.<br>
This allows me to go back and refresh my image anytime without needing<br>
to re-download the image. Something like this should work :<br>
<br>
qemu-img create -f qcow2 -b CentOS-7-x86_64-AtomicHost-20150228_01.qcow2<br>
myatomic_snap-01.qcow2<br>
<br>
then just use the myatomic_snap-01.qcow2 as your new image ( you can<br>
check this is a snapshot by qemu-img info myatomic_snap-01.qcow2 )<br>
<span class=""><br></span></blockquote><div><br></div><div>Thanks for the tip</div><div>I also found that for further boots you have to regenerate the iso with a new instance-id in meta-data.</div><div>And I verified it works.</div><div>In new iso I put different passowrd for centos user and different hostname (and differenti instance-id of course).</div><div>And after shutdown and connect of new iso, it starts without any problem with new hostname and password for centos user.</div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> but the virt-builder command is not able to extract kernel and initrd<br>
> image from the qcow2 image.<br>
<br>
</span>I am not sure if virt-builder can parse an ostree payload, i suspect its<br>
looking for a generic filesystem inside the image. You might want to<br>
validate this with the virt-tools list.<br><div class=""><div class="h5"><br></div></div></blockquote><div> </div><div>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.</div><div><br></div><div>Thanks and keep on with the great work! </div></div>Gianluca</div></div>