On Thu, 8 Feb 2018 18:18:20 +0800 "Tan, Jianfeng" <jianfeng....@intel.com> wrote:
> On 2/8/2018 5:51 PM, Igor Mammedov wrote: > > On Thu, 8 Feb 2018 09:20:45 +0800 > > "Tan, Jianfeng" <jianfeng....@intel.com> wrote: > > > >> On 2/7/2018 8:06 PM, Igor Mammedov wrote: > >>> On Wed, 7 Feb 2018 07:49:58 +0000 > >>> "Tan, Jianfeng" <jianfeng....@intel.com> wrote: > >>> > >>>>> -----Original Message----- > >>>>> From: Paolo Bonzini [mailto:pbonz...@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 ... Yep, I've meant something like it src vm: -m xG,memdev=SHARED_RAM -object memory-backend-file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on dst vm: -m xG,memdev=SHARED_RAM -object memory-backend-file,id=SHARED_RAM,size=xG,mem-path=xxx,share=on or it could be -machine FOO,inital_ram_memdev=... maybe making -M optional in this case as size is specified by backend PS: it's not a good idea to use QEMU's internal id 'pc.ram' for user specified objects as it might cause problems.