search

olopez32 / ganeti

Automatically exported from code.google.com/p/ganeti
0 stars 0 forks source link

Don't create block device for RBD/Gluster if `access=userspace` #544

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
RBD and Gluster support (or will support) the `access` disk parameter. Setting 
this to `userspace` tells KVM to access the disk via QEMU and a custom 
protocol. This does not require a kernel module, nor does it require to create 
a block device at all.

Ganeti currently creates a block device when starting an instance no matter 
which access mode is requested. This creates a dependency on kernel modules 
where it is not strictly required.
Instead, Ganeti should only create the block device on `gnt-instance 
activate-disks` (so administrators can still mount the filesystem(s) if 
necessary).

Original issue reported on code.google.com by thoma...@google.com on 31 Jul 2013 at 11:54

GoogleCodeExporter commented 9 years ago 
Additionally, the block device might be required for some other tasks (OS 
installation, import/export?, etc.)

Original comment by thoma...@google.com on 31 Jul 2013 at 2:18

GoogleCodeExporter commented 9 years ago 
That depends; a temporary disk image could be created (sparsely of course) and 
then imported in to the rbd storage via qemu-img once the initial setup is 
completed.

Original comment by mjevans1...@gmail.com on 13 Aug 2013 at 12:25

GoogleCodeExporter commented 9 years ago 
Importing via a userspace tool such as qemu-img is also desirable due to the 
possible lockup situation that can be encountered (no other realistic 
workarounds): http://tracker.ceph.com/issues/3076

Original comment by mjevans1...@gmail.com on 13 Aug 2013 at 12:36

GoogleCodeExporter commented 9 years ago 
Reassigning to rsanti, who is currently working on RBD.

Original comment by thoma...@google.com on 24 Sep 2013 at 2:53

GoogleCodeExporter commented 9 years ago

Original comment by thoma...@google.com on 19 Feb 2014 at 10:01

GoogleCodeExporter commented 9 years ago 
Move all issues assigned to 2.10 to 2.11, because their priority would not 
justify an inclusion in 2.10.

Original comment by thoma...@google.com on 19 Feb 2014 at 10:07