that is virtualization for aggregation, or reverse virtualization. it's about the hypervisor, not opnstk.
> 在 2013年12月24日,13:54,Vikas Parashar <para.vi...@gmail.com> 写道: > > 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 <harlo...@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.fal...@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 <harlo...@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.vi...@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.fal...@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.vi...@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@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@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@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@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack