I could not figure out exactly what vol-download or vol-upload do or how they work. But I did discover that vol-create-from does work across pools. It does requires one to create an XML def for the volume which I had never done. It appears at least one does not have to a give a complete definition (I did not specify key or extents for example) or even correct (I specificed qcow2 format but it still made a raw format volume on the LV). SO essentially I did virsh vol-dumpxml surfer-2.img vmback > surfer.xml Edit surfer.xml to have no key, change name, have LV path, etc. virsh vol-create-from vmpool1 surfer.xml surfer-2.img --inputpool vmback I then fired up virt-manager and edited the domain definition to delete the old disk and add the new volume as its new disk. Then booted it in single user mode so I could fix the mac address in the ifcfg-eth0 and udev/rules.d/70-persistant-net.rules files. <div class="gmail_quote">On Wed, Nov 7, 2012 at 5:18 PM, Paul Raines <<a href="mailto:paul.raines@gmail.com" target="_blank">paul.raines@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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="HOEnZb"><div class="h5"> <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> </div></div></blockquote></div>