[ovirt-users] running vm when its configured memory is bigger than host memory
Jiří Sléžka
jiri.slezka at slu.cz
Tue Mar 24 16:04:16 UTC 2015
Hello,
my colleague uses oVirt3.5 for scientific purposes and has a question.
As I know he needs to run virtual machine with huge amount of over
allocated memory (more than one host has) and when it is really needed
then migrate it to host where is much more memory.
It looks to me like nice use case for oVirt.
But here is his own question.
> Currently, the virtual machine of given memory size S cannot be run
> on the host with less than S physical memory.
>
> We need to run several virtual machines (with unpredictable memory
> requirements) on the cluster consisting of several different hosts
> (with different amount of physical memory) in such the way that any
> virtual machine can be run on any host.
>
> Due to Ovirt limitation, virtual machines memory sizes has to be set
> to the MINIMUM of host physical memory sizes (in order to be able to
> run any virtual machine on any host). As far as I know, this rule has
> no connection to cluster's Memory optimization 'Max Memory Over
> Commitment' parameter.
>
> But we cannot predict memory needs of our virtual machines so we need
> to set the memory size of all of them to the MAXIMUM of host's
> physical memory sizes.
>
> Explanation:
>
> We are running several computational tasks (every one on single
> independent virtual machine). We have several (and different) host
> machines (see Figure 1).
>
> 1. At the beginning, every task consumes a decent amount of memory.
>
> 2. After a while, some task(s) allocate a huge amount of memory
> (Figure 2). At this moment, some of them cannot continue (due to
> unavailable memory on its current host) without migration to the host
> with higher memory available.
>
> 3. After migration (Figure 3), all tasks may continue.
>
> 4. Some tasks finally consumes a LOT of memory (Figure 4).
>
> The algorithm above cannot be realized, since every virtual machine
> (i.e. task) has predefined (and fixed when running) its memory size
> set to the MINIMUM of hosts physical memory sizes.
Thanks in advance
Jiri Slezka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Figure 4.jpg
Type: image/jpeg
Size: 51531 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/users/attachments/20150324/f17c7fee/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Figure 2.jpg
Type: image/jpeg
Size: 50276 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/users/attachments/20150324/f17c7fee/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Figure 3.jpg
Type: image/jpeg
Size: 47091 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/users/attachments/20150324/f17c7fee/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Figure 1.jpg
Type: image/jpeg
Size: 45671 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/users/attachments/20150324/f17c7fee/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jiri_slezka.vcf
Type: text/x-vcard
Size: 586 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/users/attachments/20150324/f17c7fee/attachment-0001.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3247 bytes
Desc: Elektronicky podpis S/MIME
URL: <http://lists.ovirt.org/pipermail/users/attachments/20150324/f17c7fee/attachment-0001.p7s>
More information about the Users
mailing list