Displaying 4 results from an estimated 4 matches for "graeculli".
Did you mean:
graecully
2014 Jul 02
7
virsh blockcopy: doesn't seem to flatten the chain by default
Versions
--------
(Libvirt locally built from a recent git commit -ec7b922):
$ rpm -q libvirt-daemon-kvm qemu-system-x86
libvirt-daemon-kvm-1.2.6-1.fc20.x86_64
qemu-system-x86-2.0.0-1.fc21.x86_64
Test
----
[All images are qcow2 files.]
We have this simple chain:
base <- snap1
Let's quickly examine the contents of 'base' and 'snap1' images:
2014 Jul 03
0
Re: virsh blockcopy: doesn't seem to flatten the chain by default
On 07/03/2014 03:12 AM, Kashyap Chamarthy wrote:
> Versions
> --------
>
> (Libvirt locally built from a recent git commit -ec7b922):
>
> $ rpm -q libvirt-daemon-kvm qemu-system-x86
> libvirt-daemon-kvm-1.2.6-1.fc20.x86_64
> qemu-system-x86-2.0.0-1.fc21.x86_64
>
>
> Test
> ----
>
> [All images are qcow2 files.]
>
>
> We have this
2014 Jul 02
0
Re: virsh blockcopy: doesn't seem to flatten the chain by default
On Thu, Jul 03, 2014 at 12:42:20AM +0530, Kashyap Chamarthy wrote:
[. . .]
Forgot to note: Before blockcopy, the current block device is
snap1.qcow2 (after too, it's the same, since we didn't `--pivot` to the
copy.
> Now, let's do a live blockcopy (with a '--finish' to graecully finish
> the mirroring):
>
> $ virsh blockcopy --domain testvm2 vda \
>
2014 Jul 03
0
Re: virsh blockcopy: doesn't seem to flatten the chain by default
On 07/02/2014 01:12 PM, Kashyap Chamarthy wrote:
> We have this simple chain:
>
> base <- snap1
>
> Let's quickly examine the contents of 'base' and 'snap1' images:
>
> Now, let's do a live blockcopy (with a '--finish' to graecully finish
> the mirroring):
>
> $ virsh blockcopy --domain testvm2 vda \
>