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: Hypervisor Questions
Date Sat, 05 Oct 2013 04:19:12 GMT
Right, Marcus, what you say makes sense.

You brought up a point I was going to ask about: If you can migrate between
clusters, what's the point of a cluster?

That point aside, I was really more interested (for the purposes of this
e-mail thread) to find out how this works for KVM today (not to recommend
adding a new feature if cross-cluster support is not currently in
CloudStack for KVM).

By your response, can I assume you can "only" migrate a VM from one KVM
host to another in the same cluster?

Thanks


On Fri, Oct 4, 2013 at 9:48 PM, Marcus Sorensen <shadowsor@gmail.com> wrote:

> From a kvm standpoint, a cluster has admin-defined meaning. Its not always
> going to map to some externally defined cluster.  I can make my whole data
> center a cluster, and not use zone-wide storage, or still use zone wide
> storage. If you have zone-wide storage, maybe you want to keep VMs within
> small defined clusters for some non-storage reason. It makes sense to me to
> keep the cluster as an entity that confines where a vm can run, regardless
> of zone wide storage, otherwise is there a purpose to it at all? Maybe we
> can offer a migrate vm between cluster function if zone-wide is in use?
> Also keep in mind that there's a pod level. You'd still need to be in the
> same pod if you wanted to jump between clusters.
> On Oct 4, 2013 5:05 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com>
> wrote:
>
>> Perhaps Marcus can answer this from a KVM standpoint?
>>
>>
>> On Fri, Oct 4, 2013 at 5:03 PM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>>
>>> This implies live migration between VMware clusters is supported in
>>> CloudStack:
>>>
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4265
>>>
>>>
>>> On Fri, Oct 4, 2013 at 4:56 PM, Mike Tutkowski <
>>> mike.tutkowski@solidfire.com> wrote:
>>>
>>>> For anyone who is interested in the outcome of this thread, this seems
>>>> to answer the XenServer part:
>>>>
>>>>
>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enabling+Storage+XenMotion+for+XenServer
>>>>
>>>> "CloudStack currently allows live migration of a virtual machine from
>>>> one host to another only within a cluster."
>>>>
>>>> Document was last updated June 28, 2013.
>>>>
>>>>
>>>> On Fri, Oct 4, 2013 at 12:41 PM, Mike Tutkowski <
>>>> mike.tutkowski@solidfire.com> wrote:
>>>>
>>>>> Yeah, that's kind of what I was interested in learning about.
>>>>>
>>>>> Now that we have zone-wide primary storage, does that mean CS is able
>>>>> to issue the live migration of a VM from one cluster to another (or are
we
>>>>> still confined to clusters)?
>>>>>
>>>>>
>>>>> On Fri, Oct 4, 2013 at 11:55 AM, Travis Graham <tgraham@tgraham.us>wrote:
>>>>>
>>>>>> Was that a limitation caused by the primary storage only being
>>>>>> available to a single cluster and not zone wide like 4.2.0 provides?
>>>>>>
>>>>>> Travis
>>>>>>
>>>>>> On Oct 4, 2013, at 1:52 PM, Mike Tutkowski <
>>>>>> mike.tutkowski@solidfire.com> wrote:
>>>>>>
>>>>>> > Maybe this is a silly question, but if CS handles Live Migrations,
>>>>>> are we
>>>>>> > still constrained to migrating VMs from one host to another
in the
>>>>>> same
>>>>>> > cluster?
>>>>>> >
>>>>>> > Same question for HA.
>>>>>> >
>>>>>> >
>>>>>> > On Wed, Oct 2, 2013 at 8:42 AM, Clayton Weise <cweise@keyinfo.com>
>>>>>> wrote:
>>>>>> >
>>>>>> >> AFAIK, no, but it's a great RFE that I would vote for.
>>>>>> >>
>>>>>> >> -----Original Message-----
>>>>>> >> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>> >> Sent: Tuesday, October 01, 2013 9:26 PM
>>>>>> >> To: dev@cloudstack.apache.org
>>>>>> >> Subject: Re: Hypervisor Questions
>>>>>> >>
>>>>>> >> Oh, and, yes, when I referred to HA, it was (as you said)
with the
>>>>>> meaning
>>>>>> >> of a host going offline and VMs being restarted on other
hosts
>>>>>> (perhaps in
>>>>>> >> a prioritized order if there are an insufficient number
of
>>>>>> resources to
>>>>>> >> support all of the VMs that were running on the downed host).
>>>>>> >>
>>>>>> >> Does CS support assigning a priority to a VM in case not
all VMs
>>>>>> can be
>>>>>> >> restarted on the remaining resources?
>>>>>> >>
>>>>>> >>
>>>>>> >> On Tue, Oct 1, 2013 at 6:35 PM, Mike Tutkowski <
>>>>>> >> mike.tutkowski@solidfire.com
>>>>>> >>> wrote:
>>>>>> >>
>>>>>> >>> Thanks, Clayton!
>>>>>> >>>
>>>>>> >>> Yeah, copy/paste mistake there. :) I meant it as you
said.
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> On Tue, Oct 1, 2013 at 4:54 PM, Clayton Weise <cweise@keyinfo.com
>>>>>> >
>>>>>> >> wrote:
>>>>>> >>>
>>>>>> >>>> First, I think you meant to put XenServer, KVM,
and VMware and
>>>>>> not
>>>>>> >>>> XenServer 3 times in a row.  That being said I think
in all cases
>>>>>> >>>> (somebody correct me if I'm wrong here) it goes
something like
>>>>>> this:
>>>>>> >>>>
>>>>>> >>>> Live Migration: Request is made by CS but carried
out by the HV.
>>>>>> >>>> High Availability: More accurately it's "recovery
after host
>>>>>> failure"
>>>>>> >>>> because it's still a disruptive action when a host
goes
>>>>>> sideways, but
>>>>>> >>>> by default this is handled by CS.  I _think_ there's
an option
>>>>>> to let
>>>>>> >>>> the HV handle this but I'm not totally sure.
>>>>>> >>>> DRS: Managed by CS through one of several methods
with the global
>>>>>> >>>> setting vm.allocation.algorithm (see below)
>>>>>> >>>>
>>>>>> >>>> 'random', 'firstfit', 'userdispersing',
>>>>>> 'userconcentratedpod_random',
>>>>>> >>>> 'userconcentratedpod_firstfit' : Order in which
hosts within a
>>>>>> >>>> cluster will be considered for VM/volume allocation.
>>>>>> >>>>
>>>>>> >>>> That being said, after deployment there isn't any
further DRS
>>>>>> >>>> monitoring; it's only done at the time an instance
is
>>>>>> instantiated.
>>>>>> >>>>
>>>>>> >>>> -Clayton
>>>>>> >>>>
>>>>>> >>>> -----Original Message-----
>>>>>> >>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>>>>> >>>> Sent: Tuesday, October 01, 2013 3:00 PM
>>>>>> >>>> To: dev@cloudstack.apache.org
>>>>>> >>>> Subject: Hypervisor Questions
>>>>>> >>>>
>>>>>> >>>> Hi,
>>>>>> >>>>
>>>>>> >>>> I was wondering if people could clarify for me what
CloudStack
>>>>>> >>>> manages versus what the hypervisor manages in terms
of live
>>>>>> >>>> migration, high availability, and distributed resource
>>>>>> scheduling?
>>>>>> >>>>
>>>>>> >>>> I know it is probably different for XenServer, VMware,
and KVM.
>>>>>> >>>>
>>>>>> >>>> Can people fill in the info below (managed by the
management
>>>>>> server,
>>>>>> >>>> the hypervisor, or some combination of both)?
>>>>>> >>>>
>>>>>> >>>> XenServer
>>>>>> >>>>   Live migration:
>>>>>> >>>>   High availability:
>>>>>> >>>>   Distributed Resource Scheduling:
>>>>>> >>>>
>>>>>> >>>> XenServer
>>>>>> >>>>   Live migration:
>>>>>> >>>>   High availability:
>>>>>> >>>>   Distributed Resource Scheduling:
>>>>>> >>>>
>>>>>> >>>> XenServer
>>>>>> >>>>   Live migration:
>>>>>> >>>>   High availability:
>>>>>> >>>>   Distributed Resource Scheduling:
>>>>>> >>>>
>>>>>> >>>> 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>
>>>>>> > *™*
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *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>
>>>>> *™*
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *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>
>>>> *™*
>>>>
>>>
>>>
>>>
>>> --
>>> *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>
>>> *™*
>>>
>>
>>
>>
>> --
>> *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>
>> *™*
>>
>


-- 
*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>
*™*

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