[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Live migration, different instance RAM allocations?

From: Jakob Bohm
Subject: Re: [Qemu-discuss] Live migration, different instance RAM allocations?
Date: Fri, 03 Jan 2014 16:44:55 +0100
User-agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 1/3/2014 4:33 PM, Scott Sullivan wrote:

Is it possible to perform a live migration where SOURCE and DESTINATION have different RAM sizes (using QEMU/KVM)? I know you can live migrate from hostA to hostB without downtime, when the instances RAM allocation is the same on both ends. Is there anyway to perform the live migration, but with the RAM size on the DESTINATION to be larger than it was on the SOURCE?

To clarify, so what I'm wondering is if you can live migrate instance 'blah' from physical hostA with 1GB of RAM allocated, to physical hostB with 2GB of RAM allocated?

The closest thing I have thought of is doing a normal live migration, then ballooning the instance up to the new RAM allocation on the DESTINATION. However you can't balloon up past the instances maxMemory it appears when the instance is live:

virsh setmaxmem blah --live5242880k
error: Unable to change MaxMemorySize
error: Requested operation is not valid: cannot resize the maximum memory on an active domain

So it doesn't appear ballooning would work for my use case here. It's fine if its not possible, I was just wondering if anyone knew of a way to do this, or has experiences doing something similar, as it seems like a somewhat common desire.
The issue is much more fundamental:

At bootup, the OS inside the Guest VM asks the BIOS (SEABIOS) how much
(simulated) physical ram the virtual machine has.

The optional balloon driver can then tell the guest OS that it is using
X MB of that memory and temporarily hand that back to the host via qemu,
the guest OS will still think the memory is there, it just happens to be
used by the "balloon" process.

But to tell the guest OS about additional memory beyond what it was told
about at boot, the guest OS needs to support "hot-plugging" extra RAM
into a computer without reboot, and qemu needs to simulate the hardware
that tells the guest OS this has been done.

So the real things to check are:

- does the OS in your virtual machine support hot-plugging additional
- does qemu simulate a form of memory hot-plugging supported by that
 guest OS?
- what is the qemu command to actually simulate such a hot-plugging


Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

reply via email to

[Prev in Thread] Current Thread [Next in Thread]