add hypervisor volume example for runtime #133
Conversation
| @@ -3,7 +3,7 @@ | |||
| Additional filesystems can be declared as "mounts", specified in the *mounts* array. The parameters are similar to the ones in Linux mount system call. [http://linux.die.net/man/2/mount](http://linux.die.net/man/2/mount) | |||
|
|
|||
| * **type** (string, required) Linux, *filesystemtype* argument supported by the kernel are listed in */proc/filesystems* (e.g., "minix", "ext2", "ext3", "jfs", "xfs", "reiserfs", "msdos", "proc", "nfs", "iso9660"). Windows: ntfs | |||
| * **source** (string, required) a device name, but can also be a directory name or a dummy. Windows, the volume name that is the target of the mount point. \\?\Volume\{GUID}\ (on Windows source is called target) | |||
| * **source** (string, required) a device name, but can also be a directory name or a dummy. Windows, the volume name that is the target of the mount point. \\?\Volume\{GUID}\ (on Windows source is called target). Hypervisor Runtime, source can be the volume type (e.g., "qcow2", "raw", "vdi", "rbd") and the path of volume. | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Should we use a a separate source_type field for this then rather than having to interpret the source string?
There was a problem hiding this comment.
There aren't any magic headers that can be relied on to figure out the block device type?!
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
@mrunalp I don't know if other people want this field, since it't useless for container...
gao-feng
force-pushed
the
volume-example
branch
from
98ba70a to
25c9f33
Compare
|
@wking patch updated. thanks. |
|
On Wed, Sep 02, 2015 at 11:36:36PM -0700, Gao feng wrote:
Looks good to me, thanks :). |
|
@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 |
|
@philips qemu uses samilar format |
Does this not work for other types of hypervisor volumes? |
|
@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. |
For hypervisor runtime, mount hypervisor volume for container is useful. Signed-off-by: Gao feng <[email protected]>
gao-feng
force-pushed
the
volume-example
branch
from
25c9f33 to
e90fa6f
Compare
|
@wking Only rebase, you can regard this as ping. :) |
| "mounts": { | ||
| "data": { | ||
| "type": "ext3", | ||
| "source": "qcow2:/volumes/data.qcow2", |
There was a problem hiding this comment.
I'm really not sure this is needed. It seems too much like a runtime specific item.
|
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. |
For hypervisor runtime, mount hypervisor volume for
container is useful.
Signed-off-by: Gao feng [email protected]