Open Stack

None of said features, cross host CPUs or cross host RAM (combining cross host resources to form a larger virtual one?) afaik exist (maybe they exist in prototypes since it is theoretically possible). Especially since this will likely be really slow to perform. Afaik current virtualization isn't meant to replace openmp or mpi (or similar), does that answer your question?

Sent from my really tiny device...

On Dec 23, 2013, at 9:58 PM, "Vikas Parashar" <para.vikas at gmail.com<mailto:para.vikas at gmail.com>> wrote:

Thanks everyone for your valuable point.

Kindly allow me to put my Question in different way.

Shall any VM use distributed(for eg. RAM from the different host) resources at the same time?

or

Shall any VM use two cores(that lies on different hosts) at the same time?, in the distributed fashion.


On Tue, Dec 24, 2013 at 2:36 AM, Joshua Harlow <harlowja at yahoo-inc.com<mailto:harlowja at yahoo-inc.com>> wrote:
There are much bigger differences for why u should not over-provision
memory vs over-provision cpu.

But agreed in general you shouldn't use swap either.

There are many threads around how the OOM killer will get involved and why
you should avoid this...

- http://marc.info/?l=kvm&m=127375381631230&w=2
- http://www.spinics.net/lists/kvm/msg84799.html
- ...

On 12/23/13, 12:55 PM, "Cristian Falcas" <cristi.falcas at gmail.com<mailto:cristi.falcas at gmail.com>> wrote:

>There is no point in using 8 virtual cores in compute node with 2
>cores. The same is valid for using swap as memory to reach the desired
>12gb.
>
>Of course, if you don't plan on using that machine for any real work,
>you can do it.
>
>
>
>On Mon, Dec 23, 2013 at 6:39 PM, Joshua Harlow <harlowja at yahoo-inc.com<mailto:harlowja at yahoo-inc.com>>
>wrote:
>> Nope, u can over provision on most all of the resources (CPU, ram,
>>disk) u
>> described there. Ram is the tricky one as the Linux oom killer may
>>start to
>> get involved when u push the ram limits to high. But there is nothing
>> stopping u from running 8 or more vms on a box, depending on the over
>> provision ratio u are ok with...
>>
>> Sent from my really tiny device...
>>
>> On Dec 23, 2013, at 3:55 AM, "Vikas Parashar" <para.vikas at gmail.com<mailto:para.vikas at gmail.com>>
>>wrote:
>>
>> Thanks Cristian,
>>
>> Will elasticity  be limited to 4 Cores/4GB  (The max capacity of a
>>physical
>> host) ?
>>
>>
>> On Mon, Dec 23, 2013 at 5:00 PM, Cristian Falcas
>><cristi.falcas at gmail.com<mailto:cristi.falcas at gmail.com>>
>> wrote:
>>>
>>> Hi,
>>>
>>> From what I know you can resize a machine, but this involves
>>> rebuilding the instance: openstack will create a snapshot of the
>>> machine an recreate the instance with the new snapshot and a new
>>> flavor. This is not very fast from my experience, so you will have a
>>> considerable downtime doing this, depending on the size of the current
>>> instance and how fast is your storage.
>>>
>>> Best regards,
>>> Cristian Falcas
>>>
>>>
>>>
>>> On Mon, Dec 23, 2013 at 12:03 PM, Vikas Parashar <para.vikas at gmail.com<mailto:para.vikas at gmail.com>>
>>> wrote:
>>> > Hi,
>>> >
>>> > IaaS is all about elastic computing. I can stretch resources as per
>>>my
>>> > need
>>> > - increasing/decreasing the number of cores, RAM allocated etc..
>>> >
>>> > My question is - how does openStack achieve this elasticity for both
>>> > computation and RAM.
>>> >
>>> > If I create an image with 2 cores and 4 GB RAM (and one day I need to
>>> > increase this to, lets say - 6 Cores and 12 GB RAM), but all the
>>> > physical
>>> > hosts that I currently have (for Compute and RAM) at my disposal
>>>have a
>>> > max
>>> > of 4 Cores and 4 GB RAM each..
>>> >
>>> > Using openStack -
>>> >
>>> > a) is this possible (as long as the total cores and total RAM
>>>required
>>> > is
>>> > less than the group-total) ? If yes, how is this achieved.
>>> >
>>> > b) or the elasticity will be limited to 4 Cores/4GB  (The max
>>>capacity
>>> > of a
>>> > physical host) ? If no, then is it possible to achieve it ?
>>> >
>>> > _______________________________________________
>>> > Mailing list:
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> > Post to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>
>>> > Unsubscribe :
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> >
>>
>>
>> _______________________________________________
>> Mailing list:
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>
>> Unsubscribe :
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131225/b7052d6e/attachment.html>