[PATCH] NVRAM: check NVRAM file size and recover from template

Michal Privoznik mprivozn at redhat.com
Tue Sep 1 09:44:45 UTC 2020

On 9/1/20 10:46 AM, Daniel P. Berrangé wrote:
> On Sat, Aug 08, 2020 at 06:01:22PM +0800, Hao Wang wrote:
>> From: Hao Wang <wanghao232 at huawei.com>
>> Subject: [PATCH] NVRAM: check NVRAM file size and recover from template
>> A corrupted nvram file (e.g. caused by last unsuccessful creation due to
>> insufficient memory) can lead to boot or migration failure.
> Or it can be caused by incorrect deployment of new NVRAM file by an
> administrator or OS Distro...
> Just last week we were debugging an issue on Ubuntu where a person
> had deployed incorrect NVRAM files of a different size.
>> Check the size of the existed nvram file when qemuPrepareNVRAM, and re-create
>> if the existed one is unhealthy.
> ....this will delete valid NVRAM files, hiding the mistake by the
> administrator.
> Overall I'm not a fan of performing a destructive action like deleting
> files which may or may not be correct.

Not to mention that the size is only one of indicators. The NVRAM has an 
internal structure and if it gets corrupted (e.g. guest crashes while 
writing the file), we have now way of detecting it (and I know this is 
not the scenario you are trying to fix).

BTW: This all could have been avoided if you'd use firmware 
autoselection: <os firmware='efi'/>. Is there a problem with it that 
made you go with the old way of specifying NVRAM?


More information about the libvir-list mailing list