[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:
Hello,
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
memory?
- 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
event?
Enjoy
Jakob
--
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