Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux-HA: Dev

Xen resource live migration and memory management

 

 

Linux-HA dev RSS feed   Index | Next | Previous | View Threaded


sebastia at l00-bugdead-prods

Mar 5, 2009, 6:30 AM

Post #1 of 4 (1588 views)
Permalink
Xen resource live migration and memory management

Hi,

right now, as far as I can see, the Xen live migration doesn't work together
with Xen.

The problem described in short words:
- with xen memory management enabled, the available memory on all hosts is
distributed equally on all running domU's on a physical node.

- with live migration, there must be enough resources available on the node
where the domU will migrate to.

- as there is all memory used, due to the memory management, the live
migration will fail.

- a resource script on one node, e.g. the Xen script, is not really able to
manipulate sth. on other hosts in the cluster

To solve the problem I thought about the following:

1. create a XenMigrationHelperResource, that can do the following:
- figure out the amount of running domU's
- figure out the amount of maximum available memory per host
- post both values into the CIB, using attrd_updater
- resize memory on the domU's running on the same host as where the
XenMigrationHelperResource runs on

2. using this resource, in e.g. a two node cluster:
- create a group, ordered but not collocated
- first add the XenMigrationHelperResource
- then the corresponding Xen resource

add a colocation constraint with -INFINITY, to keep the Xen resource always on
a different host than the XenMigrationHelperResource

3. migrate the Xen resource, due to the order, the XenMigrationHelperResource
starts its work:
- count running xen domains, and figure out maximum available memory, and
updated the CIB with attrd_updater
- shrink the memory on the running domU's equally, to make memory available
for the new domU to be migrated to that host
- then it migrates away on the other host

- then the Xen resource starts migration, it will read the values for the
target node posted via attrd_updater, and it will shrink the memory, so that
it will fit on the other machine.
- then it will start the migration of the domU, which now has good chances to
end successfully
- at the end io migration, the Xen resource will raise the memory on the host
where it migrated from

Is this something that could work out, or maybe I think too complicated, and I
overlooked sth. to solve the problem much more easier?

any input is highly appreciated.

regards
Sebastian
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/


florian.haas at linbit

Mar 6, 2009, 1:09 PM

Post #2 of 4 (1493 views)
Permalink
Re: Xen resource live migration and memory management [In reply to]

Sebastian,

out of curiosity, have you tried live migration with the Xen
VirtualDomain RA instead?

Cheers,
Florian

On 03/05/2009 03:30 PM, Sebastian Reitenbach wrote:
> Hi,
>
> right now, as far as I can see, the Xen live migration doesn't work together
> with Xen.
> [...]
Attachments: signature.asc (0.25 KB)


lmb at suse

Mar 9, 2009, 10:16 AM

Post #3 of 4 (1464 views)
Permalink
Re: Xen resource live migration and memory management [In reply to]

On 2009-03-05T15:30:05, Sebastian Reitenbach <sebastia [at] l00-bugdead-prods> wrote:

> Hi,
>
> right now, as far as I can see, the Xen live migration doesn't work together
> with Xen.

You mean, together with memory management via the RA. That is true.

> 1. create a XenMigrationHelperResource, that can do the following:
> - figure out the amount of running domU's
> - figure out the amount of maximum available memory per host
> - post both values into the CIB, using attrd_updater
> - resize memory on the domU's running on the same host as where the
> XenMigrationHelperResource runs on
>
> 2. using this resource, in e.g. a two node cluster:
> - create a group, ordered but not collocated
> - first add the XenMigrationHelperResource
> - then the corresponding Xen resource

That is a horrible hack. You can do that, but I don't see that being
merged in the resources package, sorry ...

The real issue is that Pacemaker does not take system resources (like
memory, CPU, IO, but for Xen, memory is what matters most) into account
during resource placement decisions.

Integrating this with the policy engine is the right path forward.


> Is this something that could work out, or maybe I think too
> complicated, and I overlooked sth. to solve the problem much more
> easier?

I fear the problem is not trivial, and necessarily complicated. So you
might as well go in the right direction ;-)



Regards,
Lars

--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/


sebastia at l00-bugdead-prods

Mar 11, 2009, 5:34 AM

Post #4 of 4 (1463 views)
Permalink
Re: Xen resource live migration and memory management [In reply to]

Hi,
On Friday 06 March 2009 10:09:31 pm Florian Haas wrote:
> Sebastian,
>
> out of curiosity, have you tried live migration with the Xen
> VirtualDomain RA instead?
Thank you for your answer, but I'm not sure, what you mean. The ordinary Xen
RA? or is there another one? I checked in /usr/lib/ocf/resources.d/heartbeat,
but could not find any other than the Xen.

I tried live migration with that one, and it works well, but not in
combination with automatic memory management.

Sebastian
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Linux-HA dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.