cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: [QUESTION] VMware ServerResource
Date Tue, 01 Apr 2014 02:34:17 GMT
Interesting...when I try to unmount the datastore prior to removing the
iSCSI connections, I get a similar error to when I straight-out try to
delete the datastore prior to removing the iSCSI connections: it says the
datastore is still in use.

When I look at the contents of the datastore, there doesn't appear to be
anything on it.

There is a clue in the fact that this is only a problem if a VM was running
off of this datastore. If the datastore was only used to house a VMDK file
for a data disk, there is no problem removing it by getting rid of the
iSCSI connections to the SAN volume from the hosts.


On Mon, Mar 31, 2014 at 4:44 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Thanks, Kelven...I had seen a similar article about Storage IO
> Control...perhaps the article you pointed to has more info.
>
>
> On Mon, Mar 31, 2014 at 4:38 PM, Kelven Yang <kelven.yang@citrix.com>wrote:
>
>> Would this KB article helpful? Particularly, it seems that Stroage IO
>> control needs to disabled before detaching the datastore.
>>
>>
>> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di
>> splayKC&externalId=2004605<http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004605>
>>
>> Kelven
>>
>> On 3/31/14, 3:14 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com>
>> wrote:
>>
>> >Interesting...I can look into that. Do you know off hand if we already
>> >have
>> >such a call to perform an unmount?
>> >
>> >Thanks, Kelven!
>> >
>> >
>> >On Mon, Mar 31, 2014 at 3:28 PM, Kelven Yang <kelven.yang@citrix.com>
>> >wrote:
>> >
>> >>
>> >> On 3/31/14, 1:54 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com>
>> >> wrote:
>> >>
>> >> >Hi Kelven,
>> >> >
>> >> >Thanks for the info!
>> >> >
>> >> >I have another question that perhaps you can answer.
>> >> >
>> >> >In my situation, with managed storage, I need to create and delete
>> >> >datastores dynamically. The idea is to have a single VM (and all of
>> its
>> >> >corresponding files) or a single VMDK data disk file per datastore in
>> >>some
>> >> >cases so we can guarantee IOPS to the VM or data disk.
>> >> >
>> >> >Each datastore is based on an iSCSI target that has guaranteed IOPS.
>> >> >
>> >> >For data disks, this process has worked perfectly (first implemented
>> in
>> >> >4.2). When I need the datastore, I create an iSCSI target on my SAN,
>> >>then
>> >> >establish a connection to it from each host in the VMware cluster,
>> then
>> >> >create a datastore on the target.
>> >> >
>> >> >When I no longer need the data disk, I remove the iSCSI targets from
>> >>the
>> >> >hosts and the datastore goes away.
>> >> >
>> >> >This same process works pretty well for root disks (and the other
>> >>files of
>> >> >a VM) except for when I want to delete the VM and get rid of its
>> >> >datastore.
>> >> >In this case, I follow the same process of removing the iSCSI
>> >>connections
>> >> >from each host in the cluster, but the datastore still shows up in
>> >>vCenter
>> >> >(albeit greyed out and in the inactive state when viewed through
>> >>vSphere
>> >> >Client).
>> >> >
>> >> >Any thoughts on this? I've looked into this on the web and the general
>> >> >consensus is that the datastore is still somehow in use by vCenter.
>> Not
>> >> >sure why that would be, though.
>> >>
>> >>
>> >> Have you checked if the datastore is unmounted from all hosts within
>> the
>> >> cluster? When iSCSI target is added as a VMFS datastore, I believe all
>> >> hosts within the cluster will mount it automatically. To remove the
>> >> datastore from vCenter, you probably need to make sure the datastore is
>> >> unmounted from all hosts.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >> >Thanks!
>> >> >Mike
>> >> >
>> >> >
>> >> >On Mon, Mar 31, 2014 at 2:45 PM, Kelven Yang <kelven.yang@citrix.com>
>> >> >wrote:
>> >> >
>> >> >>
>> >> >>
>> >> >> On 3/29/14, 7:31 PM, "Sateesh Chodapuneedi"
>> >> >> <sateesh.chodapuneedi@citrix.com> wrote:
>> >> >>
>> >> >> >> -----Original Message-----
>> >> >> >> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>> >> >> >> Sent: 30 March 2014 00:06
>> >> >> >> To: dev@cloudstack.apache.org
>> >> >> >> Subject: [QUESTION] VMware ServerResource
>> >> >> >>
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> Quick question:
>> >> >> >>
>> >> >> >> For VMware, since we have vCenter Server in the mix as
opposed to
>> >> >>just
>> >> >> >> ESX(i) hosts, I was wondering how that works out with
our related
>> >> >> >>ServerResources.
>> >> >> >>
>> >> >> >> For example, if you have a cluster with three ESX hosts,
does
>> that
>> >> >> >>equate to three ServerResources running on the management
server?
>> >> >> >Yes, each host is tracked by a server resource. CloudStack
>> retrieves
>> >> >> >owning cluster/datacenter as required from vCenter and performs
>> >> >>required
>> >> >> >operations.
>> >> >> >
>> >> >> >>
>> >> >> >> Assuming that leads to three ServerResources in that situation,
>> if
>> >> >>you
>> >> >> >>have multiple management servers for your cloud, do all
three of
>> >> >> >> these ServerResources have to be managed by a single management
>> >> >>server
>> >> >> >>(because their resources are in the same cluster)?
>> >> >> >I think it is not required to be managed by a single management
>> >>server.
>> >> >>
>> >> >>
>> >> >> Yes, it is not required to be managed by a single management server.
>> >>One
>> >> >> thing to note that, all resource instances are now sharing a pool
of
>> >> >> vCenter sessions, an instance of such vCenter session is acquired
>> and
>> >> >> released by server resource when it needs to perform operations
to
>> >> >>vCenter.
>> >> >>
>> >> >>
>> >> >> >
>> >> >> >>
>> >> >> >> Thanks!
>> >> >> >>
>> >> >> >> --
>> >> >> >> *Mike Tutkowski*
>> >> >> >> *Senior CloudStack Developer, SolidFire Inc.*
>> >> >> >> e: mike.tutkowski@solidfire.com
>> >> >> >> o: 303.746.7302
>> >> >> >> Advancing the way the world uses the
>> >> >> >> cloud<http://solidfire.com/solution/overview/?video=play>
>> >> >> >> *(tm)*
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >--
>> >> >*Mike Tutkowski*
>> >> >*Senior CloudStack Developer, SolidFire Inc.*
>> >> >e: mike.tutkowski@solidfire.com
>> >> >o: 303.746.7302
>> >> >Advancing the way the world uses the
>> >> >cloud<http://solidfire.com/solution/overview/?video=play>
>> >> >*(tm)*
>> >>
>> >>
>> >
>> >
>> >--
>> >*Mike Tutkowski*
>> >*Senior CloudStack Developer, SolidFire Inc.*
>> >e: mike.tutkowski@solidfire.com
>> >o: 303.746.7302
>> >Advancing the way the world uses the
>> >cloud<http://solidfire.com/solution/overview/?video=play>
>> >*(tm)*
>>
>>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message