does not support cloning vm storage on lvm backend

Jamin,
  I suspect this is related to apparmour profile for libvirt. Do you see messages in dmesg after attempting this ?

Rebooted the server and now I'm no longer getting the "Could not determine original disk information: Disk '/dev/group/volume' does not exist." error. However it fails to actually perform the cloning with the following:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/clone.py", line 756, in _async_clone
    CloneManager.start_duplicate(self.clone_design, meter)
  File "/usr/lib/pymodules/python2.6/virtinst/CloneManager.py", line 634, in start_duplicate
    _do_duplicate(design, meter)
  File "/usr/lib/pymodules/python2.6/virtinst/CloneManager.py", line 659, in _do_duplicate
    dst_dev.setup(meter)
  File "/usr/lib/pymodules/python2.6/virtinst/VirtualDisk.py", line 1076, in setup
    self._do_create_storage(progresscb)
  File "/usr/lib/pymodules/python2.6/virtinst/VirtualDisk.py", line 938, in _do_create_storage
    self._set_vol_object(self.vol_install.install(meter=progresscb),
  File "/usr/lib/pymodules/python2.6/virtinst/Storage.py", line 1161, in install
    raise RuntimeError("Libvirt version does not support "
RuntimeError: Libvirt version does not support storage cloning.

The only output in dmesg during this operation is this:

[81563.970215] type=1503 audit(1281024773.950:22): operation="capable" pid=1526 parent=1 profile="/usr/sbin/libvirtd" name="fsetid"

Jamin, can you add the following to /etc/apparmor.d/usr.sbin.libvirtd:

  capability fsetid,

Then do:
$ sudo apparmor_parser -r -W -T /etc/apparmor.d/usr.sbin.libvirtd

and report back if it resolves the issue for you.

Made the requested apparmor change, checked the dmesg output before attempting to clone the VM, found the following new entry:

[90351.748748] type=1505 audit(1281033561.731:23): operation="profile_replace" pid=7783 name="/usr/sbin/libvirtd"

Looks good so far.

First attempt to clone the VM and set the new drive to the desired LVM device name resulted in an warning dialog:

"Cloning will overwrite the existing file

Using an existing image will overwrite the path during the clone process. Are you sure you want to use this path?"

Answered yes and continued on. Cloning errors with the following:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/clone.py", line 756, in _async_clone
    CloneManager.start_duplicate(self.clone_design, meter)
  File "/usr/lib/pymodules/python2.6/virtinst/CloneManager.py", line 634, in start_duplicate
    _do_duplicate(design, meter)
  File "/usr/lib/pymodules/python2.6/virtinst/CloneManager.py", line 659, in _do_duplicate
    dst_dev.setup(meter)
  File "/usr/lib/pymodules/python2.6/virtinst/VirtualDisk.py", line 1076, in setup
    self._do_create_storage(progresscb)
  File "/usr/lib/pymodules/python2.6/virtinst/VirtualDisk.py", line 968, in _do_create_storage
    self._clone_local(progresscb, size_bytes)
  File "/usr/lib/pymodules/python2.6/virtinst/VirtualDisk.py", line 1015, in _clone_local
    fd = os.open(self.path, os.O_WRONLY | os.O_CREAT)
OSError: [Errno 2] No such file or directory: '/dev/vms/ldap'

However, on the VM host:
# ls -l /dev/vms/ldap
lrwxrwxrwx 1 root root 18 2010-08-05 12:46 /dev/vms/ldap -> ../mapper/vms-ldap
# ls -l /dev/mapper/vms-ldap
brw-rw---- 1 root disk 251, 16 2010-08-05 12:46 /dev/mapper/vms-ldap

As you can see the device does in fact exist and this is backed up by the output of lvs:

# lvs | grep ldap
  ldap vms -wi-a- 10.00g

Now, removing the logical volume and starting fresh results in the following:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/clone.py", line 756, in _async_clone
    CloneManager.start_duplicate(self.clone_design, meter)
  File "/usr/lib/pymodules/python2.6/virtinst/CloneManager.py", line 634, in start_duplicate
    _do_duplicate(design, meter)
  File "/usr/lib/pymodules/python2.6/virtinst/CloneManager.py", line 659, in _do_duplicate
    dst_dev.setup(meter)
  File "/usr/lib/pymodules/python2.6/virtinst/VirtualDisk.py", line 1076, in setup
    self._do_create_storage(progresscb)
  File "/usr/lib/pymodules/python2.6/virtinst/VirtualDisk.py", line 938, in _do_create_storage
    self._set_vol_object(self.vol_install.install(meter=progresscb),
  File "/usr/lib/pymodules/python2.6/virtinst/Storage.py", line 1161, in install
    raise RuntimeError("Libvirt version does not support "
RuntimeError: Libvirt version does not support storage cloning.

After which point virt-manager is fairly unresponsive, all statistics for the VMs are hung, and has to be forcibly exited.

Jamin, were there any other apparmor denied messages in kern.log after you made the profile changes and tried again?

No, nothing.

Here is the full kern.log since the reload:

Aug 5 12:39:21 kvm-host kernel: [90351.748748] type=1505 audit(1281033561.731:23): operation="profile_replace" pid=7783 name="/usr/sbin/libvirtd"
Aug 5 12:46:07 kvm-host kernel: [90757.988390] lo: Disabled Privacy Extensions
Aug 5 13:34:13 kvm-host kernel: [93643.638255] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
Aug 5 13:34:13 kvm-host kernel: [93643.640841] SGI XFS Quota Management subsystem
Aug 5 13:34:13 kvm-host kernel: [93643.647929] JFS: nTxBlock = 8192, nTxLock = 65536
Aug 5 13:34:13 kvm-host kernel: [93643.672639] NTFS driver 2.1.29 [Flags: R/O MODULE].
Aug 5 13:34:13 kvm-host kernel: [93643.701273] QNX4 filesystem 0.2.3 registered.
Aug 5 13:34:13 kvm-host kernel: [93643.742493] Btrfs loaded
Aug 5 13:34:14 kvm-host kernel: [93644.999234] EXT3-fs: INFO: recovery required on readonly filesystem.
Aug 5 13:34:14 kvm-host kernel: [93644.999242] EXT3-fs: write access will be enabled during recovery.
Aug 5 13:34:15 kvm-host kernel: [93645.020791] kjournald starting. Commit interval 5 seconds
Aug 5 13:34:15 kvm-host kernel: [93645.020804] EXT3-fs: recovery complete.
Aug 5 13:34:15 kvm-host kernel: [93645.021491] EXT3-fs: mounted filesystem with ordered data mode.
Aug 5 13:34:51 kvm-host kernel: [93681.930679] kjournald starting. Commit interval 5 seconds
Aug 5 13:34:51 kvm-host kernel: [93681.930700] EXT3-fs: mounted filesystem with ordered data mode.

Restarting the libvirt daemon in addition to the above seems to have cleared things up. I can now clone LVM backed VMs.

This bug was fixed in the package libvirt - 0.8.3-1ubuntu1

---------------
libvirt (0.8.3-1ubuntu1) maverick; urgency=low

  * Merge from debian unstable with security fixes
  * Fixes:
    - LP: #588369
    - LP: #585964
  * Remaining changes:
    - debian/control:
      + Build-Depends on qemu-kvm, not qemu
      + Build-Depends on open-iscsi-utils, not open-iscsi
      + Build-Depends on libxml2-utils
      + Build-Depends on libapparmor-dev and Suggests apparmor
      + Bump bridge-utils, dnsmasq-base, netcat-openbsd, and iptables
        to Depends of libvirt-bin
      + Drop lvm2, qemu-kvm and qemu to Suggests
      + We call libxen-dev libxen3-dev, so change all references
      + Rename Vcs-* to XS-Debian-Vcs-*
    - debian/libvirt-bin.postinst:
      + rename the libvirt group to libvirtd
      + add each admin user to the libvirtd group
      + reload apparmor profiles
    - debian/libvirt-bin.postrm:
      + rename the libvirt group to libvirtd
      + remove apparmor symlinks on purge
    - debian/README.Debian: add AppArmor section based on the upstream
      documentation
    - debian/rules:
      + update DEB_DH_INSTALLINIT_ARGS for upstart
      + add DEB_MAKE_CHECK_TARGET := check
      + use --with-apparmor
      + copy apparmor and apport hook to debian/tmp
    - add debian/libvirt-bin.upstart
    - debian/libvirt-bin.dirs: add /etc/apparmor.d/abstractions,
      /etc/apparmor.d/disable, /etc/apparmor.d/force-complain,
      /etc/apparmor.d/libvirt, /etc/cron.daily and
      /usr/share/apport/package-hooks
    - add debian/libvirt-bin.cron.daily
    - add debian/libvirt-bin.apport
    - debian/libvirt-bin.install: install apparmor profiles, abstractions
      and apport hook
    - debian/apparmor:
      - add TEMPLATE
      - add libvirt-qemu abstraction
      - add usr.lib.libvirt.virt-aa-helper
      - add usr.sbin.libvirtd
    - debian/patches/series:
      + don't apply 0002-qemu-disable-network.diff.patch
      + don't apply 0005-Terminate-nc-on-EOF.patch. Use
        9009-autodetect-nc-params.patch instead
      + 9000-delayed_iff_up_bridge.patch (refreshed)
      + 9001-dont_clobber_existing_bridges.patch
      + 9002-better_default_uri_virsh.patch (refreshed)
      + 9003-better-default-arch.patch (refreshsed)
      + 9004-libvirtd-group-name.patch
      + 9005-increase-unix-socket-timeout.patch (refreshed)
      + 9006-default-config-test-case.patch
      + 9007-fix-daemon-conf-ftbfs.patch (updated)
      + 9008-run-as-root-by-default.patch (refreshed)
      + 9009-autodetect-nc-params.patch (refreshed)
      + 9010-dont-disable-ipv6.patch (refreshsed)
      + 9011-move-ebtables-script.patch (refreshed)
  * Dropped the following patches included/fixed upstream:
    - 9012-fix-nodeinfotest-ftbfs.patch
    - 9013-apparmor-lp457716.patch
  * Disable virtualbox support since virtualbox-ose is not in main
    - debian/control: remove virtualbox-ose build dependency
    - debian/rules: use --without-vbox
  * debian/patches/9012-apparmor-dont-ignore-open.patch: fix logic when
    using virDomainDiskDefForeachPath() and add tests. This can be removed
    in 0.8.4.
  * debian/apparmor/usr.sbin.libvirtd: add capability fseti...