[libvirt] Live Migration with non-shared storage for kvm

[Daniel Veillard]

On Thu, Mar 04, 2010 at 10:04:30AM +0200, Kenneth Nagin wrote:
> 
> >Daniel Veillard <veillard at redhat.com> wrote on 03/03/2010 10:18:08:
> 
> > Daniel Veillard <veillard at redhat.com>
> > 03/03/2010 10:18
> >
> > Please respond to
> > veillard at redhat.com
> >
> > To
> >
> > Kenneth Nagin/Haifa/IBM at IBMIL
> >
> > cc
> >
> > "Daniel P. Berrange" <berrange at redhat.com>, libvir-list at redhat.com
> >
> > 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 at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/