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.
On Wed, Nov 7, 2012 at 5:18 PM, Paul Raines <paul.raines@xxxxxxxxx> wrote:
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@xxxxxxxxxx> 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 libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
