Open Stack

On Mon, Aug 13, 2012 at 10:16 PM, Nathanael Burton
<nathanael.i.burton at gmail.com> wrote:
> On Aug 13, 2012 11:37 PM, "Vishvananda Ishaya" <vishvananda at gmail.com>
> wrote:
>> The second proposal I have is to use a feature of kvm attach and set the
>> device serial number. We can set it to the same value as the device
>> parameter. This means that a device attached to /dev/vdb may not always be
>> at /dev/vdb (with old kvm guests), but it will at least show up at
>> /dev/disk/by-id/virtio-vdb consistently.
>
> What about setting the serial number to the volume_id? At least that way you
> could be sure it was the volume you meant, especially in the case where vdb
> in the guest ends up not being what you requested. What about other
> hypervisors?
>
>> (review coming soon)
>>
>> First question: should we return this magic path somewhere via the api? It
>> would be pretty easy to have horizon generate it but it might be nice to
>> have it show up. If we do return it, do we mangle the device to always show
>> the consistent one, or do we return it as another parameter? guest_device
>> perhaps?
>>
>> Second question: what should happen if someone specifies /dev/xvda against
>> a kvm cloud or /dev/vda against a xen cloud?
>> I see two options:
>> a) automatically convert it to the right value and return it
>> b) fail with an error message
>>
>> Third question: what do we do if someone specifies a device value to a kvm
>> cloud that we know will not work. For example the vm has /dev/vda and
>> /dev/vdb and they request an attach at /dev/vdf. In this case we know that
>> it will likely show up at /dev/vdc. I see a few options here and none of
>> them are amazing:
>>
>> a) let the attach go through as is.
>>   advantages: it will allow scripts to work without having to manually
>> find the next device.
>>   disadvantages: the device name will never be correct in the guest
>> b) automatically modify the request to attach at /dev/vdc and return it
>>   advantages: the device name will be correct some of the time (kvm guests
>> with newer kernels)
>>   disadvantages: sometimes the name is wrong anyway. The user may not
>> expect the device number to change
>> c) fail and say, the next disk must be attached at /dev/vdc:
>>   advantages: explicit
>>   disadvantages: painful, incompatible, and the place we say to attach may
>> be incorrect anyway (kvm guests with old kernels)
>>
>> The second proposal earlier will at least give us a consistent name to
>> find the volume in all these cases, although b) means we have to check the
>> return value to find out what that consistent location is like we do when we
>> don't pass in a device.
>>
>> I hope everything is clear, but if more explanation is needed please let
>> me know. If anyone has alternative/better proposals please tell me. The last
>> question I think is the most important.
>>
>> Vish
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

I've wondered about using the mount by device-uuid as long term
solutions, ie just mount using libvirt mount by /dev/disk/by-uuid
(don't even take a device parameter).  Although I guess there are some
issues here.

As far as my input to your questions:
> What about setting the serial number to the volume_id? At least that way you
> could be sure it was the volume you meant, especially in the case where vdb
> in the guest ends up not being what you requested. What about other
> hypervisors?

+1

>First question: should we return this magic path somewhere via the api? It would be >pretty easy to have horizon generate it but it might be nice to have it show up. If we >do return it, do we mangle the device to always show the consistent one, or do we >return it as another parameter? guest_device perhaps?

I think returning a distinct parameter would be best in this case.

>Second question: what should happen if someone specifies /dev/xvda against a >kvm cloud or /dev/vda against a xen cloud?
>I see two options:
>a) automatically convert it to the right value and return it
>b) fail with an error message

I would vote for option a (auto convert and return)

With respect to the third question:
> (b) automatically modify the request to attach at /dev/vdc and return it)

Seems the best choice we have given a balance between compatibility
and reliability.
The only way to get better reliability given the scenarios creates a
mess compatibility wise in my opinion.  I also think that if we add a
field to volume show that includes the *real* path it alleviates some
of the problem here.

John