Re: [Qemu-devel] [PATCH 0/2] pflash (UEFI varstore) migration shortcut for libvirt

[Laszlo Ersek]

On 08/27/14 10:58, Daniel P. Berrange wrote:
> On Sat, Aug 23, 2014 at 12:19:05PM +0200, Laszlo Ersek wrote:
>> Libvirt is growing support for x86_64 OVMF guests:
>>
>> http://www.redhat.com/archives/libvir-list/2014-August/msg01045.html
>>
>> An important feature of such guests is the persistent store for
>> non-volatile UEFI variables. This is implemented with if=pflash drives.
>> The referenced libvirt patchset sets up the varstore files for
>> single-host use.
>>
>> Wrt. migration, two choices have been considered:
>> (a) full-blown live storage migration for the drives backing pflash
>>     devices,
>> (b) vs. a shortcut that exploits the special nature of pflash drives
>>     (namely, their minuscule size, and a RAMBlock that keeps the full
>>     contents of each pflash drive visible to the guest, and is
>>     up-to-date, at all times.)
> 
> So, IIUC, with option b), libvirt will merely need to make sure that
> the NVRAM var store file exists with the right size. QEMU will then
> just 'do the right thing' for migration copying across the contents ?
> If so that sounds nice to me.

Yes, that is the case.

Michal's patchset for libvirt pre-creates the empty varstore on the
incoming side, from the template file. That code path is shared with the
case when the VM starts up as a non-incoming one, and just has no
private varstore yet. The varstore created (from the template) is
"empty" in the PI / UEFI sense, but it's not all zeroes; it has some
internal structure.

Instantiating the VM-private varstore from the template is
- required for both size *and* contents reasons for a non-incoming
  startup, and
- required for size reasons *only* for an incoming startup.

http://www.redhat.com/archives/libvir-list/2014-August/msg01048.html

+    /* If the nvram path is configured already, there's nothing
+     * we need to do. Unless we are starting the destination side
+     * of migration in which case nvram is configured in the
+     * domain XML but the file doesn't exist yet. Moreover, after
+     * the migration is completed, qemu will invoke a
+     * synchronization write into the nvram file so we don't have
+     * to take care about transmitting the real data on the other
+     * side. */
+    if (loader->nvram && !migrated)
+        return 0;

Once the pflash_post_load() hook is called in the incoming qemu process,
the VM-private varstore (which libvirt has prepared from the template)
will be completely overwritten by QEMU. But the size of the file is
important information, for starting up the incoming qemu side.

(Any mismatch in size would be caught when the backing RAMBlock's size
is verified during migration.)

Thanks
Laszlo