On 08/27/2018 04:29 PM, John Ferlan wrote: > > > On 08/27/2018 09:29 AM, Michal Prívozník wrote: >> On 08/27/2018 12:57 PM, Yi Wang wrote: >>> When doing some job holding state lock for a long time, >>> we may come across error: >>> "Timed out during operation: cannot acquire state change lock" >>> Well, sometimes it's not a problem and users wanner continue > > s/wanner/want to/ > > or "prefer to"... Perhaps users is too vague - this essentially sets > the "default timeout policy" for everyone. Setting it too short could be > dangerous considering it's impact. > > If "a user" wanted or preferred to wait longer than the default job > timeout for a specific command, then we'd need to add some option for > various commands/API's that allowed setting a unique timeout value for a > specific job. > > Another thought would be to have an API that allowed changing the > timeout programmatically. Of course there's the admin interface that is > another area to consider altering since you're adjusting a configuration > value like this. If anything, this is a job for virt-admin. I don't think we need an API that would live next to virDomainDeviceUpdate() for instance. We don't have one for max_jobs, nor for lock_manager, ... In fact, I don't think we have any API to change anything from qemu.conf. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
