External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-22 21:55:25 +00:00
Code Issues Packages Projects Releases Wiki Activity
a0a8c95d07
libvirt/tests/qemuxmlconfdata/firmware-manual-efi-loader-path-nonstandard.x86_64-latest.args

37 lines
1.6 KiB
Plaintext
Raw Normal View History

qemu: Generate NVRAM path in more cases Right now, we only generate it after finding a matching entry either among firmware descriptors or in the legacy firmware list. Even if the domain is configured to use a custom firmware build that we know nothing about, however, we should still automatically generate the NVRAM path instead of requiring the user to provide it manually. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-05-26 12:40:02 +00:00
LC_ALL=C \
PATH=/bin \
HOME=/var/lib/libvirt/qemu/domain--1-guest \
USER=test \
LOGNAME=test \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain--1-guest/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain--1-guest/.cache \
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-guest/.config \
/usr/bin/qemu-system-x86_64 \
-name guest=guest,debug-threads=on \
-S \
-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain--1-guest/master-key.aes"}' \
-blockdev '{"driver":"file","filename":"/path/to/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \
qemuBlockStorageSourceNeedsFormatLayer: Stop formatting 'raw' driver when not needed The 'raw' driver without any special configuration is not needed and creates overhead in qemu. Stop using the 'raw' format driver in cases when it's not needed. A special case when it is needed is for FD passed images with only a single writable FD passed, where we need an overlay driver to properly reflect the 'read-only' flag. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2023-10-19 20:07:49 +00:00
-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/guest_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \
-machine pc-q35-4.0,usb=off,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,acpi=on \
qemu: Generate NVRAM path in more cases Right now, we only generate it after finding a matching entry either among firmware descriptors or in the legacy firmware list. Even if the domain is configured to use a custom firmware build that we know nothing about, however, we should still automatically generate the NVRAM path instead of requiring the user to provide it manually. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-05-26 12:40:02 +00:00
-accel tcg \
-cpu qemu64 \
-m size=1048576k \
-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":1073741824}' \
-overcommit mem-lock=off \
-smp 1,sockets=1,cores=1,threads=1 \
-uuid 63840878-0deb-4095-97e6-fc444d9bc9fa \
-display none \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc \
-no-shutdown \
-boot strict=on \
-audiodev '{"id":"audio1","driver":"none"}' \
-global ICH9-LPC.noreboot=off \
-watchdog-action reset \
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
Reference in New Issue Copy Permalink