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

[Tan, Jianfeng]

On 2/8/2018 5:51 PM, Igor Mammedov wrote:
> 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.

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 :-)