and one more: boot from image (create a new volume) doesn't work either: it leads to a VM that complains about a non-bootable disk (just like the ISO case). This is actually and improvement: earlier, nova was waiting for ages for an image to be created (I guess that this is the result of the glance -> cinder RBD improvements)
cheers jc -- SWITCH Jens-Christian Fischer, Peta Solutions Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 15 71 jens-christian.fisc...@switch.ch http://www.switch.ch http://www.switch.ch/socialmedia On 08.11.2013, at 02:20, Josh Durgin <josh.dur...@inktank.com> wrote: > On 11/08/2013 12:15 AM, Jens-Christian Fischer wrote: >> Hi all >> >> we have installed a Havana OpenStack cluster with RBD as the backing >> storage for volumes, images and the ephemeral images. The code as >> delivered in >> https://github.com/openstack/nova/blob/master/nova/virt/libvirt/imagebackend.py#L498 >> fails, >> because the RBD.path it not set. I have patched this to read: > > Using libvirt_image_type=rbd to replace ephemeral disks is new with > Havana, and unfortunately some bug fixes did not make it into the > release. I've backported the current fixes on top of the stable/havana > branch here: > > https://github.com/jdurgin/nova/tree/havana-ephemeral-rbd > >> * @@ -419,10 +419,12 @@ class Rbd(Image): >> * if path: >> * try: >> * self.rbd_name = path.split('/')[1] >> * + self.path = path >> * except IndexError: >> * raise exception.InvalidDevicePath(path=path) >> * else: >> * self.rbd_name = '%s_%s' % (instance['name'], disk_name) >> * + self.path = 'volumes/%s' % self.rbd_name >> * self.snapshot_name = snapshot_name >> * if not CONF.libvirt_images_rbd_pool: >> * raise RuntimeError(_('You should specify' >> >> >> but am not sure this is correct. I have the following problems: >> >> 1) can't inject data into image >> >> 2013-11-07 16:59:25.251 24891 INFO nova.virt.libvirt.driver >> [req-f813ef24-de7d-4a05-ad6f-558e27292495 >> c66a737acf0545fdb9a0a920df0794d9 2096e25f5e814882b5907bc5db342308] >> [instance: 2fa02e4f-f804-4679-9507-736eeebd9b8d] Injecting key into >> image fc8179d4-14f3-4f21-a76d-72b03b5c1862 >> 2013-11-07 16:59:25.269 24891 WARNING nova.virt.disk.api >> [req-f813ef24-de7d-4a05-ad6f-558e27292495 >> c66a737acf0545fdb9a0a920df0794d9 2096e25f5e814882b5907bc5db342308] >> Ignoring error injecting data into image (Error mounting volumes/ >> instance-0000 >> 0089_disk with libguestfs (volumes/instance-00000089_disk: No such file >> or directory)) >> >> possibly the self.path = … is wrong - but what are the correct values? > > Like Dinu mentioned, I'd suggest disabling file injection and using > the metadata service + cloud-init instead. We should probably change > nova to log an error about this configuration when ephemeral volumes > are rbd. > >> 2) Creating a new instance from an ISO image fails completely - no >> bootable disk found, says the KVM console. Related? > > This sounds like a bug in the ephemeral rbd code - could you file > it in launchpad if you can reproduce with file injection disabled? > I suspect it's not being attached as a cdrom. > >> 3) When creating a new instance from an image (non ISO images work), the >> disk is not resized to the size specified in the flavor (but left at the >> size of the original image) > > This one is fixed in the backports already. > >> I would be really grateful, if those people that have Grizzly/Havana >> running with an RBD backend could pipe in here… > > You're seeing some issues in the ephemeral rbd code, which is new > in Havana. None of these affect non-ephemeral rbd, or Grizzly. > Thanks for reporting them! > > Josh >
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
