Done. Tested root/data disks for CLVM, local, NFS.
On Wed, Oct 9, 2013 at 11:32 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > Yeah, existing volumes have a path thats already set in stone. It would only > concern new volumes. > > It could cause problems down the line if people get used to them matching > and decide to use uuid and path interchangeably. They're not by default > identical though since the path usually contains the directory and > filename/uuid (at least for qcow2, I think LVM just has the logical volume > uuid as path). > > On Oct 9, 2013 11:21 PM, "Prasanna Santhanam" <t...@apache.org> wrote: >> >> +1 - happens in lots of places in our code where a random-uuid >> associates with a physical resource's uuid. >> >> Will this will happen only for new volumes? Old volumes can still be >> listed and found using the old method? I'm specifically concerned >> about upgraded systems. >> >> On Wed, Oct 09, 2013 at 11:05:48PM -0600, Mike Tutkowski 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> >> > *?* >> >> -- >> Prasanna., >> >> ------------------------ >> Powered by BigRock.com >> >
