Re: CloudStack Storage Plug-in Framework for 4.2
I'm out of touch on the other technologies, but you probably wouldn't use a shared mount point on KVM. You would use the block devices themselves as they show up. Cluster LVM for KVM, for example, gives cloudstack a pool, where it creates virtual block devices, and those are treated like raw disks for the VMS to use. I would imagine a SAN storage plugin working nearly the same way, just pushing the pool out of the host OS and onto the SAN. Cloudstack still creates the volumes (via the plugin), but also does the work of connecting the luns to the proper hosts where their VMs will run, using them as dedicated block devices. Shared mount point would mean that you'd put a cluster filesystem on your dedicated lun, mount it, and then create a single flat file on it to represent your VM disk. On Mar 20, 2013 7:44 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Some questions have come up recently regarding the 4.2 storage plug-in that Edison implemented. In an attempt to clarify this, I'm sending out this e-mail with my understanding of how the new plug-in framework will operate in 4.2. Hopefully Edison or maybe David Nalley (but anyone else, of course) can comment on if this is accurate. Thanks! * The storage vendor creates a storage plug-in. * Primary Storage can be associated with this plug-in (as opposed to being associated with pre-existing storage). * When a Compute or Disk Offering is executed and it is tagged to use Primary Storage that makes use of this plug-in, the plug-in is invoked to create the necessary storage (let's say an iSCSI volume). * A datastore (for VMware) or a storage repository (for XenServer) then needs to be created for the SAN volume to be utilized from CS. I suppose a shared mount point would need to be created for KVM. * The VM or data disk is placed on the datastore or storage repository and it (the VM or data disk) is the only object that ever utilizes this datastore or storage repository (or shared mount point, for KVM). The idea behind this being that storage does not have to be set aside ahead of time in bulk and that you can map a single VM (or data disk) to a single, say, SAN volume. -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://solidfire.com/solution/overview/?video=play *™*
Re: CloudStack Storage Plug-in Framework for 4.2
Hi Marcus, Thanks for that info. I am not all that familiar with KVM ... at least yet. :) I had thought the way one would utilize an iSCSI target in CS today for KVM was via Shared Mount Point, but I could certainly be wrong. What are your thoughts on the other points I was making around the plug-in? Was I making sense in general? Thanks!! On Wed, Mar 20, 2013 at 7:54 PM, Marcus Sorensen shadow...@gmail.comwrote: I'm out of touch on the other technologies, but you probably wouldn't use a shared mount point on KVM. You would use the block devices themselves as they show up. Cluster LVM for KVM, for example, gives cloudstack a pool, where it creates virtual block devices, and those are treated like raw disks for the VMS to use. I would imagine a SAN storage plugin working nearly the same way, just pushing the pool out of the host OS and onto the SAN. Cloudstack still creates the volumes (via the plugin), but also does the work of connecting the luns to the proper hosts where their VMs will run, using them as dedicated block devices. Shared mount point would mean that you'd put a cluster filesystem on your dedicated lun, mount it, and then create a single flat file on it to represent your VM disk. On Mar 20, 2013 7:44 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Some questions have come up recently regarding the 4.2 storage plug-in that Edison implemented. In an attempt to clarify this, I'm sending out this e-mail with my understanding of how the new plug-in framework will operate in 4.2. Hopefully Edison or maybe David Nalley (but anyone else, of course) can comment on if this is accurate. Thanks! * The storage vendor creates a storage plug-in. * Primary Storage can be associated with this plug-in (as opposed to being associated with pre-existing storage). * When a Compute or Disk Offering is executed and it is tagged to use Primary Storage that makes use of this plug-in, the plug-in is invoked to create the necessary storage (let's say an iSCSI volume). * A datastore (for VMware) or a storage repository (for XenServer) then needs to be created for the SAN volume to be utilized from CS. I suppose a shared mount point would need to be created for KVM. * The VM or data disk is placed on the datastore or storage repository and it (the VM or data disk) is the only object that ever utilizes this datastore or storage repository (or shared mount point, for KVM). The idea behind this being that storage does not have to be set aside ahead of time in bulk and that you can map a single VM (or data disk) to a single, say, SAN volume. -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://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 cloudhttp://solidfire.com/solution/overview/?video=play *™*
Re: CloudStack Storage Plug-in Framework for 4.2
Yes, you can utilize an iscsi lun as shared mount point. Create a lun, make sure your hosts can see it, create a cluster filesystem on it, mount it on all hosts, then tell cloudstack about it so it can start creating VM disk images on it. But if you're talking about a 1:1 mapping of lun to VM disk, and doing it via plugin, you'll probably want to bypass the unnecessary cluster fs layer and just use the disks directly. On Mar 20, 2013 8:01 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi Marcus, Thanks for that info. I am not all that familiar with KVM ... at least yet. :) I had thought the way one would utilize an iSCSI target in CS today for KVM was via Shared Mount Point, but I could certainly be wrong. What are your thoughts on the other points I was making around the plug-in? Was I making sense in general? Thanks!! On Wed, Mar 20, 2013 at 7:54 PM, Marcus Sorensen shadow...@gmail.com wrote: I'm out of touch on the other technologies, but you probably wouldn't use a shared mount point on KVM. You would use the block devices themselves as they show up. Cluster LVM for KVM, for example, gives cloudstack a pool, where it creates virtual block devices, and those are treated like raw disks for the VMS to use. I would imagine a SAN storage plugin working nearly the same way, just pushing the pool out of the host OS and onto the SAN. Cloudstack still creates the volumes (via the plugin), but also does the work of connecting the luns to the proper hosts where their VMs will run, using them as dedicated block devices. Shared mount point would mean that you'd put a cluster filesystem on your dedicated lun, mount it, and then create a single flat file on it to represent your VM disk. On Mar 20, 2013 7:44 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Some questions have come up recently regarding the 4.2 storage plug-in that Edison implemented. In an attempt to clarify this, I'm sending out this e-mail with my understanding of how the new plug-in framework will operate in 4.2. Hopefully Edison or maybe David Nalley (but anyone else, of course) can comment on if this is accurate. Thanks! * The storage vendor creates a storage plug-in. * Primary Storage can be associated with this plug-in (as opposed to being associated with pre-existing storage). * When a Compute or Disk Offering is executed and it is tagged to use Primary Storage that makes use of this plug-in, the plug-in is invoked to create the necessary storage (let's say an iSCSI volume). * A datastore (for VMware) or a storage repository (for XenServer) then needs to be created for the SAN volume to be utilized from CS. I suppose a shared mount point would need to be created for KVM. * The VM or data disk is placed on the datastore or storage repository and it (the VM or data disk) is the only object that ever utilizes this datastore or storage repository (or shared mount point, for KVM). The idea behind this being that storage does not have to be set aside ahead of time in bulk and that you can map a single VM (or data disk) to a single, say, SAN volume. -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud™ -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud™
Re: CloudStack Storage Plug-in Framework for 4.2
I see...cool - thanks, Marcus! On Wed, Mar 20, 2013 at 8:08 PM, Marcus Sorensen shadow...@gmail.comwrote: Yes, you can utilize an iscsi lun as shared mount point. Create a lun, make sure your hosts can see it, create a cluster filesystem on it, mount it on all hosts, then tell cloudstack about it so it can start creating VM disk images on it. But if you're talking about a 1:1 mapping of lun to VM disk, and doing it via plugin, you'll probably want to bypass the unnecessary cluster fs layer and just use the disks directly. On Mar 20, 2013 8:01 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi Marcus, Thanks for that info. I am not all that familiar with KVM ... at least yet. :) I had thought the way one would utilize an iSCSI target in CS today for KVM was via Shared Mount Point, but I could certainly be wrong. What are your thoughts on the other points I was making around the plug-in? Was I making sense in general? Thanks!! On Wed, Mar 20, 2013 at 7:54 PM, Marcus Sorensen shadow...@gmail.com wrote: I'm out of touch on the other technologies, but you probably wouldn't use a shared mount point on KVM. You would use the block devices themselves as they show up. Cluster LVM for KVM, for example, gives cloudstack a pool, where it creates virtual block devices, and those are treated like raw disks for the VMS to use. I would imagine a SAN storage plugin working nearly the same way, just pushing the pool out of the host OS and onto the SAN. Cloudstack still creates the volumes (via the plugin), but also does the work of connecting the luns to the proper hosts where their VMs will run, using them as dedicated block devices. Shared mount point would mean that you'd put a cluster filesystem on your dedicated lun, mount it, and then create a single flat file on it to represent your VM disk. On Mar 20, 2013 7:44 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Some questions have come up recently regarding the 4.2 storage plug-in that Edison implemented. In an attempt to clarify this, I'm sending out this e-mail with my understanding of how the new plug-in framework will operate in 4.2. Hopefully Edison or maybe David Nalley (but anyone else, of course) can comment on if this is accurate. Thanks! * The storage vendor creates a storage plug-in. * Primary Storage can be associated with this plug-in (as opposed to being associated with pre-existing storage). * When a Compute or Disk Offering is executed and it is tagged to use Primary Storage that makes use of this plug-in, the plug-in is invoked to create the necessary storage (let's say an iSCSI volume). * A datastore (for VMware) or a storage repository (for XenServer) then needs to be created for the SAN volume to be utilized from CS. I suppose a shared mount point would need to be created for KVM. * The VM or data disk is placed on the datastore or storage repository and it (the VM or data disk) is the only object that ever utilizes this datastore or storage repository (or shared mount point, for KVM). The idea behind this being that storage does not have to be set aside ahead of time in bulk and that you can map a single VM (or data disk) to a single, say, SAN volume. -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud™ -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud™ -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://solidfire.com/solution/overview/?video=play *™*
Re: CloudStack Storage Plug-in Framework for 4.2
That's where I'm not sure. Its been a few years, and we always used vmfs, which is more of the shared pool model. VMware wants to have something to carve up rather than 1 disk per VM disk, but that doesn't mean it isn't possible. We've been building our own custom primary storage, but doing it in 4.1, since we don't want to wait. There's a decent amount of work to do on the host to get the disks connected up and usable, identified, and mapped to the right things ready for VMs. That work will exist even after the storage framework is in place. The work is done on the host by agent storage adaptors in KVM, I'm not sure if xen and VMware have an equivalent or if they just rely on xen and VMware supported pool types. On Mar 20, 2013 8:11 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hey Marcus, How do you see this plug-in working with VMware? On Wed, Mar 20, 2013 at 8:11 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: I see...cool - thanks, Marcus! On Wed, Mar 20, 2013 at 8:08 PM, Marcus Sorensen shadow...@gmail.comwrote: Yes, you can utilize an iscsi lun as shared mount point. Create a lun, make sure your hosts can see it, create a cluster filesystem on it, mount it on all hosts, then tell cloudstack about it so it can start creating VM disk images on it. But if you're talking about a 1:1 mapping of lun to VM disk, and doing it via plugin, you'll probably want to bypass the unnecessary cluster fs layer and just use the disks directly. On Mar 20, 2013 8:01 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi Marcus, Thanks for that info. I am not all that familiar with KVM ... at least yet. :) I had thought the way one would utilize an iSCSI target in CS today for KVM was via Shared Mount Point, but I could certainly be wrong. What are your thoughts on the other points I was making around the plug-in? Was I making sense in general? Thanks!! On Wed, Mar 20, 2013 at 7:54 PM, Marcus Sorensen shadow...@gmail.com wrote: I'm out of touch on the other technologies, but you probably wouldn't use a shared mount point on KVM. You would use the block devices themselves as they show up. Cluster LVM for KVM, for example, gives cloudstack a pool, where it creates virtual block devices, and those are treated like raw disks for the VMS to use. I would imagine a SAN storage plugin working nearly the same way, just pushing the pool out of the host OS and onto the SAN. Cloudstack still creates the volumes (via the plugin), but also does the work of connecting the luns to the proper hosts where their VMs will run, using them as dedicated block devices. Shared mount point would mean that you'd put a cluster filesystem on your dedicated lun, mount it, and then create a single flat file on it to represent your VM disk. On Mar 20, 2013 7:44 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Some questions have come up recently regarding the 4.2 storage plug-in that Edison implemented. In an attempt to clarify this, I'm sending out this e-mail with my understanding of how the new plug-in framework will operate in 4.2. Hopefully Edison or maybe David Nalley (but anyone else, of course) can comment on if this is accurate. Thanks! * The storage vendor creates a storage plug-in. * Primary Storage can be associated with this plug-in (as opposed to being associated with pre-existing storage). * When a Compute or Disk Offering is executed and it is tagged to use Primary Storage that makes use of this plug-in, the plug-in is invoked to create the necessary storage (let's say an iSCSI volume). * A datastore (for VMware) or a storage repository (for XenServer) then needs to be created for the SAN volume to be utilized from CS. I suppose a shared mount point would need to be created for KVM. * The VM or data disk is placed on the datastore or storage repository and it (the VM or data disk) is the only object that ever utilizes this datastore or storage repository (or shared mount point, for KVM). The idea behind this being that storage does not have to be set aside ahead of time in bulk and that you can map a single VM (or data disk) to a single, say, SAN volume. -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud™ -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud™ -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://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
Re: CloudStack Storage Plug-in Framework for 4.2
Interesting...thanks! On Wed, Mar 20, 2013 at 8:21 PM, Marcus Sorensen shadow...@gmail.comwrote: That's where I'm not sure. Its been a few years, and we always used vmfs, which is more of the shared pool model. VMware wants to have something to carve up rather than 1 disk per VM disk, but that doesn't mean it isn't possible. We've been building our own custom primary storage, but doing it in 4.1, since we don't want to wait. There's a decent amount of work to do on the host to get the disks connected up and usable, identified, and mapped to the right things ready for VMs. That work will exist even after the storage framework is in place. The work is done on the host by agent storage adaptors in KVM, I'm not sure if xen and VMware have an equivalent or if they just rely on xen and VMware supported pool types. On Mar 20, 2013 8:11 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hey Marcus, How do you see this plug-in working with VMware? On Wed, Mar 20, 2013 at 8:11 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: I see...cool - thanks, Marcus! On Wed, Mar 20, 2013 at 8:08 PM, Marcus Sorensen shadow...@gmail.comwrote: Yes, you can utilize an iscsi lun as shared mount point. Create a lun, make sure your hosts can see it, create a cluster filesystem on it, mount it on all hosts, then tell cloudstack about it so it can start creating VM disk images on it. But if you're talking about a 1:1 mapping of lun to VM disk, and doing it via plugin, you'll probably want to bypass the unnecessary cluster fs layer and just use the disks directly. On Mar 20, 2013 8:01 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi Marcus, Thanks for that info. I am not all that familiar with KVM ... at least yet. :) I had thought the way one would utilize an iSCSI target in CS today for KVM was via Shared Mount Point, but I could certainly be wrong. What are your thoughts on the other points I was making around the plug-in? Was I making sense in general? Thanks!! On Wed, Mar 20, 2013 at 7:54 PM, Marcus Sorensen shadow...@gmail.com wrote: I'm out of touch on the other technologies, but you probably wouldn't use a shared mount point on KVM. You would use the block devices themselves as they show up. Cluster LVM for KVM, for example, gives cloudstack a pool, where it creates virtual block devices, and those are treated like raw disks for the VMS to use. I would imagine a SAN storage plugin working nearly the same way, just pushing the pool out of the host OS and onto the SAN. Cloudstack still creates the volumes (via the plugin), but also does the work of connecting the luns to the proper hosts where their VMs will run, using them as dedicated block devices. Shared mount point would mean that you'd put a cluster filesystem on your dedicated lun, mount it, and then create a single flat file on it to represent your VM disk. On Mar 20, 2013 7:44 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Some questions have come up recently regarding the 4.2 storage plug-in that Edison implemented. In an attempt to clarify this, I'm sending out this e-mail with my understanding of how the new plug-in framework will operate in 4.2. Hopefully Edison or maybe David Nalley (but anyone else, of course) can comment on if this is accurate. Thanks! * The storage vendor creates a storage plug-in. * Primary Storage can be associated with this plug-in (as opposed to being associated with pre-existing storage). * When a Compute or Disk Offering is executed and it is tagged to use Primary Storage that makes use of this plug-in, the plug-in is invoked to create the necessary storage (let's say an iSCSI volume). * A datastore (for VMware) or a storage repository (for XenServer) then needs to be created for the SAN volume to be utilized from CS. I suppose a shared mount point would need to be created for KVM. * The VM or data disk is placed on the datastore or storage repository and it (the VM or data disk) is the only object that ever utilizes this datastore or storage repository (or shared mount point, for KVM). The idea behind this being that storage does not have to be set aside ahead of time in bulk and that you can map a single VM (or data disk) to a single, say, SAN volume. -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud™ -- Mike Tutkowski Senior CloudStack Developer, SolidFire Inc. e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud™ -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloudhttp://solidfire.com/solution/overview/?video=play *™* -- *Mike Tutkowski* *Senior CloudStack
