Quickly instantiating multiple VMs from the same base image is something
I don't work on.
A previous email mentioned Snowflock, which is designed to do a fast
instantiation of nearly identical VMs.
You might also look at OpenNebula, OSCAR-V, Ganeti, or any one of the
other VM creation tools.
If you have 100 different VM images that you want to bring up at the
same time, Xen infrastructure/developments won't really help you as it
is a problem they aren't really worried about.
Your best bet is to look at one of the higher layers (Snowflock, ...).
Hopefully I didn't miss the question you were asking.
Wesley
>
> What about this use-case?
>
> We have a supercomputer with 200,000 cores. And it is devoted to
> Infrastructure-as-a-Service cloud computing model. So this means it
> must be able to bring up different Virtual Machines lets say 100
> different Virtual Machine (depends on the workload) at the same time.
> We assume that supercomputer has Parallel File System to read Virtual
> Machine files concurrently by high speed.
> What sort of developments need to be done in Xen to manage this situation?
>
> Regards,
> Mehdi
>
> On Thu, Feb 18, 2010 at 6:39 PM, Wesley Emeneker
> <wesley.emeneker@gmail.com> wrote:
>> I've been researching (and measuring) this on x86_64 for about a year now.
>> I've been focusing on how cache structures affect the performance of a
>> range of scientific applications with various levels of VCPU-pinning.
>>
>> Some of the questions are:
>> 1. How much do the applications like/hate sharing a last level cache
>> (usually L2 or L3 depending on what the micro-architecture is)?
>> 2. Do TLBs have much of an effect?
>> 3. Depending on the answer to question 1, how well can applications
>> share a cache? i.e. if we have a CPU-intensive, small-memory application
>> how well does it share with a memory-hungry app?
>>
>>
>> What I've found is that a good many scientific applications actually
>> like sharing a cache.
>> If they don't share one, performance often suffers.
>>
>>
>>
>> Wesley Emeneker
>>
>>
>>> If we consider the future of computer systems with many cores, the
>>> problem of bringing multiple VMs at the same time on a multicore
>>> system becomes critical from the performance and speed point of view.
>>> I'd like to know whether is there any research on this topic?
>>>
>>> Regards,
>>> Mehdi
>> ***
>> This email has been stamped using Penny Post. Stamping email helps
>> combat spam.
>> Find out more about stamping your email at: http://pennypost.sourceforge.net
>>
>> _______________________________________________
>> Xen-research mailing list
>> Xen-research@lists.xensource.com
>> http://lists.xensource.com/mailman/listinfo/xen-research
>>
>
>
>
***
This email has been stamped using Penny Post. Stamping email helps
combat spam.
Find out more about stamping your email at: http://pennypost.sourceforge.net
_______________________________________________
Xen-research mailing list
Xen-research@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-research
I don't work on.
A previous email mentioned Snowflock, which is designed to do a fast
instantiation of nearly identical VMs.
You might also look at OpenNebula, OSCAR-V, Ganeti, or any one of the
other VM creation tools.
If you have 100 different VM images that you want to bring up at the
same time, Xen infrastructure/developments won't really help you as it
is a problem they aren't really worried about.
Your best bet is to look at one of the higher layers (Snowflock, ...).
Hopefully I didn't miss the question you were asking.
Wesley
>
> What about this use-case?
>
> We have a supercomputer with 200,000 cores. And it is devoted to
> Infrastructure-as-a-Service cloud computing model. So this means it
> must be able to bring up different Virtual Machines lets say 100
> different Virtual Machine (depends on the workload) at the same time.
> We assume that supercomputer has Parallel File System to read Virtual
> Machine files concurrently by high speed.
> What sort of developments need to be done in Xen to manage this situation?
>
> Regards,
> Mehdi
>
> On Thu, Feb 18, 2010 at 6:39 PM, Wesley Emeneker
> <wesley.emeneker@gmail.com> wrote:
>> I've been researching (and measuring) this on x86_64 for about a year now.
>> I've been focusing on how cache structures affect the performance of a
>> range of scientific applications with various levels of VCPU-pinning.
>>
>> Some of the questions are:
>> 1. How much do the applications like/hate sharing a last level cache
>> (usually L2 or L3 depending on what the micro-architecture is)?
>> 2. Do TLBs have much of an effect?
>> 3. Depending on the answer to question 1, how well can applications
>> share a cache? i.e. if we have a CPU-intensive, small-memory application
>> how well does it share with a memory-hungry app?
>>
>>
>> What I've found is that a good many scientific applications actually
>> like sharing a cache.
>> If they don't share one, performance often suffers.
>>
>>
>>
>> Wesley Emeneker
>>
>>
>>> If we consider the future of computer systems with many cores, the
>>> problem of bringing multiple VMs at the same time on a multicore
>>> system becomes critical from the performance and speed point of view.
>>> I'd like to know whether is there any research on this topic?
>>>
>>> Regards,
>>> Mehdi
>> ***
>> This email has been stamped using Penny Post. Stamping email helps
>> combat spam.
>> Find out more about stamping your email at: http://pennypost.sourceforge.net
>>
>> _______________________________________________
>> Xen-research mailing list
>> Xen-research@lists.xensource.com
>> http://lists.xensource.com/mailman/listinfo/xen-research
>>
>
>
>
***
This email has been stamped using Penny Post. Stamping email helps
combat spam.
Find out more about stamping your email at: http://pennypost.sourceforge.net
_______________________________________________
Xen-research mailing list
Xen-research@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-research