Yeah, I'm not really clear how the snapshot strategy works if you have multiple vendors that implement that interface either.
On Wed, Oct 9, 2013 at 9:57 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > Does anyone have any reservations about changing the volume identifier in > KVM's volume creation command to be the uuid of the volume? Currently for > new volumes it generates a random uuid and passes that back to be stored in > the database. From an admin perspective, the only way to link a volume on > the back end (be it a qcow2 image or an LVM volume) to one as reported is > to look in the DB and see what this 'secondary uuid' is and look for THAT > as the filename/image name on the back end. It would simply remove a layer > of translating uuid to another hidden uuid to get file/volume name. > > It shouldn't disrupt or change current volumes, just new ones. > > The only caveat I can think of so far is if we wanted multiple files/images > on the back end to map to one volume, but I don't see that as a blocker > since it would probably have lots of other implications to the tracking > volume objects. > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
