From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: Migration and Node parameter Date: Mon, 6 Oct 2008 21:40:53 +0200 Message-ID: <48EA69C5.5000705@amd.com> References: <48EA0BEC.6070308@konink.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <48EA0BEC.6070308@konink.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefan de Konink Cc: xen-devel List-Id: xen-devel@lists.xenproject.org Stefan de Konink wrote: > def domain_migrate(self, domid, dst, live=False, port=0, node=-1, > ssl=None): > """Start domain migration. > ... > @keyword node: use node number for target > @type node: int > ... > What does the node parameter do in this context? This means the NUMA node the new guest should be created on. Newer Xen versions create guests on a single node and choose the least used one. If later the system load changes, it can become imbalanced in respect to equal load on all nodes. In this situation you can manually move a guest to another NUMA node. (NUMA literature often uses the term "NUMA domain" instead of node, but for obvious reason I try to avoid this term in Xen) Using localhost migration for this purpose isn't the smartest solution, but was fairly easy to implement ... and works. See unstable c/s 17148 for the code. Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 277-84917 ----to satisfy European Law for business letters: AMD Saxony Limited Liability Company & Co. KG, Wilschdorfer Landstr. 101, 01109 Dresden, Germany Register Court Dresden: HRA 4896, General Partner authorized to represent: AMD Saxony LLC (Wilmington, Delaware, US) General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy