On 1/8/15 2:48 PM, Eric Blake wrote:
On 12/23/2014 05:24 PM, Gary R Hook wrote:
I read that article.
Now shut down the domain (post-pivot) which is using the new disk file,
and start it up, without using a block device. This is the part that no
one seems to write about, nor do I see that in your example. But thank
you very much for your help and your articles; very much appreciated.
What do you mean by "without using a block device"? Are you trying to
revert back to the pre-copy file? Libvirt is supposed to rewrite the
domain XML to reflect the end result of breaking the mirroring (whether
you pivot or abort back to the original), and further starts of the
domain should use the correct current file (which might not be the file
that the earlier domain start used). If you abort a blockcopy before it
is complete, the destination is useless (incomplete). If you end a
blockcopy after it reached mirroring phase, the the file that you
abandon (whether the original if you pivoted, or the destination if you
aborted) is a point-in-time snapshot of the disk at the point you quit
the mirroring; this disk snapshot is liable to need fsck and otherwise
have inconsistencies unless you also ensured that guest I/O was stable
before the point of breaking the mirroring (basically, using guest-agent
freezing and thawing around the operation).
I've responded to Kashyap about this with the solution to my problem. It
was a usage error.
We want a copy that can be used in place of the original. Seems very simple.
If you set up an NBD chain intuitively, based on assumed behavior, then
the file you create is _not_ usable when all is said and done. See my
other post. Based on experiences and observation, writing to an NBD
device is _not_ equivalent to writing to a disk file. I can only
conclude this is because the far end (the NBD server) is not acting like
a disk file. Which, upon reflection, makes perfect sense.
OMG it would be nice if qemu-nbd behavior and usage were documented. 8
years and still nothing of substance in the man page. There's a to-do
there, I guess.
--
Gary R Hook
Senior Kernel Engineer
NIMBOXX, Inc
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
