From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34583) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ejjHi-0005aF-UW for qemu-devel@nongnu.org; Thu, 08 Feb 2018 05:18:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ejjHf-0005u4-O3 for qemu-devel@nongnu.org; Thu, 08 Feb 2018 05:18:30 -0500 Received: from mga18.intel.com ([134.134.136.126]:52316) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ejjHf-0005sN-DA for qemu-devel@nongnu.org; Thu, 08 Feb 2018 05:18:27 -0500 References: <1517842735-9011-1-git-send-email-jianfeng.tan@intel.com> <1b6a1999-95bb-5eac-70e1-39e6ba5b22fc@redhat.com> <6716e932-9ce5-3d97-41cb-f33ea94ad4ce@intel.com> <502bbdba-0c35-e35a-6600-dfca739d0ea3@redhat.com> <20180205181521.47232aa4@redhat.com> <5155622d-cc49-d24c-7a7d-24ebb9ca2331@redhat.com> <20180207130635.4033f8b8@redhat.com> <8474af94-7bff-a7b5-e316-b8a0e332467e@intel.com> <20180208105111.7a776513@redhat.com> From: "Tan, Jianfeng" Message-ID: <53186984-2111-ed5e-0d47-65db12f22ea3@intel.com> Date: Thu, 8 Feb 2018 18:18:20 +0800 MIME-Version: 1.0 In-Reply-To: <20180208105111.7a776513@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Paolo Bonzini , "qemu-devel@nongnu.org" , Jason Wang , Maxime Coquelin , "Michael S . Tsirkin" On 2/8/2018 5:51 PM, Igor Mammedov wrote: > On Thu, 8 Feb 2018 09:20:45 +0800 > "Tan, Jianfeng" wrote: > >> On 2/7/2018 8:06 PM, Igor Mammedov wrote: >>> On Wed, 7 Feb 2018 07:49:58 +0000 >>> "Tan, Jianfeng" wrote: >>> >>>>> -----Original Message----- >>>>> From: Paolo Bonzini [mailto:pbonzini@redhat.com] >>>>> Sent: Tuesday, February 6, 2018 1:32 AM >>>>> To: Igor Mammedov >>>>> Cc: Tan, Jianfeng; qemu-devel@nongnu.org; Jason Wang; Maxime Coquelin; >>>>> Michael S . Tsirkin >>>>> Subject: Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as >>>>> migration >>>>> >>>>> On 05/02/2018 18:15, Igor Mammedov wrote: >>>>>>>> Then we would have both ram block named pc.ram: >>>>>>>> Block Name PSize >>>>>>>> pc.ram 4 KiB >>>>>>>> /objects/pc.ram 2 MiB >>>>>>>> >>>>>>>> But I assume it's a corner case which not really happen. >>>>>>> Yeah, you're right. :/ I hadn't thought of hotplug. It can happen indeed. >>>>>> perhaps we should fail object_add memory-backend-foo if it resulted >>>>>> in creating ramblock with duplicate id >>>>> Note that it would only be duplicated with Jianfeng's patch. So I'm >>>>> worried that his patch is worse than what we have now, because it may >>>>> create conflicts with system RAMBlock names are not necessarily >>>>> predictable. Right now, -object creates RAMBlock names that are nicely >>>>> constrained within /object/. >>>> So we are trading off between the benefit it takes and the bad effect it brings. >>>> >>>> I'm wondering if the above example is the only failed case this patch leads to, i.e, only there is a ram named "pc.ram" and "/object/pc.ram" in the src VM? >>>> >>>> Please also consider the second option, that adding an alias name for RAMBlock; I'm not a big fan for that one, as it just pushes the problem to OpenStack/Libvirt. >>> looking at provided CLI examples it's configuration issue on src and dst, >>> one shall not mix numa and non numa variants. >> Aha, that's another thing we also want to change. We now add numa at dst >> node, only because without -numa, we cannot set up the file-baked memory >> with share=on. > then shouldn't you start src with the same -numa to begin with, > changing such things on the fly is not supported. Yes, you are describing the best practice. But we are originally trying to migrate without any changes to QEMU. > General rule is that machine on dst has to be the same as on src. OK. > (with backend not visible to guest it possible might be changed > but it's hard to tell if something would break due to that > or would continue working in future since doesn't go along with above rule) > >> For example, "-m xG -mem-path xxx" can set up a file-baked memory, but >> the file is not share-able. > It could be solved by adding memdev option to machine, > which would allow to specify backend object. And then on > top make -mem-path alias new option to clean thing up. Do you mean? src vm: -m xG dst vm: -m xG,memdev=pc.ram -object memory-backend-file,id=pc.ram,size=xG,mem-path=xxx,share=on ... > > But then again, You'd need to start both src and dst > with the same option. Yeah, got it :-)