From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juan Quintela Subject: Re: 1.1.1 -> 1.1.2 migrate /managedsave issue Date: Tue, 06 Nov 2012 16:05:20 +0100 Message-ID: <87y5iesrf3.fsf@trasno.org> References: <201210220904.31653.hahn@univention.de> <50852CCF.3070000@redhat.com> <87390pc9zo.fsf@codemonkey.ws> Reply-To: quintela@redhat.com Mime-Version: 1.0 Content-Type: text/plain Cc: Anthony Liguori , Avi Kivity , Philipp Hahn , KVM mailing list , qemu-devel To: Doug Goldstein Return-path: Received: from mx1.redhat.com ([209.132.183.28]:35380 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751168Ab2KFPFg (ORCPT ); Tue, 6 Nov 2012 10:05:36 -0500 In-Reply-To: (Doug Goldstein's message of "Sun, 4 Nov 2012 23:41:20 -0600") Sender: kvm-owner@vger.kernel.org List-ID: Doug Goldstein wrote: > On Sun, Nov 4, 2012 at 3:51 PM, Anthony Liguori wrote: >>> >>> Seems reasonable. Doug, please verify to see if it's the same issue or >>> another one. >>> >>> Juan, how can we fix this? It's clear that the option ROM size has to >>> be fixed and not change whenever the blob is updated. This will fix it >>> for future releases. But what to do about the ones in the field? >> >> This is not a problem upstream because we don't alter the ROMs. If we >> did, we would keep the old ROMs around and set the romfile property in >> the compatible machine. >> >> This is what distros that are shipping ROMs outside of QEMU ought to >> do. It's a bug to unconditionally change the ROMs (in a guest visible >> way) without adding compatibility support. >> >> Regards, >> >> Anthony Liguori >> > > Anthony, > > Gerd updated seabios on August 7th and before that on April 17. The > default VGA ROM size also changed in recent releases. There are no old > versions of the ROMs included once these updates are performed so a > user building a new version from source will hit this problem. Juan > Quintela even mentioned that he has been bit by this issue and had to > use gdb to track it down as did Philipp that responded earlier in the > thread. The patch is a simple fprintf() which would have saved at > least 3 users the effort of tracking down an issue with gdb. So I urge > you to reconsider. I hit this problem. But it was a bug, the problem was to detect it. The problem was doing migration to an old version, we now "round" the RAM amount to a multiple of 8k. If your old ram memory was mulitple of 4k, you get this prolbem with migration. And it only prints "migration failed". Printing a message telling that: memory size of %foo is %d and expected %d would have make error trivial to found. Later, Juan. PD. Problem was really a bit more complex than this, this is a simplification.