From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=53556 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OszBq-0004Pf-Or
	for qemu-devel@nongnu.org; Tue, 07 Sep 2010 10:30:27 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <chrisw@redhat.com>) id 1OszBp-0002g0-0F
	for qemu-devel@nongnu.org; Tue, 07 Sep 2010 10:30:26 -0400
Received: from mx1.redhat.com ([209.132.183.28]:8551)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <chrisw@redhat.com>) id 1OszBo-0002fo-Q6
	for qemu-devel@nongnu.org; Tue, 07 Sep 2010 10:30:24 -0400
Date: Tue, 7 Sep 2010 07:30:21 -0700
From: Chris Wright <chrisw@redhat.com>
Message-ID: <20100907143021.GA26141@x200.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Qemu-devel] KVM call minutes for Sept 7
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: kvm@vger.kernel.org
Cc: qemu-devel@nongnu.org

0.13 schedule
- RSN
- rc1 uploaded, tagged in git (and tag should actually be there now)
- announcement once it propagates
- 0.13.0 should be 1 week after rc1 announcement
- please check rc1 for any missing critical patches

qed
- concession that qcow2 is complicated and hard to get right
- it's much more efficient than qcow2
- not had data integrity testing, but simple enough design to
  rationalize the format and meta-data updates
- formal spec planned...documented on wiki http://wiki.qemu.org/Features/QED
  - design doc written first, code written to design doc
- defragmentation supportable and important (not done now)
- defragmented image should be as fast as raw
- concern about splitting install base (doubles qa effort, etc)
  - should be possible to do an in-place qcow2->qed update
  - even live update could be doable
- what about vmdk or vhd?
  - controlled externally
  - specification license implications are unclear
  - too close to NIH?
- qed and async model could put pressure to improve other formats and
  push code out of qed to core
- another interest for qed...streaming images (fault in image extents
  via network)
  - want to design this as starting from mgmt interface discussion