Description of problem: A code cleanup to virsh ended up causing any command with an optional --domain parameter (virsh event, virsh qemu-monitor-event) to reject a domain argument with an error and proceed as if no domain filtering had been supplied. Version-Release number of selected component (if applicable): libvirt-1.2.14-1.fc22.x86_64 How reproducible: 100% Steps to Reproduce: 1. virsh list --all 2. virsh event $dom1 (for some $dom in the list from step 1) 3. virsh start $dom2 Actual results: error: internal error: virsh event: no domainVSH_OT_DATA option then a startup event is listed for $dom2 Expected results: events should be filtered to only $dom1 Additional info: fixed by commit 31ef0836a73ed8583ff93613d2759e28965103ef Author: Eric Blake <eblake> Date: Tue Apr 14 16:15:06 2015 -0600 virsh: fix regression in 'virsh event' by domain Commit a0670ae caused a regression in 'virsh event' and 'virsh qemu-monitor-event' - if a user tries to filter the command to a specific domain, an error message is printed: $ virsh event dom --loop error: internal error: virsh qemu-monitor-event: no domain VSH_OT_DATA option and then the command continues as though no domain had been supplied (giving events for ALL domains, instead of the requested one). This is because the code was incorrectly assuming that all "domain" options would be supplied via a mandatory VSH_OT_DATA, even though "domain" is optional for these two commands, so we had changed them to VSH_OT_STRING to quit failing for other reasons (ever since it was decided that VSH_OT_DATA and VSH_OT_STRING should no longer be synonyms). In looking at the situation, though, the code for looking up a domain was making a pointless check for whether the option exists prior to finding the option's string value, as vshCommandOptStringReq does just fine at reporting any errors when looking up a string whether or not the option was present. So this is a case of regression fixing by pure code deletion :) * tools/virsh-domain.c (vshCommandOptDomainBy): Drop useless filter. * tools/virsh-interface.c (vshCommandOptInterfaceBy): Likewise. * tools/virsh-network.c (vshCommandOptNetworkBy): Likewise. * tools/virsh-nwfilter.c (vshCommandOptNWFilterBy): Likewise. * tools/virsh-secret.c (vshCommandOptSecret): Likewise. * tools/virsh.h (vshCmdHasOption): Drop unused function. * tools/virsh.c (vshCmdHasOption): Likewise. Signed-off-by: Eric Blake <eblake>
backported to v1.2.14-maint branch; next fedora 22 build will be fixed
also v1.2.13-maint branch (1.2.14 was in fedora-virt-preview)
libvirt-1.2.13.1-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libvirt-1.2.13.1-1.fc22
Package libvirt-1.2.13.1-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libvirt-1.2.13.1-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-7122/libvirt-1.2.13.1-1.fc22 then log in and leave karma (feedback).
libvirt-1.2.13.1-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.