Yeah, but I'm not seeing an easy/pluggable way to implement a storage adaptor, where LibvirtComputingResource relies exclusively on KVMStoragePoolManager, which is implementing LibvirtStorageAdaptor. I don't see how to switch between storage adaptors in KVMStoragePoolManager.java based on what primary storage type I happen to be acting upon.
On Mon, Dec 10, 2012 at 12:51 PM, Edison Su <edison...@citrix.com> wrote: > ** ** > > ** ** > > *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.**** >
