So, now that I'm getting back to this, do you think I should just try to make this work with 4.2 (like we originally talked about)?
I updated again from master, rebuilt, redeployed DEBs and still get this JNA error message: log4j:WARN No appenders could be found for logger (org.apache.commons.httpclient.params.DefaultHttpParams). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243) Caused by: java.lang.UnsatisfiedLinkError: Can't obtain updateLastError method for class com.sun.jna.Native at com.sun.jna.Native.initIDs(Native Method) at com.sun.jna.Native.<clinit>(Native.java:139) at org.libvirt.jna.Libvirt.<clinit>(Unknown Source) at org.libvirt.Library.<clinit>(Unknown Source) at org.libvirt.Connect.<init>(Unknown Source) at com.cloud.hypervisor.kvm.resource.LibvirtConnection.getConnection(LibvirtConnection.java:44) at com.cloud.hypervisor.kvm.resource.LibvirtConnection.getConnection(LibvirtConnection.java:37) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:733) at com.cloud.agent.Agent.<init>(Agent.java:161) at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:415) at com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:370) at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:351) at com.cloud.agent.AgentShell.start(AgentShell.java:448) ... 5 more Cannot start daemon Service exit with a return value of 5 On Mon, Oct 7, 2013 at 2:31 PM, Mike Tutkowski <mike.tutkow...@solidfire.com > wrote: > 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> > *™* > -- *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> *™*
