I'm sorry! I sent this e-mail to the wrong discussion thread. :)
On Wed, Oct 9, 2013 at 11:05 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > 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> > *™* > -- *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> *™*
