| Image handlers (in essex) |
George asks in the comments on my previous post about loop and nbd devices an interesting question about the behavior of this code on essex. I figured the question was worth bringing out into its own post so that its more visible. I've edited George's question lightly so that this blog post flows reasonably.
Can you please explain the order (and conditions) in which the three methods are used? In my Essex installation, the "img_handlers" is not defined in nova.conf, so it takes the default value "loop,nbd,guestfs". However, nova is using nbd as the chose method.The handlers will be used in the order specified -- with the caveat that loop doesn't support Copy On Write (COW) images and will therefore be skipped if the libvirt driver is trying to create a COW image. Whether COW images are used is configured with the use_cow_images flag, which defaults to True. So, loop is being skipped because you're probably using COW images.
My ssh keys are obtained by cloud-init, and still whenever I start a new instance I see in the nova-compute.logs this sequence of events:This is a bit harder than the first bit of the question. What I think is happening is that there are files being injected, and that's causing the mount. Just because the admin password isn't being inject doesn't mean that other things aren't being injected still. You'd be able to tell what's happening by grepping your logs for "Injecting .* into image" and seeing what shows up.qemu-nbd -c /dev/nbd15 /var/lib/nova/instances/instance-0000076d/disk kpartx -a /dev/nbd15 mount /dev/mapper/nbd15p1 /tmp/tmpxGBdT0 umount /dev/mapper/nbd15p1 kpartx -d /dev/nbd15 qemu-nbd -d /dev/nbd15I don't understand why the mount of the first partition is necessary and what it happens when the partition is mounted.
posted at: 15:51 | path: /openstack | permanent link to this entry
-
###
George
I grepped the nova-compute.log after starting a new instance and it came back with "Injecting key into image".
So I think the key was indeed injected by Nova as per the log, and then cloud-init was over-writing the "/root/.ssh/authorized_keys" file with the same SSH key.
To test this assumption, I added the following flags in nova.conf and restarted the nova-compute service:
--libvirt_inject_password=false
--libvirt_inject_key=false
Upon starting a new instance, the qemu-nbd part is missing from the logs as well as the "Injecting key into image", but the ssh key is still injected by cloud-init.
In conclusion, when using qcow based images and "--libvirt_inject_key=true" (or not defined in nova.conf), the nbd method is used for ssh key injection.
If the baseline has cloud-init installed, the SSH key will be obtained from the nova-api-metadata service and saved into "/root/.ssh/authorized_keys" at the first boot.
Thanks for your reply and for helping me understand this mechanism.
George