From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjTo9-0006i2-Bc for qemu-devel@nongnu.org; Wed, 20 Jul 2011 06:15:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjTo6-0002hv-70 for qemu-devel@nongnu.org; Wed, 20 Jul 2011 06:15:12 -0400 Received: from arsenic.logifi.fr ([217.108.178.219]:56998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjTo5-0002eU-Dt for qemu-devel@nongnu.org; Wed, 20 Jul 2011 06:15:10 -0400 Date: Wed, 20 Jul 2011 12:15:02 +0200 From: Nicolas Sebrecht Message-ID: <20110720101502.GC2560@nicolas-desktop> References: <4E258635.2040108@redhat.com> <4E258D70.6000205@redhat.com> <4E25902D.2000403@redhat.com> <4E2593B0.1030508@redhat.com> <4E2594FB.4050203@redhat.com> <20110719164613.GE12026@redhat.com> <4E269070.8050101@redhat.com> <20110720093609.GA5015@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110720093609.GA5015@redhat.com> Subject: [Qemu-devel] [libvirt] Re: live snapshot wiki updated List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: "libvir-list@redhat.com" , Jes Sorensen , Nicolas Sebrecht , QEMU Developers , Stefan Hajnoczi The 20/07/11, Daniel P. Berrange wrote: > To make the decision whether the filename from QEMU is valid, we have > to parse the master image header data to see if the filename actually > matches the backing file required by the image assigned to the guest. Actually, libvirt should not have to worry if the filename provided by QEMU is valid. I think it should trust QEMU. If QEMU doesn't provide information others can trust; it should be fixed at QEMU side. > We're not fighting over the internals of metadata. We just need to know > ahead of launching QEMU, what backing files an image has & what format > they are in. We do that by reading at the metadata headers of the disk > images. We never attempt to write to the disk images. Either someone > provides a library todo that, or we write the probing code for each > file format in libvirt. Currently we have the latter. This is what I would call "fighting with QEMU internals". How do you prevent from concurrency access and modifications? Ideally speacking libvirt should be able to co-exist with foreign implementations, all requesting QEMU. -- Nicolas Sebrecht