[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration
From: |
Igor Mammedov |
Subject: |
Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration |
Date: |
Thu, 8 Feb 2018 12:30:18 +0100 |
On Thu, 8 Feb 2018 18:18:20 +0800
"Tan, Jianfeng" <address@hidden> wrote:
> 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 ...
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.
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, (continued)
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Igor Mammedov, 2018/02/05
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Paolo Bonzini, 2018/02/05
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Tan, Jianfeng, 2018/02/07
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Igor Mammedov, 2018/02/07
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Tan, Jianfeng, 2018/02/07
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Igor Mammedov, 2018/02/08
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Tan, Jianfeng, 2018/02/08
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration,
Igor Mammedov <=
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Tan, Jianfeng, 2018/02/23
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Tan, Jianfeng, 2018/02/23
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Igor Mammedov, 2018/02/26
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Paolo Bonzini, 2018/02/26
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Tan, Jianfeng, 2018/02/26
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Tan, Jianfeng, 2018/02/26
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Igor Mammedov, 2018/02/28
- Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Dr. David Alan Gilbert, 2018/02/05
Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, no-reply, 2018/02/05
Re: [Qemu-devel] [RFC] exec: eliminate ram naming issue as migration, Igor Mammedov, 2018/02/05