Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration

[Igor Mammedov]

On Thu, 8 Feb 2018 09:20:45 +0800
"Tan, Jianfeng" <address@hidden> wrote:

> On 2/7/2018 8:06 PM, Igor Mammedov wrote:
> > On Wed, 7 Feb 2018 07:49:58 +0000
> > "Tan, Jianfeng" <address@hidden> wrote:
> >  
> >>> -----Original Message-----
> >>> From: Paolo Bonzini [mailto:address@hidden
> >>> Sent: Tuesday, February 6, 2018 1:32 AM
> >>> To: Igor Mammedov
> >>> Cc: Tan, Jianfeng; address@hidden; 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.
General rule is that machine on dst has to be the same as on src.
(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.

But then again, You'd need to start both src and dst
with the same option.
 
> >  
> >> Or any other suggestions?  
> > Fix configuration, namely dst side of it (i.e. use the same -m only variant
> > without -numa as it's on src).
> >
> > BTW, what are you trying to achieve adding -numa on dst?  
> 
> See above reply.
> 
> Thanks,
> Jianfeng