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. 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 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. 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. 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. Thoughts? [1] http://raobharata.wordpress.com/2012/10/29/qemu-glusterfs-native-integration/ -- Lance Albertson Director Oregon State University | Open Source Lab
