Initialization of device cfi.pflash01 failed: Block node is read-only
Hi,
I have several vms defined in libvirt using ovmf for uefi, since a later
update of my server I'm unable to start any of the domains defined. This is
an example of the output given:
# virsh start os-1
error: Failed to start domain os-1
error: internal error: qemu unexpectedly closed the monitor: 2019-03-02T21:23:51.726446Z qemu-system-x86_64: Initialization of device cfi.pflash01 failed: Block node is read-only
an example of domain is like this:
os-134c41008-ab91-483b-959c-81a7a12ae9be838860883886084hvm/var/lib/libvirt/qemu/nvram/os-1-ovmf.fddestroyrestartdestroy/usr/bin/qemu-system-x86_64
where /var/lib/libvirt/qemu/nvram/os-1-ovmf.fd is a copy of
/usr/share/edk2-ovmf/OVMF_VARS.fd. An the extract from my
/etc/libvirt/qemu.conf to define ovmf:
...
# Location of master nvram file
#
# When a domain is configured to use UEFI instead of standard
# BIOS it may use a separate storage for UEFI variables. If
# that's the case libvirt creates the variable store per domain
# using this master file as image. Each UEFI firmware can,
# however, have different variables store. Therefore the nvram is
# a list of strings when a single item is in form of:
# ${PATH_TO_UEFI_FW}:${PATH_TO_UEFI_VARS}.
# Later, when libvirt creates per domain variable store, this list is
# searched for the master image. The UEFI firmware can be called
# differently for different guest architectures. For instance, it's OVMF
# for x86_64 and i686, but it's AAVMF for aarch64. The libvirt default
# follows this scheme.
nvram = [
"/usr/share/edk2-ovmf/OVMF_CODE.fd:/usr/share/edk2-ovmf/OVMF_VARS.fd",
]
...
This setup used to work one month ago, now it's setup with:
QEMU emulator version 3.1.0
libvirt-5.0.0
linux-4.19.20
Any help appreciated.
Best regards.
José
Extract from the libvirt log of todays launch of vms.
The uncommented piece of my /etc/libvirt/qemu.conf.
vnc_listen = "192.168.0.61"
user = "root"
group = "root"
dynamic_ownership = 0
nvram = [
"/usr/share/edk2-ovmf/OVMF_CODE.fd:/usr/share/edk2-ovmf/OVMF_VARS.fd",
]
For some reason, emails directly from mailing list are not hitting my inbox
so I managed to miss this:
https:///msg600959.html
Please ensure it's sent to my email when answering.
Thanks!
José.
seems to be piece of true on Phil's comments, as extracting the command on the log and executing it manually the result is the following:
2019-04-18T19:37:49.685841Z qemu-system-x86_64: -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-6-os-1/master-key.aes: Unable to read /var/lib/libvirt/qemu/domain-6-os-1/master-key.aes: Failed to open file “/var/lib/libvirt/qemu/domain-6-os-1/master-key.aes”: No such file or directory
unless those folders with master keys are dinamically genreated and trashed after execution it would be worthy to involve here libvirt project as well.
José.
Hi José,
your domain XML is bogus with regard to the firmware configuration. You
have:
/var/lib/libvirt/qemu/nvram/os-1-ovmf.fd
and no element, and you write that "os-1-ovmf.fd" is a copy of
"OVMF_VARS.fd".
The element, with @type='pflash', no other attributes, and then
no sibling element either, happens to be valid, but it is an
extremely niche use case. It is used when you have a unified, writeable,
OVMF.fd file that contains both the firmware executable and the live
variable store.
Most distros don't provide such unified "OVMF.fd" files, and even if
yours does, you are not passing a full such "OVMF.fd" to the guest, but
just a variable store -- there is no firmware binary at all that the
guest could *execute*.
So please do the following:
- power down the domain
- delete "/var/lib/libvirt/qemu/nvram/os-1-ovmf.fd" for starters
- modify the domain XML as follows, with "virsh edit":
/usr/share/edk2-ovmf/OVMF_CODE.fd
When you exit your editor, libvirtd will:
- create the element, and auto-generate the pathname for the
element
- create the varstore file, pointed-to by the pathname above, from the
template at "/usr/share/edk2-ovmf/OVMF_VARS.fd".
(more precisely, the nvram element will be auto-generated when you exit "virsh edit", and the nvram file will be created (copied) from the varstore template when you launch the domain)
thanks for the thorough pointers Laszlo, I did and run in different kind
of issues, and given that I was just having the vars around I really wonder
how it ever worked, perhaps I copied the unified and I forgot, as gentoo
thas provide it:
# du -h /usr/share/edk2-ovmf/*
1.9M /usr/share/edk2-ovmf/OVMF_CODE.fd
2.0M /usr/share/edk2-ovmf/OVMF.fd
128K /usr/share/edk2-ovmf/OVMF_VARS.fd
Thanks!
José
oh well, it turns out to be actually related, it turns out
virt-aa-helper is skipping the code file of ovmf:
2019-04-19 10:06:43.576+0000: 9272: error : AppArmorGenSecurityLabel:469 : internal error: cannot load AppArmor profile 'libvirt-34c41008-ab91-483b-959c-81a7a12ae9be'
2019-04-19 10:09:25.751+0000: 9270: error : virCommandWait:2636 : internal error: Child process (LIBVIRT_LOG_OUTPUTS=3:stderr /usr/libexec/virt-aa-helper -c -u libvirt-34c41008-ab91-483b-959c-81a7a12ae9be) unexpected exit status 1: 2019-04-19 10:09:25.750+0000: 13797: info : libvirt version: 5.2.0
2019-04-19 10:09:25.750+0000: 13797: info : hostname: mole
2019-04-19 10:09:25.750+0000: 13797: error : virStorageFileBackendFileRead:129 : Failed to open file '/dev/mole-vg0/os-1-vda': Permission denied
2019-04-19 10:09:25.750+0000: 13797: error : virStorageFileBackendFileRead:129 : Failed to open file '/dev/mole-vg0/os-1-vdb': Permission denied
virt-aa-helper: error: /usr/share/edk2-ovmf/OVMF_CODE.fd
virt-aa-helper: error: skipped restricted file
virt-aa-helper: error: invalid VM definition
The domain now looks like:
[40/100]
os-134c41008-ab91-483b-959c-81a7a12ae9be838860883886084hvm/usr/share/edk2-ovmf/OVMF_CODE.fd/var/lib/libvirt/qemu/nvram/os-1_VARS.fddestroyrestartdestroy/usr/bin/qemu-system-x86_64
this is apparmor profile related in the end, rebooting with apparmor disabled allows
the domain to boot, so I'll deal with the gentoo community, and this can be closed.
Thanks!
José.