I have found this problem with libvirt-1.2.7-2.el7.x86_64 and found  libvirt-1.1.29 didn't have this problem ,seems this is a regression bug. 
Bug 1035474 is closed,so clone a bug for RHEL7.1

When cloning a bug, please, try to thing about what you are doing and remove everything which is not relevant to the new bug. Not to mention that in this specific case the bug description does not contain anything that we could start with. However, instead of closing this bug and requiring a new one to be created, let's just add the relevant info to this bug (since I suspect this is not a bug anyway).

So, could you tell us the exact steps you did and what was the result that makes you think this bug is back?

(In reply to Jiri Denemark from comment #3)
> When cloning a bug, please, try to thing about what you are doing and remove
> everything which is not relevant to the new bug. Not to mention that in this
> specific case the bug description does not contain anything that we could
> start with. 
Thanks for your a advice.

> However, instead of closing this bug and requiring a new one to
> be created, let's just add the relevant info to this bug (since I suspect
> this is not a bug anyway).
> 
> So, could you tell us the exact steps you did and what was the result that
> makes you think this bug is back?

I just do the same thing with Bug 1035474 comment 12.

step(Today is not workday,i will offer version and other information which get from my machine on next Monday)：

1. Prepare a guest using vnc and with a password.

2. Enable FIPS mode.
#yum install dracut-fips
#rpm -qa |grep dracut
dracut-network-033-40.el7.x86_64
dracut-033-40.el7.x86_64    
dracut-fips-033-40.el7.x86_64
dracut-config-rescue-033-40.el7.x86_64
#setting configuring "PRELINKING=no" in the /etc/sysconfig/prelink configuration file
#prelink -u -a
#dracut -f

# reboot 

add "fips=1" and boot partition (my machine is /dev/sda2) in kernel command line
in grub2

linux16 /vmlinuz-3.10.0-54.el7.x86_64 root=/dev/mapper/rhel_intel--5205--32--1-root ro rd.lvm.lv=rhel_intel-5205-32-1/swap console=tty0 vconsole.keymap=us reboot=pci console=ttyS0,115200 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=rhel_intel-5205-32-1/root biosdevname=0 crashkernel=256M LANG=en_US.UTF-8 fips=1 boot=/dev/sda2

3. Check fips:
# cat /proc/sys/crypto/fips_enabled
1

4.check libvirt version
# rpm -q libvirt
libvirt-1.2.7-2.el7.x86_64

5.# virsh dumpxml test6

guest have vnc password

6.# virsh start test6
Domain test6 started

7.check in qemu cmdline there is no " -enable-fips"
# ps -ef|grep test6

8.# virt-manager

should use vnc password to log in  guest

9.# virsh destroy test6
Domain test6 destroyed

10.remove vnc password and do step 6 7 there is no "-enable-fips"

And to make sure it is a regression ,downgrade to rhel7.0 release version

11.# rpm -q libvirt

libvirt-1.1.1-29.el7.x86_64

12.# service libvirtd restart

13.# virsh dumpxml test6

guest have vnc password

14.# virsh start test6
error: Failed to start domain test6
error: internal error: early end of file from monitor: possible problem:
qemu-kvm: Failed to start VNC server on `unix:/var/lib/libvirt/qemu/test6.vnc,password': VNC password auth disabled due to FIPS mode, consider using the VeNCrypt or SASL authentication methods as an alternative


15.remove vnc password and start guest

# virsh start test6 
Domain test6 started

17.check in qemu cmdline ,can find " -enable-fips"
# ps -ef|grep test6

Some thing maybe useful:
# cat /proc/sys/crypto/fips_enabled 
1

(gdb) p virQEMUCapsGet(qemuCaps, QEMU_CAPS_ENABLE_FIPS)
$1 = false
(gdb) p *qemuCaps
$3 = {
  object = {
    u = {
      dummy_align1 = 7700611098, 
      dummy_align2 = 0x1cafe001a, 
      s = {
        magic = 3405643802, 
        refs = 1
      }
    }, 
    klass = 0x7f9a081a6f80
  }, 
  usedQMP = true, 
  binary = 0x0, 
  ctime = 0, 
  flags = 0x7f9a04007400, 
  version = 2001000, 
  kvmVersion = 0, 
  arch = VIR_ARCH_X86_64, 
  ncpuDefinitions = 26, 
  cpuDefinitions = 0x7f9a04002240, 
  nmachineTypes = 8, 
  machineTypes = 0x7f9a0400f920, 
  machineAliases = 0x7f9a040070d0, 
  machineMaxCpus = 0x7f9a04009030
}

# ps aux|grep test2
qemu     11816 25.0  3.6 3628720 257112 ?      Sl   14:33   0:13 /usr/libexec/qemu-kvm -name test2 -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 2,maxcpus=4,sockets=4,cores=1,threads=1 -uuid 2264db2c-57c2-412e-9f6b-398b57e6a448 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/test2.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/var/lib/libvirt/images/test2.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:06:5a:5a,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0,password -k en-us -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -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=0x7 -msg timestamp=on

These messages are get from a guest with vnc password  and i found if downgrade libvirt version to 1.1.1-29, this issue disappeared ,then update to 1.2.7-2 ,this issue also disappeared(very strange).So i prepared a machine which do not install libvirt before to do this test (install 1.2.7-2 and do comment 4),also found this issue.

Fixed upstream

commit da7799d879fd037849f820667b9b610bf94b6262
Author: Pavel Hrdina <phrdina>
Date:   Thu Sep 18 17:38:32 2014 +0200

    Move the FIPS detection from capabilities
    
    We are not detecting the presence of FIPS from QEMU, but from procfs and
    that means it's not QEMU capability. It was decided that we will pass
    this flag to QEMU even if it's not supported by old QEMU binaries.
    
    This patch also reverts changes done by commit a21cfb0f to
    qemucapabilitestest and implements a new test case in qemuxml2argvtest.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1135431
    
    Signed-off-by: Pavel Hrdina <phrdina>

Verify this bug with libvirt-1.2.8-4.el7.x86_64

Steps:

1.# cat /proc/sys/crypto/fips_enabled
1

2.# rpm -q libvirt
libvirt-1.2.8-4.el7.x86_64

3.# virsh dumpxml --security-info raw |grep gra
    <graphics type='vnc' port='-1' autoport='yes' passwd='123456'/>


4.# virsh dumpxml raw |grep gra ^C


5.# virsh start raw
error: Failed to start domain raw
error: internal error: early end of file from monitor: possible problem:
2014-10-08T03:41:11.161447Z qemu-kvm: Failed to start VNC server on `127.0.0.1:0,password': VNC password auth disabled due to FIPS mode, consider using the VeNCrypt or SASL authentication methods as an alternative

6.remove password
# virsh edit raw
Domain raw XML configuration edited.

7.# virsh start raw
Domain raw started

8.can found -enable-fips
# ps aux|grep raw
qemu      4214  117  0.4 1672272 34548 ?       Sl   11:41   0:04 /usr/libexec/qemu-kvm -name raw -S -enable-fips -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid c92efd79-1808-43c0-8aef-f31257f54421 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/raw.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/var/lib/libvirt/images/raw.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -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=0x7 -msg timestamp=on

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