Can you show me how one would use vol-download and vol-upload to do this?
I cannot figure it out from the docs.  What I have in the old directory based storage pool is:

virsh # pool-info vmback
Name:           vmback
UUID:           7a8ab88b-42a9-f4c9-128e-83adea324b9a
State:          running
Persistent:     yes
Autostart:      yes
Capacity:       885.88 GB
Allocation:     65.57 GB
Available:      820.31 GB

virsh # vol-list vmback
Name                 Path
-----------------------------------------
lost+found           /vmback/lost+found
pool.xml             /vmback/pool.xml
ruby.img             /vmback/ruby.img
surfer-1.img         /vmback/surfer-1.img
webtemplate.img      /vmback/webtemplate.img

The new one (LVM) is:

virsh # pool-info vmpool1
Name:           vmpool1
UUID:           a95f6f30-b035-7750-6b7d-77953ee7d9af
State:          running
Persistent:     yes
Autostart:      yes
Capacity:       1.76 TB
Allocation:     0.00
Available:      1.76 TB

And I want to move the ruby domain (single disk file ruby.img) to it.

On Wed, Nov 7, 2012 at 4:37 PM, Eric Blake <eblake@redhat.com> wrote:
On 11/07/2012 02:13 PM, Paul Raines wrote:
>
> I created a new LVM type storage pool on my server and would like to
> move my VM disk volumes in a directory-based pool into this new pool.
> But I cannot figure out how that is done.  I find plenty of information
> on how to migrate live VM images from one host to another, but not on
> how to just move one live from one storage pool to another on the same
> host.
>
> If it cannot be done live, how an I do it non-live?  I guess non-live I
> could clone, but that would change the MAC address.  Just seems that if
> libvirt
> can migrate live it should be able to move a VM between storage pools
> on the same host even easier.

Hmm - you have a good point - right now, 'virsh vol-create-from' and
'virsh vol-clone' only allow motion within a single pool, and not from
one pool to another.  I guess you could use 'virsh vol-download' and
'virsh vol-upload' to move volumes from one place to another, although
those APIs still lack the ability to cleanly state whether you are
migrating metadata (what the host sees) or contents for conversion into
a different format (what the guest sees).  At any rate, these commands
would be useful on offline disks (and NOT for a disk image in active
read-write use by any qemu guest).  I think there's a lot of work that
could be done to improve matters with how we manage volumes and pools.

Meanwhile, live storage migration IS possible, with libvirt 1.0.0 (now
out) and qemu 1.3 (which will be released in December, or if you are
comfortable building from qemu.git now), via the 'virsh blockcopy' command.