The only VMWare functionality that allows a VM to be "spread across
multiple hosts" is vLockstep (VMWare Fault Tolerance). This
functionality makes an identical clone of a VM on another host and
replays actions taken on the primary against the cloned VM.
So... not really spreading a single VM across multiple hosts but rather
synchronous replication of all changes to one VM's state to a clone of it.
https://kb.vmware.com/s/article/1013428
That said, this is about the least "cloudy" thing I can imagine and
isn't something that a cloud-native application should rely on.
Based on the OP's original question, he may also be referring to VMWare
DPM functionality, which is something that automatically live migrates
(via vMotion) VMs from one host to another in a cluster in order to
consolidate and then powers down the free hosts.
Best,
-jay
On 02/15/2018 04:31 PM, 'David Oppenheimer' via Kubernetes user
discussion and Q&A wrote:
I read the VMWare page. AFAICT they are not saying that a VM can be
spread across multiple physical hosts. A "resource pool" appears to be a
quota pool. They are using a quota model somewhat like the
kube-arbitrator
<https://github.com/kubernetes-incubator/kube-arbitrator>, where quota
is a guaranteed minimum (rather than a maximum like Kubernetes
ResourceQuota), and they're saying that if there is unused quota in some
pool, then it becomes available to other pools on a temporary basis. So
a VM may be drawing resources (quota) from multiple resource (quota)
pools, but the VM is only actually running on a single physical host.
At least, that's my reading of the page.
On Thu, Feb 15, 2018 at 9:16 AM, 'Tim Hockin' via Kubernetes user
discussion and Q&A <kubernetes-users@googlegroups.com
<mailto:kubernetes-users@googlegroups.com>> wrote:
I don't know VMWare either, but that seems disastrous from a
predictability point of view.
On Wed, Feb 14, 2018 at 8:02 PM, Warren Strange
<warren.stra...@gmail.com <mailto:warren.stra...@gmail.com>> wrote:
>
> AFAIK you can not split a pod between more than one node.
>
> I know nothing about VMware, but I am guessing they can split VM
processes
> across nodes, which is pretty much equivalent to what Kubernetes
does with
> pods (VM process == a pod, roughly speaking).
>
>
>
> On Wednesday, February 14, 2018 at 8:04:30 PM UTC-7, chez wrote:
>>
>> Folks,
>> Looks like VMware with vsphere (and vcenter?) is able to allocate
>> resources (vcpu for instance) across hosts for a single VM ? Is this
>> possible with kubernetes for containers ?
>> Can kubernetes pool vcpu between multiple hosts/nodes for one
container ?
>>
>>
https://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsphere.intro.doc_41/c_hosts_clusters_and_resource_pools.html
<https://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsphere.intro.doc_41/c_hosts_clusters_and_resource_pools.html>
>>
>> I am really intrigued by this statement -
>> "You can dynamically change resource allocation policies. For
example, at
>> year end, the workload on Accounting increases, and which
requires an
>> increase in the Accounting resource pool reserve of 4GHz of
power to 6GHz.
>> You can make the change to the resource pool dynamically without
shutting
>> down the associated virtual machines."
>>
>> Each physical host is 4Ghz, but this doc says it can pull 2Ghz
out of the
>> second host. Is it because of ESXi ?
>>
>> thanks
>>
> --
> You received this message because you are subscribed to the
Google Groups
> "Kubernetes user discussion and Q&A" group.
> To unsubscribe from this group and stop receiving emails from it,
send an
> email to kubernetes-users+unsubscr...@googlegroups.com
<mailto:kubernetes-users%2bunsubscr...@googlegroups.com>.
> To post to this group, send email to
kubernetes-users@googlegroups.com
<mailto:kubernetes-users@googlegroups.com>.
> Visit this group at
https://groups.google.com/group/kubernetes-users
<https://groups.google.com/group/kubernetes-users>.
> For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google
Groups "Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to kubernetes-users+unsubscr...@googlegroups.com
<mailto:kubernetes-users%2bunsubscr...@googlegroups.com>.
To post to this group, send email to
kubernetes-users@googlegroups.com
<mailto:kubernetes-users@googlegroups.com>.
Visit this group at https://groups.google.com/group/kubernetes-users
<https://groups.google.com/group/kubernetes-users>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google
Groups "Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to kubernetes-users+unsubscr...@googlegroups.com
<mailto:kubernetes-users+unsubscr...@googlegroups.com>.
To post to this group, send email to kubernetes-users@googlegroups.com
<mailto:kubernetes-users@googlegroups.com>.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Kubernetes
user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to kubernetes-users+unsubscr...@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.
