Hi Dr. David On Thu, 11 Apr 2019 at 00:57, Dr. David Alan Gilbert <dgilb...@redhat.com> wrote:
> * Catherine Ho (catherine.h...@gmail.com) wrote: > > Hi Dr. David > > > > On Wed, 10 Apr 2019 at 22:59, Dr. David Alan Gilbert < > dgilb...@redhat.com> > > wrote: > > > > > * Catherine Ho (catherine.h...@gmail.com) wrote: > > > > Hi Igor > > > > > > > > > > > > On Mon, 8 Apr 2019 at 18:35, Igor Mammedov <imamm...@redhat.com> > wrote: > > > > > > > > > On Sun, 7 Apr 2019 22:19:05 -0400 > > > > > Catherine Ho <catherine.h...@gmail.com> wrote: > > > > > > > > > > > Currently it is not forbidden to use "-object > > > > > memory-backend-file,share=on" > > > > > > and together with "-incoming". But after incoming migration is > > > finished, > > > > > > the memory-backend-file will be definitely written if share=on. > So > > > the > > > > > > memory-backend-file can only be used once, but failed in the 2nd > time > > > > > > incoming. > > > > > > > > > > > > Thus it gives a warning and the users can run the qemu if they > really > > > > > > want to do it. > > > > > > > > > > Shouldn't we add a migration blocker in such a case instead of > warning > > > > > and letting qemu run wild? > > > > > > > > > > > > > IMO, it doesn't need to block this. With share=on and -incoming, the > user > > > > can > > > > still save the device memory state into memory-backend file again if > > > > ignore-shared > > > > capability is on. > > > > > > > > If we block this, the user can't use the ignore-shared capability in > > > > incoming > > > > migration. > > > > > > -incomign with share=on is a perfectly normal thing to do - it just > > > depends who you are sharing the file with and the lifetime of that > > > shared file. > > > > > > For example; if you're just running a qemu with vhost-user then you > > > use share=on - however wyou typically select the backend file as > > > a new file from /dev/shm - it's not a file that you previously migrated > > > to. > > > > > Thanks, > > but using a new file from /dev/shm means kernel will start from > > start_kernel or early? Is it different from the x-ignore-shared case? > > If we remove the share=on in incoming migration, all the writting > > of ram will not be flush into the memory backend file. Thus we > > can use the base memory backend file for ever. > > e.g. > > 1) save the vm like a snapshot, current ram state is "kernel > > has been started, systemd has been started" > > 2) restore it with -incoming and *no* share=on flag > > 3) restore it with -incoming and *no* share=on again... > > In contrary, if we use share=on, the base backend file will > > be written at once after 1st time incoming. > > > > So, IMO, no "share=on" is the proper usage of incoming migration > > when ignore-shared is on. > > Please correct me if sth is wrong, thanks:) > > OK, I see what you're trying to do - you mean for the 'snapshotting' > case; but that's not the only use. Another use is for being able to > do a very quick upgrade of the running qemu to a new qemu binary > version; and in that case you want to be able to write to the shared > file so that you can repeatedly do the quick migrate. > > Dave > > Ah, that quick upgrade example makes sense to me. Thanks for the explanation. B.R. Catherine
