From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYgoQ-0002xq-AA for qemu-devel@nongnu.org; Wed, 24 Feb 2016 16:17:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYgoP-0000DH-55 for qemu-devel@nongnu.org; Wed, 24 Feb 2016 16:17:34 -0500 Date: Wed, 24 Feb 2016 16:17:24 -0500 From: Jeff Cody Message-ID: <20160224211724.GA26318@localhost.localdomain> References: <951bf8f8c49ff3c2a38dcd02fe78ae00a5de8add.1456274059.git.jcody@redhat.com> <20160224101937.GC4485@noname.redhat.com> <20160224122443.GC23671@localhost.localdomain> <20160224130718.GE4485@noname.redhat.com> <20160224134056.GD23671@localhost.localdomain> <56CE0454.5050202@kamp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56CE0454.5050202@kamp.de> Subject: Re: [Qemu-devel] [PATCH 3/4] block/vpc: give option to force the current_size field in .bdrv_create List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: Kevin Wolf , qemu-devel@nongnu.org, qemu-block@nongnu.org On Wed, Feb 24, 2016 at 08:28:20PM +0100, Peter Lieven wrote: > Am 24.02.2016 um 14:40 schrieb Jeff Cody: > > On Wed, Feb 24, 2016 at 02:07:18PM +0100, Kevin Wolf wrote: > >> Am 24.02.2016 um 13:44 hat Peter Lieven geschrieben: > >>> if the size is forced I would set the chs values to max. this way no > >>> new creator String is needed and it is even backwards compatible. this > >>> is what disk2vhd does. > >> Does disk2vhd do it this way even if the size is smaller than the > >> maximum that can be represented with CHS? > >> > > I don't know about disk2vhd, but I just created a 5G dynamic VHD > > image on Hyper-V, and it produced: > > > > cyl: 10402, heads: 16, secs: 63 > > virtual size: 5.0G (5368709120 bytes) > > > > (the virtual size as calculated by CHS in that case would have been > > 5368430592 bytes) > > > > I then tested the reverse - I modified qemu to create a VHD image with > > 5G as the current_size, but maxed out CHS parameters. I imported it > > into Hyper-V, and it worked fine - just recognized as a 5G disk with > > 5368709120 bytes. > > So the idea to set CHS to MAX is not that bad. > I agree. I just did a test with disk2vhd, against an empty (but formatted) 7.5G usb drive. Here is what it created: # ./qemu-img info /mnt/nfs-2/tmp/WINtsts2.VHD cyls: 65535, heads: 16, sectors: 255 image: /mnt/nfs-2/tmp/WINtsts2.VHD file format: vpc virtual size: 7.5G (8095006720 bytes) I really like how one company has 3 different tools that all handle this differently. > > > > But with all that, it seems like it may be better to mimic the Hyper-V > > behavior, and use a new creator app string, with the normal CHS > > values. > > But this means that it is not backwards compatible. Maxing out CHS > when forcing the size would mean all old qemu version would look > at current size and not CHS. > That is a valid concern. So, how about this: With 'force_size' during image create, set the CHS parameters to MAX (as d2v does), but also set the creator app to 'qem2'. This at least gives other software a chance to learn that new creator app and handle it differently, if needed (and it shouldn't hurt anything, and will still be backwards compatible). > Might it be that Hyper-V and others use CHS when an ATA disk is emulated > and the cur_size otherwise? I think this is what virtualbox does. I tested the Hyper-V created image under a Linux VM in Hyper-V. The VM is using IDE controllers, and the image size was the current_size, not the CHS calculation. Jeff