From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Yury Kotov <yury-kotov@yandex-team.ru>,
qemu-devel@lists.ewheeler.net, jiangshanlai@gmail.com,
peter.maydell@linaro.org, Laurent Vivier <lvivier@redhat.com>,
Thomas Huth <thuth@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
Peter Crosthwaite <crosthwaite.peter@gmail.com>,
Juan Quintela <quintela@redhat.com>,
qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
wrfsh@yandex-team.ru, Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v2 0/5] Add ignore-external migration capability
Date: Mon, 11 Feb 2019 16:13:25 +0000 [thread overview]
Message-ID: <20190211161325.GG27585@redhat.com> (raw)
In-Reply-To: <20190211160357.GK2627@work-vm>
On Mon, Feb 11, 2019 at 04:03:57PM +0000, Dr. David Alan Gilbert wrote:
> * Yury Kotov (yury-kotov@yandex-team.ru) wrote:
> > Hi,
> >
> > The series adds a migration capability, which allows to skip shared RAM blocks
> > during the migration. It's useful for fast local migration. E.g. to update QEMU
> > for the running guests.
> >
> > Usage example:
> > 1. Start source VM:
> > qemu-system-x86 \
> > -m 4G \
> > -object memory-backend-file,id=mem0,size=4G,share=on,mem-path=/dev/shm/mem0 \
> > -numa node,memdev=mem0 \
> > -qmp unix:/tmp/qemu-qmp-1.sock,server,nowait \
> >
> > 2. Start target VM:
> > qemu-system-x86 \
> > -m 4G \
> > -object memory-backend-file,id=mem0,size=4G,share=on,mem-path=/dev/shm/mem0 \
> > -numa node,memdev=mem0 \
> > -qmp unix:/tmp/qemu-qmp-2.sock,server,nowait \
> > -incoming defer
> >
> > 3. Enable ignore-external capability on both VMs:
> > { "execute": "migrate-set-capabilities" , "arguments":
> > { "capabilities": [ { "capability": "x-ignore-external", "state": true } ] } }
> >
> > 4. Start migration.
> >
> > Another use case I keep in mind is to migrate to file. Usage is very similar.
>
> Hi,
> I've cc'd in Eric, Lai and Peter, all who were asking for something
> similar last year; can you all confirm this patch does what you need or
> can work with what you needed to do?
x-ignore-external is a global setting so affects all memory-backend-file
instances. The obvious question is where there is any reasonable/conceivable
scenario in which QEMU would have multiple "-object memory-backend-file"
intsances and it be neccessary/desirable to migrate some, but skip migrate
of others ?
Could there ever be a device backend which is using a memory region
to communicate with an external process, where you would need to have
a new instance for the migration target QEMU, and explicitly not reuse
the source QEMU's memory-backend-file storage ?
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
prev parent reply other threads:[~2019-02-11 16:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-04 13:09 [Qemu-devel] [PATCH v2 0/5] Add ignore-external migration capability Yury Kotov
2019-02-04 13:09 ` [Qemu-devel] [PATCH v2 1/4] exec: Change RAMBlockIterFunc definition Yury Kotov
2019-02-11 11:40 ` Dr. David Alan Gilbert
2019-02-04 13:09 ` [Qemu-devel] [PATCH v2 2/4] migration: Introduce ignore-shared capability Yury Kotov
2019-02-11 12:45 ` Dr. David Alan Gilbert
2019-02-11 13:36 ` Yury Kotov
2019-02-11 15:55 ` Dr. David Alan Gilbert
2019-02-04 13:09 ` [Qemu-devel] [PATCH v2 3/4] tests/migration-test: Add a test for " Yury Kotov
2019-02-11 13:17 ` Dr. David Alan Gilbert
2019-02-12 12:49 ` Yury Kotov
2019-02-04 13:09 ` [Qemu-devel] [PATCH v2 4/4] migration: Add capabilities validation Yury Kotov
2019-02-11 13:30 ` Dr. David Alan Gilbert
2019-02-12 13:58 ` Yury Kotov
2019-02-11 11:24 ` [Qemu-devel] [PATCH v2 0/5] Add ignore-external migration capability Yury Kotov
2019-02-11 16:03 ` Dr. David Alan Gilbert
2019-02-11 16:13 ` Daniel P. Berrangé [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190211161325.GG27585@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=crosthwaite.peter@gmail.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=jiangshanlai@gmail.com \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@lists.ewheeler.net \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
--cc=wrfsh@yandex-team.ru \
--cc=yury-kotov@yandex-team.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.