On Mon, Aug 13, 2012 at 10:16 PM, Nathanael Burton <nathanael.i.bur...@gmail.com> wrote: > On Aug 13, 2012 11:37 PM, "Vishvananda Ishaya" <vishvana...@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-...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > openstack-...@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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
