memory hotplug for guests?

Does KVM allow something like "memory hotplug" for its guests?

For example, lets says you are running several guests, and would like

start yet another one for a while - but have no free memory left.

Obviously, your guests are so important that you don't want to stop

- so you simply "hotplug remove" memory from a guest that has a lot of free memory left - and start a new guest.

When that new guest is no longer needed, and is stopped, you can "hotplug add" memory to the guest it was previously removed from.

Guest's kernel would of course need to support memory hotplugging, too.

Is it possible with KVM? If not, is such a feature planned?

I noticed it was only mentioned once or twice on the list:

http://article.gmane.org/gmane.comp.emulators.kvm.devel/712/

"Well, the _interface_ supports removing, the implementation does not

Everything was written in mind to allow memory hotplug."

--
Tomasz Chmielewski
http://wpkg.org

-----------------------------------------------------------------------

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVD

_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Quoted 1 line

For example, lets says you are running several guests, and would like

to

Quoted 2 lines

start yet another one for a while - but have no free memory left.

We have another solution for it that will soon be pushed into the kernel:
It is the balloon driver solution.
Each guest runs a balloon driver, when the host needs to free up memory a daemon with certain policy asks some of the guests to inflate their balloon,
KVM frees their ballooned pages and the host free memory increases. When the memory pressure relives, the balloons get deflate command.

Quoted 1 line

Quoted 1 line

For example, lets says you are running several guests, and would

Quoted 8 lines

to

Quoted 2 lines

start yet another one for a while - but have no free memory left.

We have another solution for it that will soon be pushed into the kernel:
It is the balloon driver solution.
Each guest runs a balloon driver, when the host needs to free up

Quoted 4 lines

a daemon with certain policy asks some of the guests to inflate their balloon,
KVM frees their ballooned pages and the host free memory increases. When the memory pressure relives, the balloons get deflate command.

You probably want to have a look at arch/s390/mm/cmm.c which is exactly doing what you want. Of course the message interface to the hypervisor is different to what you want to do.

Quoted 1 line

Quoted 1 line

Quoted 1 line

For example, lets says you are running several guests, and would

like

Quoted 8 lines

Quoted 8 lines

to

Quoted 2 lines

start yet another one for a while - but have no free memory left.

We have another solution for it that will soon be pushed into the kernel:
It is the balloon driver solution.
Each guest runs a balloon driver, when the host needs to free up

memory

Quoted 5 lines

Quoted 4 lines

a daemon with certain policy asks some of the guests to inflate their balloon,
KVM frees their ballooned pages and the host free memory increases. When the memory pressure relives, the balloons get deflate command.

Quoted 3 lines

You probably want to have a look at arch/s390/mm/cmm.c which is exactly doing what you want. Of course the message interface to the hypervisor is different to what you want to do.

Gee, thanks, I wasn't aware of it. I wrote the Linux driver, not yet ready for mainline. This might change things and I'll might use/change the cmm.
It will take a while because my queue is jammed with too much stuff.

Another driver you might want to look at is the Xen balloon driver:
http://81.161.245.2/lxr/http/source/linux-2.6-xen-sparse/drivers/xen/balloon/balloon.c

The s390 driver is probably a better example though. One thing the Xen one got wrong is that its interface requires you do an hcall in order to get back a page that you gave up to the host.

On s390, it
simply maps the host empty_zero_page as COW into the guest like the initial memory, so you get a new page back with the regular method whenever you write to the guest real page.

Quoted 3 lines · Arnd Bergmann

Another driver you might want to look at is the Xen balloon driver:
http://81.161.245.2/lxr/http/source/linux-2.6-xen-

sparse/drivers/xen/balloon/balloon.c

Quoted 4 lines

The s390 driver is probably a better example though. One thing the Xen one got wrong is that its interface requires you do an hcall in order to get back a page that you gave up to the host.

Er, that's what we do :)

Quoted 6 lines

On s390, it
simply maps the host empty_zero_page as COW into the guest like the initial memory, so you get a new page back with the regular method whenever you write to the guest real page.

This has the advantage of surviving a guest reboot, but the

of not allowing the host to nack the request.

--
error compiling committee.c: too many arguments to function

-----------------------------------------------------------------------

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVD

_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Currently the only memory-over-commit mechanism is the balloon. In the future we will add all the wise spectrum of host demand pages, shared pages, etc.

Quoted 4 lines · Dor Laor

Currently the only memory-over-commit mechanism is the balloon. In the future we will add all the wise spectrum of host demand pages, shared pages, etc.

Ok, just as another hint: you should definitely take a look at pfault_interrupt() in arch/s390/mm/fault.c, which manages notifications about host memory manangement, so that the guest can put a task to sleep that accesses a page on the host block device, instead of suspending the entire guest, while waiting for the page to come back.

arch/s390/mm/extmem.c has another very interesting concept, though the hcall interfaces used there are not as flexible as they should be in kvm. It's basically about mapping host files into the guest real address space, e.g. for shared memory between guests.

Quoted 5 lines

arch/s390/mm/extmem.c has another very interesting concept, though the hcall interfaces used there are not as flexible as they should be in kvm. It's basically about mapping host files into the guest real address space, e.g. for shared memory between guests.

This, too, is interesting, though it means guest apps need to be written to take advantage of it.

Quoted 1 line

Quoted 1 line

arch/s390/mm/extmem.c has another very interesting concept, though

Quoted 1 line

Quoted 1 line

hcall interfaces used there are not as flexible as they should be

Quoted 1 line

Quoted 1 line

kvm. It's basically about mapping host files into the guest real

address

Quoted 4 lines

Quoted 2 lines

space, e.g. for shared memory between guests.

This, too, is interesting, though it means guest apps need to be

Quoted 1 line

to take advantage of it.

The primary user of this interface is the ext2 file system with the

mount option that can easily share read-only file systems across guests without actually copying files into the page cache of each guest.

Another potential (future) user are cluster file systems like ocfs2 and gfs2, but to be really efficient, these also need a specialized

lock manager that communicates through hcalls instead of TCP/IP

Simply mapping the shared memory as a character device is similar

that applications written for posix shared memory can easily be

but I'm not aware of anyone doing that currently.

	Arnd <><