From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: The two image formats called qcow Date: Wed, 26 Mar 2008 09:50:06 +0100 Message-ID: <47EA0E3E.4030200@suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com, Otavio Salvador List-Id: xen-devel@lists.xenproject.org Keir Fraser schrieb: > It's tricky where users' non-volatile storage is concerned though. Other > than that I would say the bug should be fixed immediately. Is there an easy > way to detect with reasonable reliability whether we have an old or new > image? Failing that we may have to provide a tool to convert old images to > new format. Something like "that number looks too big, it be must little endian" could easily turn into "that harddisk looks big, let's break the image", I suspect. However, I just noticed that the tapdisk qcow driver writes an extended Xen-specific header to the image file. This should be reliable enough to detect tapdisk images. Is it an option to convert broken images to big endian when it is opened for the first time in ioemu? In this case, the fix for older versions could be in one place at least instead of being scattered over the whole file. Then you wouldn't be able to open such a file with tapdisk again, though. Kevin