Fixed upstream with v1.2.6-rc1-12-g39931f5:

commit 39931f5ee8314137dba453bad9742310fc275f5b
Author: Martin Kletzander <mkletzan>
Date:   Thu Jun 26 16:09:46 2014 +0200

    qemu: fix guestfwd chardev option back how it was

I still can reproduce it using fixed version, but it has a different error message.

[root@dell-per415-02 ~]# rpm -q libvirt qemu-kvm-rhev
libvirt-0.10.2-40.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.428.el6.x86_64

[root@dell-per415-02 ~]# virsh dumpxml r7| grep channel -A5
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/foo'/>
      <target type='guestfwd' address='127.0.0.1' port='2445'/>
    </channel>

[root@dell-per415-02 ~]# virsh start r7
error: Failed to start domain r7
error: internal error process exited while connecting to monitor: 2014-07-01T07:44:27.910998Z qemu-kvm: -netdev user,guestfwd=tcp:127.0.0.1:2445-chardev:charchannel0,id=user-channel0: conflicting/invalid host:port in guest forwarding rule 'tcp:127.0.0.1:2445-chardev:charchannel0'
2014-07-01T07:44:27.911350Z qemu-kvm: -netdev user,guestfwd=tcp:127.0.0.1:2445-chardev:charchannel0,id=user-channel0: Device 'user' could not be initialized

(In reply to Hu Jianwei from comment #5)
Of course, because guestfwd outside the default guest address for the interface doesn't make sense.  So by default it has to be an address in the network 10.0.2.0/24 and can't be 10.0.2.2 (DHCP server) or 10.0.2.3 (DNS server).

(In reply to Martin Kletzander from comment #6)
> (In reply to Hu Jianwei from comment #5)
> Of course, because guestfwd outside the default guest address for the
> interface doesn't make sense.  So by default it has to be an address in the
> network 10.0.2.0/24 and can't be 10.0.2.2 (DHCP server) or 10.0.2.3 (DNS
> server).

Yes, the domain can start successfully.

[root@rhel6 ~]# virsh dumpxml r7 | grep channel -A4
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/foo'/>
      <target type='guestfwd' address='10.0.2.9' port='2445'/>
    </channel>
...

[root@rhel6 ~]# virsh start r7
Domain r7 started

[root@rhel6 ~]# ps aux | grep qemu-kvm
qemu     13389 52.9  0.3 1536916 30804 ?       Sl   14:47   0:05 /usr/libexec/qemu-kvm -name r7 -S -M rhel6.5.0 -enable-kvm -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 727bfa08-3937-aee7-8b61-13a6ec1c398e -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/r7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:68:d6:f0,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/foo,server,nowait -netdev user,guestfwd=tcp:10.0.2.9:2445-chardev:charchannel0,id=user-channel0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on

According to comment 7's testing results, we can get expected results, so changed to 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.

http://rhn.redhat.com/errata/RHBA-2014-1374.html