In order to support kvm's live migration with non-shared storage I added
two
migration flags that user can invoke:
VIR_MIGRATE_NON_SHARED_DISK = (1 << 6), /* migration with non-shared
storage with full disk copy */
VIR_MIGRATE_NON_SHARED_INC = (1 << 7), /* migration with non-shared
storage with incremental copy */
/* (same base image shared
between source and destination) */
Likewise I add complementary flags to virsh migrate: non_shared_disk and
non_shared_inc
As Daniel B. suggested I also added internal flags to be passed in the
"background" parameter to the qemu monitor:
typedef enum {
QEMU_MONITOR_MIGRATE_BACKGROUND = 1 << 0,
QEMU_MONITOR_MIGRATE_NON_SHARED_DISK = 1 << 1, /* migration with
non-shared storage with full disk copy */
QEMU_MONITOR_MIGRATE_NON_SHARED_INC = 1 << 2, /* migration with
non-shared storage with incremental copy */
QEMU_MONITOR_MIGRATION_FLAGS_LAST
};
I updated qemu_driver.c's doNativeMigrate and doTunnelMigrate to map the
external flags to the internal flags.
I updated qemu_monitor_text's qemuMonitorTextMigrate to map the internal
flags to the qemu monitor's command line flags.
I tested the doNativeMigrate usage of the two flags. However, I could not
test the doTunnelMigrate usage because I wasn't sure how it works. Also,
qemudDomainSave ends up calling qemuMonitorTextMigrate, but it didn't
support the external flags so I assumed that it was not relevant.
Here is the diff patch file from the current git:
(See attached file: libvirt_migration_ns.patch)
-- Kenneth Nagin
>Daniel Veillard <veillard@xxxxxxxxxx> wrote on 04/03/2010 11:50:44:
> Daniel Veillard <veillard@xxxxxxxxxx>
> 04/03/2010 11:50
>
> Please respond to
> veillard@xxxxxxxxxx
>
> To
>
> Kenneth Nagin/Haifa/IBM@IBMIL
>
> cc
>
> "Daniel P. Berrange" <berrange@xxxxxxxxxx>, libvir-list@xxxxxxxxxx
>
> Subject
>
> Re: [libvirt] Live Migration with non-shared storage for kvm
>
> On Thu, Mar 04, 2010 at 10:04:30AM +0200, Kenneth Nagin wrote:
> >
> > >Daniel Veillard <veillard@xxxxxxxxxx> wrote on 03/03/2010 10:18:08:
> >
> > > Daniel Veillard <veillard@xxxxxxxxxx>
> > > 03/03/2010 10:18
> > >
> > > Please respond to
> > > veillard@xxxxxxxxxx
> > >
> > > To
> > >
> > > Kenneth Nagin/Haifa/IBM@IBMIL
> > >
> > > cc
> > >
> > > "Daniel P. Berrange" <berrange@xxxxxxxxxx>, libvir-list@xxxxxxxxxx
> > >
> > > Subject
> > >
> > > Re: [libvirt] Live Migration with non-shared storage for kvm
> > >
> > > On Wed, Mar 03, 2010 at 08:52:07AM +0200, Kenneth Nagin wrote:
> > > >
> > > > On February 16th I posted a patch and description for libvirt
support
> > of
> > > > 'Live Migration with non-shared strorage for kvm.'
> > > > What is the status of the proposed enhancement?
> > >
> > > I'm afraid that Dan and me got too busy last week and didn't review
it,
> > > The patch looks mostly sane, I'm just a bit suspicious about the
> > > handling of option string in the QEmu command line building code.
> > >
> > > I suggest you rebase the patch to 0.7.7 when it's out and send it
> > > again, so we can review and push it next week,
> > >
> > > thanks !
> > >
> > > Daniel
> > Ok.
> > I have a few questions:
> > 1) What is the best way to know that the release is out? Do I just
poll
> > the http://libvirt.org/news.html?
>
> I make the announce on the mailing-list when I release. I also try to
> post statuses on a weekly or so basis
>
> https://www.redhat.com/archives/libvir-list/2010-February/msg00130.html
> https://www.redhat.com/archives/libvir-list/2010-February/msg00784.html
> https://www.redhat.com/archives/libvir-list/2010-March/msg00126.html
>
> > 2) I found working with "tip" of the difficult since it was constantly
> > changing. From your note I understand that I should work with the last
> > stable release. Assuming that I am correct is this the recommended
method
> > to get a particular release:
> > git clone git://libvirt.org/libvirt.git
> > cd libvirt
> > git reset --hard <release tag name>
>
> make a branch, work on that branch, that won't change, just "git
rebase"
> from time to time. Never try to develop pathes directly on master.
>
> > 3) Is this the recommended method to generate a patch from the above
> > release:
> > git diff master > patch
>
> git diff > patch in your branch if you didn't commited (simple patch)
> otherwise commit on your branch, then the commits can be pulled in
various
> ways.
>
> Daniel
>
> --
> Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
> daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
> http://veillard.com/ | virtualization library http://libvirt.org/Attachment:
libvirt_migration_ns.patch
Description: Binary data
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list