On Tue, Mar 05, 2024 at 04:08:20PM -0500, Chuck Lever wrote: > Hello - > > The virsh(1) man page says: > > > --nvram and --keep-nvram specify accordingly to delete or keep nvram (/domain/os/nvram/) file. > > However on my Fedora 39 system with libvirt 9.7.0, using "virsh > undefine --nvram" option appears to leave the NVRAM backing file: > > cel@boudin:~$ ls ~/.config/libvirt/qemu/nvram > guestfs-02a4oblo9vg7888d_VARS.qcow2 guestfs-7hmiolqcqwz5b0qs_VARS.qcow2 > guestfs-el7lqymnwgzpnr38_VARS.qcow2 guestfs-jp0tfneh205xjrh8_VARS.qcow2 > guestfs-mhqbp4gwmqsuu9w3_VARS.qcow2 guestfs-sat7x2kgpg9opjds_VARS.qcow2 > guestfs-vhhi476rsq7vh83z_VARS.qcow2 guestfs-177mrq9xrb5589wl_VARS.qcow2 > guestfs-88p8heyq1j0sy8bk_VARS.qcow2 guestfs-gxul3j9e1h3po19o_VARS.qcow2 > guestfs-k0jf8msw4kh3yuff_VARS.qcow2 guestfs-oakcwpbozezvids8_VARS.qcow2 > guestfs-sinmkv97r4k4dzcd_VARS.qcow2 guestfs-vj5cu9hgwcv0f18u_VARS.qcow2 > guestfs-6jnim67ceme3h369_VARS.qcow2 guestfs-89g707uzdttxb9hv_VARS.qcow2 > guestfs-h6vzt9zqxhoxx0hj_VARS.qcow2 guestfs-k4hw4gkcq8u0eebj_VARS.qcow2 > guestfs-pljksgeblxgyf0pw_VARS.qcow2 guestfs-t8bnntykpzm3qvh2_VARS.qcow2 > guestfs-ynbxqtj01sn4ovwy_VARS.qcow2 guestfs-6sqhenv6ditrq410_VARS.qcow2 > guestfs-at8lndx32y69bjmg_VARS.qcow2 guestfs-ht0uycdn3vwdozad_VARS.qcow2 > guestfs-lfy19ftph83jo4v0_VARS.qcow2 guestfs-qj0c2u9w2k4ors6h_VARS.qcow2 > guestfs-tmq0h36spng4vtwk_VARS.qcow2 guestfs-7erqks7ks5c8rj38_VARS.qcow2 > guestfs-ba2kzqxb1pna12l5_VARS.qcow2 guestfs-is7avsxjtnig5kgb_VARS.qcow2 > guestfs-m3nrhs3x58rlget9_VARS.qcow2 guestfs-rilsled4ff9wvk6v_VARS.qcow2 > guestfs-veebmlno2okc7c8h_VARS.qcow2 > cel@boudin:~$ > > Or perhaps I do not understand what these files are. Based on the names, I believe those have been created by libguestfs. Rich, is it possible that libguestfs doesn't use VIR_DOMAIN_UNDEFINE_NVRAM when cleaning up after itself? -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ Users mailing list -- users@xxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxx