Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120814/c7d30548/attachment.html>