add hypervisor volume example for runtime

[gao-feng]

For hypervisor runtime, mount hypervisor volume for
container is useful.

Signed-off-by: Gao feng omarapazanadi@gmail.com

[mrunalp]

Is it necessary to know the type of the volume? If so, then it would make sense to have something like a source type and a destination type. Or some altogether separate option.

[gao-feng]

Yes. in order to emulate volume file to the block device of guest os, hypervisor need to know the type of volume, the destination type must be a block disk device, container in guest os can mount it directly.

[mrunalp]

Should we use a a separate source_type field for this then rather than having to interpret the source string?

[philips]

There aren't any magic headers that can be relied on to figure out the block device type?!

[gao-feng]

@philips the source is not only the device path, but also the RADOS Block Devices (RBD) or something eles. had better to specify the volume type, this makes things simple.

[gao-feng]

@mrunalp I don't know if other people want this field, since it't useless for container...

[gao-feng]

@wking patch updated. thanks.

[wking]

On Wed, Sep 02, 2015 at 11:36:36PM -0700, Gao feng wrote:

@wking patch updated. thanks.

Looks good to me, thanks :).

[philips]

@gao-feng Is there existing prior art for this stuff? For example kvm or something? I am not ecstatic about making up a serialization format like qcow2:/volumes/data.qcow2

[gao-feng]

@philips qemu uses samilar format qemu -m 1024 -drive format=rbd,file=rbd:{pool-name}/{image-name},cache=writeback http://docs.ceph.com/docs/cuttlefish/rbd/qemu-rbd/#running-qemu-with-rbd,
If you think adding an extra source type field or even source option field(for configure rbd user, keyring, hosts so on) and renaming the type filed to filesystem are good idea, I agree with you.

[mrunalp]

@gao-feng

[mrunal@dhcp-16-188 Images]$ file docker.qcow2 
docker.qcow2: QEMU QCOW Image (v3), 12884901888 bytes

Does this not work for other types of hypervisor volumes?

[gao-feng]

@mrunalp the source is not only the device path, but also the RADOS Block Devices (RBD) or something eles. had better to specify the volume type, this makes things simple.

[gao-feng]

@philips @wking @mrunalp rebased, please check.

[wking]

On Wed, Sep 09, 2015 at 11:20:51PM -0700, Gao feng wrote:

@philips @wking @mrunalp rebased, please check.

What changed with 25c9f33 → e90fa6f? It looks like your rebase picked
up #136 and #165, but didn't address whether or not we should be
overloading the ‘source’ field 1.

[gao-feng]

@wking Only rebase, you can regard this as ping. :)

[wking]

On Thu, Sep 10, 2015 at 07:28:05AM -0700, Gao feng wrote:

@wking Only rebase…

Ok. e90fa6f still looks good to me (I'm agnostic on overloading
‘source’ vs. adding a ‘sourceType’ field).

[vbatts]

I'm really not sure this is needed. It seems too much like a runtime specific item.

[vbatts]

I really like that virtual devices can suffice here, but this is so specific for VM and not kernel containers that it feels a bit like a one-off. I think something like this could be an annoations and use of life-cycle hooks.

I'm going to close this for the time being, until all minimal options are determined to not solve this.