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

[Igor Mammedov <imammedo@redhat.com>]

On Mon, 5 Feb 2018 18:36:31 +0000
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:

> * Tan, Jianfeng (jianfeng.tan@intel.com) wrote:
> > 
> > 
> > On 2/6/2018 12:29 AM, Igor Mammedov wrote:  
> > > On Mon,  5 Feb 2018 14:58:55 +0000
> > > Jianfeng Tan <jianfeng.tan@intel.com> wrote:
> > >   
> > > > Existing VMs with virtio devices and vhost-kernel as the backend
> > > > are always started with mem config:
> > > > 
> > > >    "-m xG"
> > > >    (with a ram block named "pc.ram")
> > > > 
> > > > while new VMs with virtio devices and vhost-user as the backend
> > > > are always started with mem config:
> > > > 
> > > >    "-m xG -numa node,memdev=pc.ram -object memory-backend-file,id=pc.ram,..."
> > > >    (with a ram block named "/object/pc.ram")  
> > > could you elaborate more on what src command line migrating to what dst command line?  
> > 
> > The src cmdline:
> >     $QEMU -enable-kvm -cpu host -smp 4 /path/to/img \
> >       -m 2G \
> >       -netdev tap,id=mynet1,vhost=on \
> >       -device virtio-net-pci,netdev=mynet1,mac=52:54:00:12:34:58 ...
> > 
> > The dst cmdline:
> >     $QEMU -enable-kvm -cpu host -smp 4 /path/to/img \
> >       -m 2G -numa node,memdev=pc.ram -mem-prealloc \
> >       -object
> > memory-backend-file,id=pc.ram,size=2G,mem-path=/dev/hugepages,share=on \
> >       -chardev socket,id=char0,path=/tmp/sock0 \
> >       -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \
> >       -device virtio-net-pci,netdev=mynet1,mac=52:54:00:12:34:58 \
> >       -incoming tcp:0:4444 ...  
> 
> I'm surprised that it's safe to -numa node  the destination, even with
> the hack to the RAMBlock naming.  I'd expect it to have other effects
> as well.
it supposed to be 2 mutually exclusive configurations,
but migration stream doesn't have that information explicitly
(different id naming/mapping could fail migration).


> Dave
> 
> > Thanks,
> > Jianfeng
> >   
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK