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 <[email protected]> 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. > > >
_______________________________________________ libvirt-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvirt-users
