This is the normal result if --atomic option is not specified.
But right now, atomic live snapshot of multiple disks is unsupported:

# virsh snapshot-create-as rhel6u3qcow2 s2 --disk-only --atomic
error: unsupported configuration: atomic live snapshot of multiple disks is unsupported

This is not a bug currently, or it could be changed to a RFE.

Hi, Eric 

This bug relates "--atomic" option but disk-snapshot do not support it now .

Does libvirt purpose to support  "atomic live snapshot of multiple disks"  in the RHEL6.4 or RHEL7, if there is a plan to support it , I will change this bug name to "[RFE] support atomic live snapshot of multiple disks " if not  this bug will be closed , because --atomic disk snapshot will not support in the RHEL 
Thanks very much .


Wenlong

Are you using qemu-kvm (disk snapshots not supported) or qemu-kvm-rhev (disk snapshots ARE supported) in your testing?  Do not change this to RFE, because this feature was supposed to work in 6.3, and must work in 6.4, when you are using the correct qemu.

(In reply to comment #4)
> Are you using qemu-kvm (disk snapshots not supported) or qemu-kvm-rhev (disk
> snapshots ARE supported) in your testing?  Do not change this to RFE,
> because this feature was supposed to work in 6.3, and must work in 6.4, when
> you are using the correct qemu.

I am using qemu-kvm-rhev in the disk-snapshot testing 
In this case I need --atomic in the --disk-only snapshot it can not support as comment 2 ,it just support internal snapshot with atomic .
Dose libvirt purpose to support atomic disk snapshot in the rhel6.4 ?

(In reply to comment #5)
> I am using qemu-kvm-rhev in the disk-snapshot testing 

Good.

> In this case I need --atomic in the --disk-only snapshot it can not support
> as comment 2 ,it just support internal snapshot with atomic .

Here's how --atomic is supposed to work:

                              omitted          --atomic
no snapshot support           fail             fail
only blockdev-snapshot-sync   use blockdev     fail
also has transaction          use transaction  use transaction

Older qemu (such as in RHEL 6.1), and qemu-kvm in RHEL 6.3, lacks snapshot support altogether.  The qemu shipped in RHEL 6.2 had blockdev-snapshot-sync but not transaction.  qemu-kvm-rhev (introduced in 6.3) has both methods.

> Dose libvirt purpose to support atomic disk snapshot in the rhel6.4 ?

There should be no change in behavior between atomic disk snapshot support in RHEL 6.3 and RHEL 6.4.  Either you have identified a bug in RHEL 6.3, or a regression in RHEL 6.4.

Close this bug as NOTABUG :

virsh man doc has covered his use case and atomic live snapshot of multiple disks is unsupported 

man virsh : 

...
 If --atomic is specified, libvirt will guarantee that the snapshot either succeeds, or fails with
           no changes; not all hypervisors support this.  If this flag is not specified, then some hypervisors
           may fail after partially performing the action, and dumpxml must be used to see whether any partial
           changes occurred.
...

I need to reopen this bug, because as Eric said, if the qemu you are testing on is qemu-kvm-rhev, this is a bug, because the qemu-kvm-rhev should support transaction, the libvirt should rollback.

If it is the qemu-kvm with only blockdev-snapshot-sync support, it is not a bug.
Wenlong, could you confirm this or let me check it.

(In reply to comment #8)
> I need to reopen this bug, because as Eric said, if the qemu you are testing
> on is qemu-kvm-rhev, this is a bug, because the qemu-kvm-rhev should support
> transaction, the libvirt should rollback.
> 
> If it is the qemu-kvm with only blockdev-snapshot-sync support, it is not a
> bug.
> Wenlong, could you confirm this or let me check it.

Hi,Guannan 
I am sure this case using qemu-kvm-rhev . and it can not run the --disk-only with qemu-kvm which not support disk snapshot.

Yes, it is a bug, The reason and steps to reproduce by using qemu command line is described in libvirt commit log.
upstream mail discusstion link:
https://www.redhat.com/archives/libvir-list/2012-September/msg00796.html

commit ac89a611d487bd273c539eac891525da9795241d
Author: Guannan Ren <gren>
Date:   Thu Sep 13 18:09:44 2012 +0800

    snapshot: fix rollback failure in transaction mode
    
    BZ:https://bugzilla.redhat.com/show_bug.cgi?id=843372
    when qemu supports the 'transaction' monitor command,
    and libvirt's --reuse-ext flag was not specified, libvirt created
    a stub file with zero size in first place. After the failure of
    QEMU transaction command performing qcow2 snapshots on more than
    one drives, the stub file is left behind with non-empty
    by the QEMU transaction command.
    In order to unlink the file, the patch removes the file size checking.
    
    Steps to reproduce the issue:
    Steps:
     1, Create a qemu instance with two drive images of qcow2 type (root user)
        /usr/libexec/qemu-kvm -m 1024 -smp 1 -name "rhel6u1" \
          -drive file=/var/lib/libvirt/images/firstqcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none
          -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \
          -drive file=/var/lib/libvirt/images/secondqcow2,if=none,id=drive-virtio-disk1,format=qcow2,cache=none \
          -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1 -qmp stdio
    
     2, Initialize qemu qmp
        {"execute":"qmp_capabilities"}
    
     3, Remove the second drive image file
        rm -f /var/lib/libvirt/images/secondqcow2
    
     4, Run 'transaction' command with snapshot qemu commands in.
        {"execute":"transaction","arguments":
          {"actions":
            [{"type":"blockdev-snapshot-sync","data":
              {"device":"drive-virtio-disk0","snapshot-file":"/var/lib/libvirt/images/firstqcow2-snapshot.img","format":"qcow2"}
             },
             {"type":"blockdev-snapshot-sync","data":
              {"device":"drive-virtio-disk1","snapshot-file":"/var/lib/libvirt/images/secondqcow2-snapshot.img","format":"qcow2"}
             }]
          },
       "id":"libvirt-6"}
    
     5, Got the error as follows:
        {"id": "libvirt-6",
          "error": {"class": "OpenFileFailed", "desc": "Could not open '/var/lib/libvirt/images/secondqcow2-snapshot.img'",
                    "data": {"filename": "/var/lib/libvirt/images/secondqcow2-snapshot.img"}
                   }
        }
    
     6, List first newly-created snapshot file:
        -rw-r--r--. 1 root root     262144 Sep 13 11:43 firstqcow2-snapshot.img

It might be nice if qemu didn't write metadata into the file (or, if it does write, that it then does ftruncate() back to 0 to undo the write) in the cases where 'transaction' fails; but that question was posed to the upstream qemu list, and meanwhile libvirt still has to deal with current qemu, so it is not worth creating a BZ against qemu at this time.

Test with:
libvirt-0.10.2-0rc1.el6.x86_64


#virsh dumpxml bbb
...
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/var/lib/libvirt/images/bbb.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/var/lib/libvirt/images/rhel62.qcow2'/>
      <target dev='vdb' bus='virtio'/>
      <alias name='virtio-disk1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>
...
# cat snaplive.xml
<domainsnapshot>
<description>snapsnap</description>
<disks>
<disk name='/var/lib/libvirt/images/bbb.qcow2'>
<source file='/var/lib/libvirt/images/bbb.qcow2.new'/>
</disk>
<disk name='/var/lib/libvirt/images/rhel62.qcow2'>
<source file='/var/lib/libvirt/images/rhel62.qcow2.new'/>
</disk>
</disks>
</domainsnapshot>

# virsh start bbb
# chmod 000 /var/lib/libvirt/images/rhel62.qcow2

# ll /var/lib/libvirt/images/*.new
ls: cannot access /var/lib/libvirt/images/*.new: No such file or directory

# virsh snapshot-create bbb --disk-only snaplive.xml 
error: internal error unable to execute QEMU command 'transaction': Could not open '/var/lib/libvirt/images/rhel62.qcow2.new'

# ll /var/lib/libvirt/images/*.new
ls: cannot access /var/lib/libvirt/images/*.new: No such file or directory

So, this is 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/RHSA-2013-0276.html