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. <div class="gmail_quote">On Wed, Nov 7, 2012 at 4:37 PM, Eric Blake <<a href="mailto:eblake@redhat.com" target="_blank">eblake@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. </blockquote></div>