(In reply to comment #0)
> $ valgrind -v virsh blockpull test /var/lib/libvirt/images/test --wait
It should be 'virsh blockpull test /var/lib/libvirt/images/test --wait' without
valgrind.

Yuck.  The problem here is that we don't learn some of qemu's capabilities until after we start the guest, so the behavior depends on what you have previously done with the guest:

offline
check capability -> not present
start guest
check capability -> present
stop guest
check capability -> present

I can do a quick fix for the symptoms (for the 3 or 4 capabilities that are conditional until the guest is first started, ensure that we are _always_ checking for an online guest before checking those caps), but the _real_ fix is to cache qemu capabilities once, instead of re-computing them per-VM, and as part of the up-front caching, compute even the capabilities that right now are only visible through the guest monitor.

Keeping this bug for the quick fix for 6.3 (swapping the checks is trivial to give us a better error message for offline domains); and cloning into 6.4 for the bigger issue of caching capabilities checks.

Upstream patch proposed:
https://www.redhat.com/archives/libvir-list/2012-April/msg01413.html

In POST:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-April/msg00850.html

Hi Eric,
The blockcopy has the same issue for a offline domain:

# virsh domstate test2
shut off

# virsh blockcopy test2 /var/lib/libvirt/images/test2 /var/lib/libvirt/images/
error: unsupported configuration: block copy is not supported with this QEMU binary

Need I separately open a new bug to track it?

Thanks,
Alex

(In reply to comment #6)
> Hi Eric,
> The blockcopy has the same issue for a offline domain:
> 
> # virsh domstate test2
> shut off
> 
> # virsh blockcopy test2 /var/lib/libvirt/images/test2 /var/lib/libvirt/images/
> error: unsupported configuration: block copy is not supported with this QEMU
> binary

As does 'virsh dompmsuspend' and 'virsh snapshot-create --atomic --disk-only'.

> 
> Need I separately open a new bug to track it?

Nope - the patch in POST fixes all those issues at once.

(In reply to comment #7)
> 
> As does 'virsh dompmsuspend' and 'virsh snapshot-create --atomic --disk-only'.
But virsh blockcopy is different with above commands, as usual, the above commands will judge whether the domain is running, if not, libvirt will raise some error messages, for example:

# virsh dompmsuspend test2 disk
error: Domain test2 could not be suspended
error: argument unsupported: QEMU guest agent is not configured

Notes, in fact, the guest isn't running and guest agent is configured in the guest.

# virsh snapshot-create test2 --atomic --disk-only
error: unsupported configuration: disk snapshots of inactive domains not implemented yet

Notes, in fact, I gave a error argument without xml file in here.

(In reply to comment #8)
> (In reply to comment #7)
> > 
> > As does 'virsh dompmsuspend' and 'virsh snapshot-create --atomic --disk-only'.
> But virsh blockcopy is different with above commands, as usual, the above
> commands will judge whether the domain is running, if not, libvirt will raise
> some error messages, for example:

Indeed, virsh blockcopy has to be patched separately, since it is (at the moment) a RHEL-only patch.  I'll post a 2nd patch shortly; until then, this is back in ASSIGNED.

> 
> # virsh dompmsuspend test2 disk
> error: Domain test2 could not be suspended
> error: argument unsupported: QEMU guest agent is not configured
> 
> Notes, in fact, the guest isn't running and guest agent is configured in the
> guest.

Yep, this is a misleading message that should be fixed by the first patch.

> 
> # virsh snapshot-create test2 --atomic --disk-only
> error: unsupported configuration: disk snapshots of inactive domains not
> implemented yet
> 
> Notes, in fact, I gave a error argument without xml file in here.

No, it is not an error to omit the xml file; doing that lets libvirt generate everything on your behalf (if you don't mind the snapshot having a timestamp for its name).  But the error message is correct for now (it may be worth a separate BZ to add support for offline disk-only snapshots in 6.4).

Back in POST; 2-part patch, with second patch:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-April/msg00864.html

(In reply to comment #9)
> No, it is not an error to omit the xml file; doing that lets libvirt generate
> everything on your behalf (if you don't mind the snapshot having a timestamp
> for its name).  But the error message is correct for now (it may be worth a
> separate BZ to add support for offline disk-only snapshots in 6.4).
Okay, I will file a separate BZ to add support for offline disk-only snapshots in 6.4, thanks for your comments.

Verify this bug :
libvirt-0.9.10-15.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.285.el6.x86_64


#qemu-img create /var/lib/libvirt/images/test 1M

# cat > /tmp/test.xml <<EOF
<domain type='qemu'>
  <name>test</name>
  <memory>219200</memory>
  <vcpu>1</vcpu>
  <os>
    <type arch='x86_64'>hvm</type>
    <boot dev='hd'/>
  </os>
  <devices>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/libvirt/images/test'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <input type='mouse' bus='ps2'/>
    <graphics type='spice' autoport='yes' listen='0.0.0.0'/>
  </devices>
</domain>
EOF

# virsh define /tmp/test.xml
Domain test defined from /tmp/test.xml
# virsh blockpull test /var/lib/libvirt/images/test --wait
error: Requested operation is not valid: domain is not running

# /etc/init.d/libvirtd status
libvirtd (pid  2033) is running...

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/RHSA-2012-0748.html