Server side filtering exists as of upstream v1.2.2 with commits such as:

commit 158795d20ea0ae928feb8a3691e6d8340cb8a92a
Author: Eric Blake <eblake>
Date:   Thu Jan 9 11:22:53 2014 -0700

    event: convert remaining domain events to new style
    
    Following the patterns established by lifecycle events, this
    creates all the new RPC calls needed to pass callback IDs
    for every domain event, and changes the limits in client and
    server codes to use modern style when possible.
    
    I've tested all combinations: both 'old client and new server'
    and 'new client and old server' continue to work with the old
    RPCs, and 'new client and new server' benefit from server-side
    filtering with the new RPCs.
    
    * src/remote/remote_protocol.x (REMOTE_PROC_DOMAIN_EVENT_*): Add
    REMOTE_PROC_DOMAIN_EVENT_CALLBACK_* counterparts.
    * daemon/remote.c (remoteRelayDomainEvent*): Send callbackID via
    newer RPC when used with new-style registration.
    (remoteDispatchConnectDomainEventCallbackRegisterAny): Extend to
    cover all domain events.
    * src/remote/remote_driver.c (remoteDomainBuildEvent*): Add new
    Callback and Helper functions.
    (remoteEvents): Match order of RPC numbers, register new handlers.
    (remoteConnectDomainEventRegisterAny)
    (remoteConnectDomainEventDeregisterAny): Extend to cover all
    domain events.
    * src/remote_protocol-structs: Regenerate.
    
    Signed-off-by: Eric Blake <eblake>

Hi Eric
I'm verify this bug right now, Unluckly, i couldn't reproduce it following the comment0's steps, so can you show me some more details steps or a reproducer for this bug reproduce？ so that i could verify this bug sufficiently, Thanks in advance.

Hi Eric
The following steps were my reproduce and verify steps, can you help check whether they're ok to verify this bug thanks

Reproduce steps
1.Prepare 2 host, 1 libvirtd server with a old packet and 1 libvirtd client with the latest packet
Server:
libvirt-1.1.1-29.el7.x86_64
client:
libvirt-client-1.2.17-9.el7.x86_64

2.Prepare 3 guests in the libvirtd server
# virsh list --all
 Id    Name                           State
----------------------------------------------------
 7     vm1                            running
 10    vm2                            running
 -     win7                           shut off


3.Connect the libvirtd server from the libvirtd client,Register to receive events for a single domain in a client, with debugging turned on to track async messages from the server

client#LIBVIRT_DEBUG=1 virsh -c qemu+ssh://$server_ip/system
virsh# event vm1 --all


4.Connect the libvirtd server with the server's local virsh client, then do some operates on the vm2 or win7
server#virsh -c qemu:///system 
virsh # start win7
Domain win7 started

virsh # destroy vm2
Domain vm2 destroyed

virsh # start vm2
Domain vm2 started


5.Check the debug logs on the step3's libvirtd client, the debug traffic show that libvirtd server also send the other domain's event to this client

2015-09-17 07:42:43.279+0000: 5575: info : virObjectNew:202 : OBJECT_NEW: obj=0x7fed04000a20 classname=virDomainEventLifecycle
--
2015-09-17 07:42:49.437+0000: 5575: info : virObjectNew:202 : OBJECT_NEW: obj=0x7fed04000a00 classname=virDomainEventLifecycle
--
2015-09-17 07:43:12.350+0000: 5575: info : virObjectNew:202 : OBJECT_NEW: obj=0x7fed04000a20 classname=virDomainEventLifecycle


Verify steps
1.Both server and client use the latest libvirt packet
 Server:
libvirt-1.2.17-9.el7.x86_64
client:
libvirt-client-1.2.17-9.el7.x86_64

2.Re-excute step 2~4
3.check the debug logs on the libvirtd client, the events for other domain won't show in this client 

4.do some operations with vm1, could get the corresponding event for vm1

server#virsh -c qemu:///system 
virsh#destroy vm1


2015-09-17 07:55:27.174+0000: 5700: info : virObjectNew:202 : OBJECT_NEW: obj=0x7fb1b0000a90 classname=virDomainEventLifecycle

Hi Eric
Please ignore the comment6 and check comment7 directly, thanks

Yes, comment 7 confirms that the old server did not do server-side filtering, while the new server does; it also confirms that the new client is interoperable with either version of server.  You've come up with a good test.

Thanks for Eric's response, so mark this bug verified

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html