> It should work, and if that workaround works, you could instead add > > def check_for_export(self, context, volume_id): > pass
I'll try that out. That's a heck of a lot cleaner, plus I just picked that "if not volume[ 'iscsi_target' ]" because it was the only attribute I could find, but that was just for messing around. I wasn't able to find any attribute of the "volume" object that said that it was an RBD volume. My real concern is that the check_for_export is somehow important and I might be missing something else down the road. That said, I've been able to migrate back and forth just fine after I put that initial hack in. > to the RBDDriver. It looks like the check_for_export method was > added and relied upon without modifying all VolumeDriver subclasses, so > e.g. sheepdog would have the same problem. > > >> If live migration isn't currently possible for RBD, anyone know if >> it's in a roadmap? > > > If this is still a problem in trunk I'll make sure it's fixed before > Folsom is released. Cool, thanks! Incidentally (and I can open up a new thread if you like), I was also going to post here about your quote in Sebastien's article: <quote> What’s missing is that OpenStack doesn’t yet have the ability to initialize a volume from an image. You have to put an image on one yourself before you can boot from it currently. This should be fixed in the next version of OpenStack. Booting off of RBD is nice because you can do live migration, although I haven’t tested that with OpenStack, just with libvirt. For Folsom, we hope to have copy-on-write cloning of images as well, so you can store images in RBD with glance, and provision instances booting off cloned RBD volumes in very little time. </quote> I just wanted to confirm I'm reading it right: With the above features, we'll be able to use "--block_device_mapping vda" mapped to an RBD volume *and* a glance-based image on the same instance and it'll clone that image onto the RBD volume? Is that a correct interpretation? That'd be indeed sweet. Right now I'm either booting with an image, which forces me to use qcow2 and a second RBD-based volume (with the benefit of immediately running), or booting with both vda and vdb on RBD volumes (but then have to install the vm from scratch, OS-wise). Of course, I might be missing a beautiful, already-existing 3rd option that I'm just not aware of :) _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
