From: Marcus Sorensen [mailto:shadow...@gmail.com] Sent: Monday, December 10, 2012 2:06 PM To: Edison Su Cc: cloudstack-dev@incubator.apache.org Subject: pluggable storage implementation
Just curious, hadn't thought about this before but it seems that at least on KVM (probably similar in Xen and VMware too?), there are two separate issues with storage in the existing code. First, adding a new storage type is a matter of adding in a new 'else if' or something in a bunch of different places, as well as tweaking behavior to match the storage type. Second, everything about the storage is tightly integrated with Libvirt, meaning that if your storage type is not supported by Libvirt it's much, much more difficult to implement. Are these both being addressed by the storage changes, for example can we write a storage plugin that creates pools/volumes that libvirt doesn't know about and still attach those to instances? Or would we need to patch libvirt to utilize our storage first? [Edison] That's the storageadaptor used for: https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob;f=plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/StorageAdaptor.java;h=ef1e7c9302ab6ac8f197cf75bbf7235bba0235cf;hb=HEAD The LibvirtStorageAdaptor is one of implementation of storageadaptor, which is totally based on libvirt, If you have a new storage, not supported by libvirt, then you can add a new implementation of storageadaptor.
