Sure, that's a good plan. I'll get to it.
On Mon, Oct 7, 2013 at 2:29 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > I know you mentioned you might need some minor changes to it, as well as > other minor changes just for master (attach volume switched to pool vs > adapter or something). My hope was that you would be able to send an update > that works for your plugin on master, I'll test against existing libvirtd > storage and apply it. > On Oct 7, 2013 1:49 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> > wrote: > >> This is an automatically generated e-mail. To reply, visit: >> https://reviews.apache.org/r/14381/ >> >> This looks reasonable to me, Marcus. >> >> When do you think you might start the process of getting this into master? >> >> >> - Mike Tutkowski >> >> On September 30th, 2013, 5:14 p.m. UTC, Marcus Sorensen wrote: >> Review request for cloudstack, edison su and Mike Tutkowski. >> By Marcus Sorensen. >> >> *Updated Sept. 30, 2013, 5:14 p.m.* >> *Repository: * cloudstack-git >> Description >> >> With custom storage plugins comes the need to prep the KVM host prior to >> utilizing the disks. e.g. an iscsi initiator needs to log into the target >> and scan for the lun before it can be used on the host. This patch is an >> example I developed against 4.2, minor changes may be necessary to apply to >> master, but I want to share with others who are working on storage so they >> can ensure it works for them. Please tweak as you see fit. >> >> MigrateCommand: pass vmTO object so we can see which disks/storage pool >> types belong to the vm when migrating a VM. This facilitates being able to >> call disconnectPhysicalDisksViaVmSpec >> >> VirtualMachineManagerImpl: pass VirtualMachineTO when migrating so that we >> can see which disks belong to the VM and what storage pools/adaptors should >> be used >> >> LibvirtComputingResource: add calls KVMStoragePoolManager's >> connectPhysicalDiskViaVmSpec and disconnectPhysicalDiskViaVmSpec calls where >> appropriate (when starting a vm, migrating a vm). Ensure that we create >> 'raw' format XML disk definitions when the storage format is RAW. Move >> cleanupDisk logic to storage adaptors so that each adaptor type can clean up >> its disks in is own way. >> >> KVMStoragePoolManager: add connectPhysicalDisk, disconnectPhysicalDisk, >> connectPhysicalDiskViaVmSpec, disconnectPhysicalDiskViaVmSpec, >> disconnectPhysicalDiskByPath. These all call the specific StorageAdaptor's >> connectPhysicalDisk, disconnectPhysicalDisk, or disconnectPhysicalDiskByPath >> calls. >> >> KVMStorageProcessor: Call connectPhysicalDisk/disconnectPhysicalDisk on the >> storage adaptor. Whether or not this is implemented is up to the storage >> adaptor. >> >> LibvirtStorageAdaptor: implement dummy >> connectPhysicalDisk/disconnectPhysicalDisk, move cleanupDisk logic from >> LibvirtComputingResource to disconnectPhysicalDiskByPath >> >> StorageAdaptor: define >> connectPhysicalDisk/disconnectPhysicalDisk/disconnectPhysicalDiskByPath in >> the interface >> >> >> Testing >> >> Basic testing with my storage adaptor >> >> Diffs >> >> - core/src/com/cloud/agent/api/MigrateCommand.java (5042b8c) >> - >> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java >> (3ee811f) >> - >> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStoragePoolManager.java >> (e09c9ba) >> - >> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStorageProcessor.java >> (c69f9b0) >> - >> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java >> (123a9f1) >> - >> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/StorageAdaptor.java >> (4956d8d) >> - server/src/com/cloud/vm/VirtualMachineManagerImpl.java (d46bbb0) >> >> View Diff <https://reviews.apache.org/r/14381/diff/> >> > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
