Ah, interesting. I didn’t realize that is what ‘managed’ meant. We are only doing NFS right now and everything is preallocated. I’ll update all my code to avoid the ‘managed’ flag.
Sorry about the confusion! -- Chris Suich chris.su...@netapp.com<mailto:chris.su...@netapp.com> NetApp Software Engineer Data Center Platforms – Cloud Solutions Citrix, Cisco & Red Hat On Nov 1, 2013, at 10:53 AM, Mike Tutkowski <mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>> wrote: What it comes down to is if your storage does not require the hypervisor code to create/delete SRs (datastores for VMware) dynamically, then it is not managed storage. On Fri, Nov 1, 2013 at 8:42 AM, Mike Tutkowski <mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>> wrote: By the way, when we say "managed" storage in CloudStack, we mean the storage is not preallocated (as was the only case prior to 4.2). For example, before 4.2 (using a SAN and XenServer as an example) you had to create an iSCSI target, create an SR, then introduce the SR into CS as primary storage. With 4.2 you can introduce the SAN into CS as primary storage and have volumes carved from it dynamically. The "managed" part comes in on the hypervisor side where the hypervisor code now knows how to create the SR for you to leverage the SAN volume. On Fri, Nov 1, 2013 at 8:39 AM, Mike Tutkowski <mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com>> wrote: Hey Chris, A bunch of these do make the assumption managed storage is iSCSI based (which was the situation in 4.2). At the time, we had decided to deal with the only managed storage type that was in use. You and I should work together to update managed storage in 4.3 to handle your situation. Let's start with CitrixResourceBase's StartCommand. Can you tell me, are you using NFS? What is your managed storage type? Thanks! On Fri, Nov 1, 2013 at 8:32 AM, SuichII, Christopher <chris.su...@netapp.com<mailto:chris.su...@netapp.com>> wrote: It looks like some changes made in 858ce766659101eb731c83c806892dd5d9baa976 prohibit any managed storage pool other than ISCSI from starting a VM. It looks like you’ assuming that if the storage pool is managed then we should use getIscsiSR() to get the xen SR, which isn’t the case. I also believe I see this same issue in: -XenServerStorageProcessor.attachVolume() -VmwareStorageProcessor.attachVolume() -VmwareResource.inferDatastoreDetailsFromDiskInfo() although those may not be the only places. Can you please update/fix this? Or, can a committer please revert these changes until a fix is available. Thanks, Chris -- Chris Suich chris.su...@netapp.com<mailto:chris.su...@netapp.com> NetApp Software Engineer Data Center Platforms – Cloud Solutions Citrix, Cisco & Red Hat -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com> o: 303.746.7302<tel: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<mailto:mike.tutkow...@solidfire.com> o: 303.746.7302<tel: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<mailto:mike.tutkow...@solidfire.com> o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>™
