You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Marcus Sorensen <sh...@gmail.com> on 2013/10/10 05:57:41 UTC
Back end volume names in KVM
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.
Re: Back end volume names in KVM
Posted by Mike Tutkowski <mi...@solidfire.com>.
OK, now I'm really replying to this e-mail thread. :)
I think this is a good idea, Marcus. It gets rid of an unnecessary
translation step.
On Wed, Oct 9, 2013 at 11:23 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:
> 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.tutkowski@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 <sh...@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
Re: Back end volume names in KVM
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.tutkowski@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 <sh...@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
Re: Back end volume names in KVM
Posted by Marcus Sorensen <sh...@gmail.com>.
Done. Tested root/data disks for CLVM, local, NFS.
On Wed, Oct 9, 2013 at 11:32 PM, Marcus Sorensen <sh...@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" <ts...@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 <sh...@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.tutkowski@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
>>
>
Re: Back end volume names in KVM
Posted by Marcus Sorensen <sh...@gmail.com>.
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" <ts...@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 <sh...@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.tutkowski@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
>
>
Re: Back end volume names in KVM
Posted by Prasanna Santhanam <ts...@apache.org>.
+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 <sh...@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.tutkowski@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
Re: Back end volume names in KVM
Posted by Mike Tutkowski <mi...@solidfire.com>.
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 <sh...@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*
Re: Back end volume names in KVM
Posted by Koushik Das <ko...@citrix.com>.
On 10-Oct-2013, at 9:27 AM, Marcus Sorensen <sh...@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.
>
The 'uuid' field in volumes table was added later on. Since previously there was no uuid for a volume it was done that way.
+1 for the change.
> 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.