From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=212.186.127.180; helo=proxmox-new.maurer-it.com; envelope-from=t.lamprecht@proxmox.com; receiver=edk2-devel@lists.01.org Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1B1062245119E for ; Thu, 1 Mar 2018 03:15:21 -0800 (PST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 1D8E7420B6; Thu, 1 Mar 2018 12:21:28 +0100 (CET) From: Thomas Lamprecht To: qemu-discuss@nongnu.org Cc: edk2-devel-01 Message-ID: <96f46413-6eb6-21f4-d07c-89aebea6f233@proxmox.com> Date: Thu, 1 Mar 2018 12:21:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 Subject: How to handle pflash backed OVMF FW upgrade and live migration best? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 11:15:22 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi, I'm currently evaluating how to update the firmware (OVMF) code image without impacting a KVM/QEMU VM on live migration. I.e., the FW code lives under /usr/share/OVMF/OVMF_CODE.fd and gets passed to the QEMU command with: qemu-binary [...] -drive "if=pflash,unit=0,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd" Now if the target node has an updated version of OVMF the VM does not really likes that, as from its POV it gets effectively another code image loaded from one moment at the other without any notice. So my questions is if it would make sense to see this read-only pflash content as "VM state" and send it over during live migration? This would make migration way easier. Else we need to save all FW files and track which one the VM is using, so that when starting the migration target VM we pass along the correct pflash drive file. Sending over a pflash drive could maybe only get done when a special flag is set for the pflash drive? As said I can work around in our management stack, but saving the FW image and tracking which VM uses what version, and that cluster wide, may get quite a headache and we would need to keep all older OVMF binaries around... If I'm missing something and there's already an easy way for this I'd be very happy to hear from it. Besides qemu-discuss I posted it to edk2-devel as there maybe more people are in the QEMU and OVMF user intersection. :) cheers, Thomas