On Fri, Jul 12, 2013 at 11:10 PM, Lance Albertson <[email protected]> wrote: > I'm asking this question for Harry (the Ganeti+GlusterFS GSoC student) to > try and make sure its understood correctly the first time. > > So we're needing to decide how to deal with the virtual disks that Ganeti > will interact with for the KVM+GlusterFS support. On the surface its going > to be using file-based storage similar to "file" and "sharedfile", however > it looks like in lib/storage/bdev.py that you don't use tools such as > qemu-img to create the raw file, you literally just make a file of a certain > size. >
this is indeed the case for now. The glusterfs implementation should be similar to sharedfile and rbd. > According to this blog post [1] talking about this new feature, we will need > to add support for creating this file using qemu-img instead of just a raw > file. You can create the file-based disk storage on gluster directly using > qemu-img using a command such as: > > qemu-img create gluster://server/volname/path/to/image size > Ack, makes sense. > So to me this means we need a new device type in bdev.py which could open > the possibility of finally adding support for other image formats that > qemu-img support (such as qcow2). But for this project we can just stick to > raw files. > I don't understand if raw files are supported or not, and qemu-img is a strict dependency. Anyway, either way we need a new class called GlusterBlockDevice that is able to create/delete etc devices on gluster. *if* this wants to (perhaps optionally) depend on a common QemuImgDevice class, this is OK too. Then in the future perhaps file/sharedfile could add Qemu Img support. > So my question for Ganeti devs is, should Harry make a new device type in > bdev.py that specifically supports qemu-img (say QemuImgDevice)? It doesn't > have to only work for this GlusterFS feature but could potentially be used > for file and sharedfile as well. > This would definitely be a good design (GlusterBlockDevice using QemuImgDevice), but of course there's no need to change file/sharedfile to support it right away. This can be done later either by harry (after the summer of code) or by someone else. > I think initially we were looking at the rbd patch as an example however > that doesn't exactly align 1:1 since we aren't directly accessing a block > device. We're doing all of the operations via qemu-img or qemu (kvm) > directly. > Didn't we say there would also be (optional) direct access? Or was that deemed not needed/too complex? Anyway it's OK to behave similarly to rbd, but ignoring the direct access part (or make them optional), as this is the plan for rbd itself as well. Thanks, Guido
