qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [libvirt-users] Using virsh blockcopy -- what's it supp


From: Kashyap Chamarthy
Subject: Re: [Qemu-devel] [libvirt-users] Using virsh blockcopy -- what's it supposed to accomplish?
Date: Fri, 9 Jan 2015 09:30:37 +0100
User-agent: Mutt/1.5.22.1 (2013-10-16)

On Thu, Jan 08, 2015 at 06:04:20PM -0600, Gary R Hook wrote:
> On 1/8/15 2:21 PM, Kashyap Chamarthy wrote:
> 
> >>qemu-img create -f qcow2 /tmp/dsk.test.qcow2
> >
> >A typo? You also need to provide a size here:
> >
> >     $ qemu-img create -f qcow2 /tmp/dsk.test.qcow2 1G
> 
> Yes, my mistake. The size is set to the potential size of the source disk,
> which in this case is 20G.
> 
> >For the rest, I'm afraid I still didn't manage time to test
> >the NBD scenario to give a meaningful response here. I'll let the others
> >who deal with NBD more often respond to it.
> 
> Well, that's the trick, right? No one that may have any experience has
> managed to pitch in to this conversation.
>
> 
> I can add this now: qemu-nbd seems to function like nbd-server, and concern
> itself with serving a filesystem. What's need, however, is a simple _file_.
> The challenge is getting that NBD-served thing to be viewed the same as a
> local disk file.
> 
> It would appear that the virsh option --raw is required. As far as I can
> tell, both virsh and qemu-nbd munge data with the intent of making it
> suitable for a qcow2 destination; the problem is that we don't need
> double-munging. So telling the blockcopy operation to "knock it off" seems
> to make it treat the NBD device the same as it does a simple disk file.
> 
> Yea!
> 
> So I find that the following:
> 
> >>qemu-nbd -f qcow2 -p11112 /tmp/dsk.test.qcow2
> >>nbd-client localhost 11112 /dev/nbd2
> >>virsh dumpxml my_domain > my_domain.xml
> >>virsh undefine my_domain
> >>virsh blockcopy --domain my_domain --wait --verbose --finish
> 
> only requires the addition of "--raw" to the above command. Or, rather, what
> I really need, which is
> 
> virsh blockcopy --domain my_domain --raw
> 
> which I can then control with subsequent commands.

Nice, I see that Eric and Paolo also concur with your observations.

> 
> I'm kinda surprised no one else has tried to do this and lived to write
> about it.

Well, the above is slightly an exaggerated statement, as you can guess
from other responses in this thread, not everyone will invest the time
to write everything they test explaining it to the world. Anyhow, the
issue seems to be resolved, and as you suggested in your other response
to write about this, that'd be useful. :-)

-- 
/kashyap



reply via email to

[Prev in Thread] Current Thread [Next in Thread]