Hi, Thank you very much for the answer. so if romfile on destination got a larger size than source, why romfile check still does not pass? because dest got enough space to hold romfile.
thank you. Jiatong Shen On Tue, Feb 23, 2021 at 5:46 PM Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: > * Philippe Mathieu-Daudé (phi...@redhat.com) wrote: > > Cc'ing qemu-devel@ > > > > On 2/23/21 1:45 AM, Jiatong Shen wrote: > > > Hello, > > > > > > we are faced with an issue where a changed sized romfile > > > (efi-virtio.rom) fails live migration. Do qemu load this rom from its > > > current host only? If yes, why cannot sync this from source vm? > > Hi, > For migration to work the ROM has to be the same size on the source > and destination. > > The problem is that whne the destination starts up it allocates the > size of the ROM based on the size of the file; but then the migration > comes along and tries to copy the data from the source machine into that > allocation; and isn't sure what should happen when it doesn't quite fit. > > There is some variation allowed (I think the allocated size gets > rounded up, maybe to the next power of 2); but you still hit problems > wehn the ROM size crosses certain thresholds. > > In the latest qemu, a 'romsize' property was added (see git commit > 08b1df8ff463e72b0875538fb991d5393047606c ); that lets you specifiy a > size that's big enough to hold some space for future expansion - e.g. > lets say your ROM is currently 300k, you might specify romsize=512k > and then it doesn't matter what size the actual file is, we'll always > allocate 512k, and as long as the file is less than 512k migration will > work. > > The more manual way to do that, is to arrange for your files to be > padded to a larger boundary so that you leave room for growth. > Some distros have done that for a while. > > Dave > > > > thank you. > > > > > > -- > > > > > > Best Regards, > > > > > > Jiatong Shen > > > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > -- Best Regards, Jiatong Shen
