[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCHv4 00/51] another round of snapshot patches

On 09/02/2011 03:57 AM, Daniel Veillard wrote:
On Thu, Sep 01, 2011 at 10:24:37PM -0600, Eric Blake wrote:
I think I've addressed most findings from round 3 - by implementing
the ability to redefine a snapshot, it becomes possible to restore
snapshot hierarchy when recreating a transient domain by the same
name.  New goodies in this round: several bug fixes, add virsh
snapshot-edit, drop undefine --snapshots-full (you can only remove
snapshot metadata on undefine).  I tested as I went, but this went
through so many rebases that there may be some nasties that snuck
in; but I wanted to get this posted now.  I also know that I'm
missing at least one major feature requested in the v3 review:
namely, transient domains _should_ auto-remove snapshot metadata
files when they halt, but right now aren't doing that.

v3 was at:

Also available here:

git fetch git://repo.or.cz/libvirt/ericb.git snapshot

   thanks, very convenient !
though I had to use
  git fetch git://repo.or.cz/libvirt/ericb.git +snapshot:snapshot
to actually get a snapshot branch locally...

  1 ACK

I'll commit things in phases, broken out by BZs that each phase fixes.

I have now pushed patch 1 (BZ 674537).

  2 ACK
  3,4,5,6: New flags in API ACK, it would be good to have regression tests
           tracking all the events sent in the various cases...

These tests will have to be in the TCK, unless we were to also teach src/tests/test_driver.c the same events. Improving tests:///default to cover events is certainly doable in the future, but not in time for 0.9.5.

  27 I'm not so sure about that, as the caching is infinite. Some module
     rely on inotify already, and best would be to add an utility for
     inotify use and then use it on the dirs of $PATH, then upon change
     discard the cacher path
     I would push for now but add a TODO to fix that problem

If we expected the location of qemu-img along a PATH search to change, then I see your point. But I see nothing wrong with caching that qemu-img lives in /usr/bin (or wherever else it was found) - that is unlikely to change, even if you upgrade the package that provided qemu-img in the meantime.

Using inotify cache expulsion is more useful for things like caching 'qemu -help' output - it's one thing to cache where qemu lives, it's another to also cache what that version of qemu supports, and the cache must be invalidated if the file at the cached location changes due to a package upgrade. But in this case, we aren't caching qemu-img capabilities.

  28 ACK
  29 Isn't there a way to save the domain snapshot on shared storage when
     available to try to avoid the problem ? It wouldn't work all the
     time but might be simpler than rolling out a v4. or consider the
     snapshot data as extra domain resource that could be migrated on
     the fly like we can do for disk images in some cases.

Certainly lots of room for improvement along this front, but probably most of it will be post-0.9.5. Right now, we're just getting the basics in place.

  30 ACK
  31 ACK
  32 argh ... ACK
  33 the new rng need to be added to libvirt.spec.in file list,
     once done ACK

Good catch. I also had to rebase on top of Osier's change to domain.rng (git wasn't very nice, claiming a conflict of several thousand lines even though it was really just a single addition).

Elapsed time: 3h 20mn

Not bad, considering it took me several weeks to reach 51 pending patches.

now the 100hours question is how are we gonna test all this in a
reasonable fashion and outside of your environment :-)
I think we should push, but need a testing plan because I don't think
we can reasonably expect people to test this in time for 0.9.5,

I'll have everything pushed in the next 8 hours or so, in batches tied to BZ as I mentioned above. I'll have limited connectivity next week (I'll be traveling), so hopefully I've tested well enough that I'm not leaving people in a lurch by pushing a large series then disappearing for a few days.

Eric Blake   eblake redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]