From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SorAL-0007Xu-Hc for qemu-devel@nongnu.org; Wed, 11 Jul 2012 03:16:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SorAJ-0000se-49 for qemu-devel@nongnu.org; Wed, 11 Jul 2012 03:16:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SorAI-0000sL-S5 for qemu-devel@nongnu.org; Wed, 11 Jul 2012 03:16:51 -0400 From: Markus Armbruster References: Date: Wed, 11 Jul 2012 09:16:47 +0200 In-Reply-To: (Blue Swirl's message of "Tue, 10 Jul 2012 19:42:22 +0000") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] Disk geometry and migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Kevin Wolf , Paolo Bonzini , qemu-devel@nongnu.org, Juan Quintela Blue Swirl writes: > On Tue, Jul 10, 2012 at 6:34 PM, Markus Armbruster wrote: >> Scenario: >> >> 1. Start a guest with a blank disk (need not be the only disk) and >> default disk geometry. >> >> 2. Examine the disk's physical geometry >> >> Details depend on the device model. scsi-hd exposes it in mode pages >> 4 and 5. ide-hd in command IDENTIFY, and in its translation from CHS >> to LBA. virtio-blk in its device configuration (optional, feature >> bit VIRTIO_BLK_F_GEOMETRY). >> >> 3. Partition the disk with a DOS partition table >> >> 4. Examine the disk's physical geometry >> >> 5. Migrate >> >> 6. Examine the disk's physical geometry >> >> Bug: if the end of the first valid entry in partition table created in >> step 2 has a CHS address with H < 15, the physical geometry in step 6 is >> different than the one in steps 2 and 4. How come? >> >> QEMU picks default physical geometry based on image size and DOS >> partition table. >> >> In step 1, there is no partition table, and QEMU picks 16 heads, 63 >> sectors per track. >> >> In step 5, there is a partition table, and the destination QEMU picks a >> geometry that matches it. Which may differ from the previous one. >> >> Possible solutions: >> >> A. Migrate physical geometry >> >> Possible once my recent geometry series is merged. Devil's in the >> compatibility details. We need to send a geometry subsection when >> the current MBR will make the destination QEMU pick a different >> geometry. Thus, guest updating a DOS partition table may prevent >> migration to an older QEMU. >> >> The geometry change still happens on the next non-migration QEMU >> restart. Implies cold boot, so hardware changes are tolerable. >> Document as feature. If you want to keep physical geometry stable, >> don't rely on default geometry, specify one. >> >> B. Make physical geometry invisible to the guest >> >> SCSI: the geometry mode pages are obsolete since SBC-3 (2005). Guest >> software choking on their absence seems unlikely, but not impossible. >> >> virtio-blk: geometry information is optional. But since we've always >> provided it, it's conceivable that some guest software depends on its >> presence. >> >> IDE: I'm afraid we can't do. CHS addressing is obsolete in ATA-7 >> (2008). ATA-4 (1998) requires it for disks up to 16,514,064 sectors. >> Plenty of old software uses it. >> >> To be precise, old software may talk CHS to the disk. It can also >> talk CHS to the BIOS (int 13h), but that's a separate, logical >> geometry. The BIOS makes it up from physical geometry (which it >> finds in CMOS) with a translation method (also from CMOS). Since it >> makes it up during initialization, it doesn't change even when >> migration screws up physical geometry. Since SeaBIOS translates >> logical geometry to LBA, *not* CHS, it even keeps working. >> >> C. Do not derive default geometry from DOS partition table >> >> Can do only for new machine type, because it may break guests. >> >> D. Document as feature >> >> If you want to keep physical geometry stable under migration, specify >> the correct geometry on the destination. > > E. Detect the inconsistency and warn user > > Mismatch between physical and DOS geometry can be detected. Before > migration, output a warning message for the users. Perhaps QEMU should > do this on startup as well. Define "mismatch". Differences between physical and logical geometry are normal (otherwise we wouldnt' have logical geometry). So, what kind of difference should trigger warnings? Note that a warning message is prone to be buried in logs, where nobody sees it until something goes wrong badly enough to make someone examine the logs. Double-checking: you suggest to migrate regardless of the warning, don't you? >> Preferences? Comments? >> > > EACDB