[openstack-dev] [nova] Block Device mapping and supporting cd-roms
josh.durgin at inktank.com
Wed Jan 30 23:47:15 UTC 2013
On 01/30/2013 07:38 AM, Vishvananda Ishaya wrote:
> On Jan 30, 2013, at 2:05 AM, Daniel P. Berrange <berrange at redhat.com> wrote:
>> On Tue, Jan 29, 2013 at 11:58:39AM -0800, Vishvananda Ishaya wrote:
>>> On Jan 29, 2013, at 6:18 AM, Daniel P. Berrange <berrange at redhat.com> wrote:
>>> b) There is no concept of dest-type so I assume we would be going with
>>> auto-generating dest-type from source? Glance -> local, Ephemeral -> local,
>>> Cinder -> remote.
>> I'm not entirely sure what you mean by 'dest-type' - can you point to
>> where this 'dest-type' value is currently specified and/or used ?
> Sorry i confused things by changing what i was calling it. My previous email called
> it target-type. Basically it refers to where the bits will live while the guest
> is active. From my previous email:
> 5. allow users to specify target_type (optional)
> (not mentioned)
> src_type tells us where the disk bits come from. Currently we do some magic to
> determine where the bits will live while the guest is active.
> volume -> self
> snapshot -> new volume
> image -> local
> blank -> local
> We could continue to have a magic mapping like this or we could expose to the user
> the ability to specify where the bits should be. This involves nova having more
> conversion options, but it could be valuable to specify if it isn't too complex.
> I think it is fine having this automatically calculated initially, which is what
> we do already, but we should keep in mind that we may want to add an extra
> parameter for this in the future.
I think this is a pretty important feature for narrowing the difference
between local files and volumes. It's not too complex to implement
either, since the infrastructure to convert between snapshots, volumes
and images already exists in cinder.
I'll post a prototype for review in the next few days.
More information about the OpenStack-dev