Re: virsh undefine --nvram
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@lists.libvirt.org To unsubscribe send an email to users-le...@lists.libvirt.org
Re: virsh undefine --nvram
On Wed, Mar 06, 2024 at 02:28:34AM -0800, Andrea Bolognani wrote: > 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? Libguestfs uses transient VMs, so there's no Undefine operation that will ever be invoked. We have a feature gap here in that we don't provide a mechanism for apps to say they want clean up of NVRAM and TPM state for transient VMs. We can't automatically clean up after transient VMs, as some will be intended to be restarted later. We already have VIR_DOMAIN_CREATE_AUTO_DESTORY which libguests uses to guarantee the VM is killed if libguest is killed. Again though, we can't assume that AUTO_DESTORY implies cleanup. Perhaps we need a VIR_DOMAIN_CREATE_AUTO_CLEANUP flag for virDomainCreateXML ? With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ Users mailing list -- users@lists.libvirt.org To unsubscribe send an email to users-le...@lists.libvirt.org
Re: virsh undefine --nvram
On Wed, Mar 06, 2024 at 02:28:34AM -0800, Andrea Bolognani wrote: > 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? libguestfs only uses transient guests, it never has to call virDomainUndefine at all, so I guess this is really a problem with libvirt ... https://github.com/libguestfs/libguestfs/blob/729d6d55ea84494f0398d02450bd29c39c55f0bd/lib/launch-libvirt.c#L625 Rich. > -- > Andrea Bolognani / Red Hat / Virtualization -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit ___ Users mailing list -- users@lists.libvirt.org To unsubscribe send an email to users-le...@lists.libvirt.org
Error Cannot acquire state change lock from remoteDispatchDomainMigratePrepare3Params during live migration of domains
Hallo libvirt-users! we observe lock-ups / timeouts with in prometheus-libvirt-exporter (https://github.com/inovex/prometheus-libvirt-exporter) when libvirt is live-migrating domains: Timed out during operation: cannot acquire state change lock (held by monitor=remoteDispatchDomainMigratePrepare3Params) All of the source code can be found at: https://github.com/inovex/prometheus-libvirt-exporter/blob/master/pkg/exporter/prometheus-libvirt-exporter.go. Basically the error happens when DomainMemoryStats or other operational domain info is queried via the libvirt socket. 1) We are actually using the read-only socket at '/var/run/libvirt/libvirt-sock-ro', so there should not be any locking required. Is there any way to not run into lock contention, like running a request with some "nolock" indication? 2) This being reported as timeout waiting for the lock, what is the timeout and would waiting a bit longer help? Or is the lock active during the whole time a domain live migration is running? 3) Is this in any way related to the type of migration? Tunneled vs. native (https://libvirt.org/migration.html)? 4) Is there any indication that we could use to skip those domains (or certain queries)? The same issue was actually previously reported for another implementation of a Prometheus exporter (https://github.com/kumina/libvirt_exporter/issues/33). Currently the exporter locks up or throws the mentioned timeout errors during the the migration of 200 domains, 5 at a time. It would be awesome to find a way to make this work as smooth as possible, even during live migrations! I am thankful for any insights into how the libvirt socket, the various calls, the locking mechanisms or live migration modes work! Regards Christian ___ Users mailing list -- users@lists.libvirt.org To unsubscribe send an email to users-le...@lists.libvirt.org
