Fixed upstream; 7.1 will get it via rebase:

commit 9b291bbe20c36c0820c6e7cd2bf6229bf41807e8
Author: Eric Blake <eblake>
Date:   Wed Jun 25 14:54:36 2014 -0600

    docs: publish correct enum values
    
    We publish libvirt-api.xml for others to use, and in fact, the
    libvirt-python bindings use it to generate python constants that
    correspond to our enum values.  However, we had an off-by-one bug
    that any enum that relied on C's rules for implicit initialization
    of the first enum member to 0 got listed in the xml as having a
    value of 1 (and all later members of the enum were equally
    botched).
    
    The fix is simple - since we add one to the previous value when
    encountering an enum without an initializer, the previous value
    must start at -1 so that the first enum member is assigned 0.
    
    The python generator code has had the off-by-one ever since DV
    first wrote it years ago, but most of our public enums were immune
    because they had an explicit = 0 initializer.  The only affected
    enums are:
    - virDomainEventGraphicsAddressType (such as
    VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4), since commit 987e31e
    (libvirt v0.8.0)
    - virDomainCoreDumpFormat (such as VIR_DOMAIN_CORE_DUMP_FORMAT_RAW),
    since commit 9fbaff0 (libvirt v1.2.3)
    - virIPAddrType (such as VIR_IP_ADDR_TYPE_IPV4), since commit
    03e0e79 (not yet released)
    
    Thanks to Nehal J Wani for reporting the problem on IRC, and
    for helping me zero in on the culprit function.
    
    * docs/apibuild.py (CParser.parseEnumBlock): Fix implicit enum
    values.
    
    Signed-off-by: Eric Blake <eblake>

Verify it as follows. The result is expected. Move its status to VERIFIED.


# rpm -q libvirt libvirt-python
libvirt-1.2.8-8.el7.x86_64
libvirt-python-1.2.8-5.el7.x86_64

# grep -n VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4 /usr/lib64/python2.7/site-packages/libvirt.py
5674:VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4 = 0

# python -c "import libvirt; print libvirt.VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4"
0

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/RHSA-2015-0323.html