On 09/03/2014 04:10 PM, Gary Hook wrote:
On Wed, Sep 3, 2014 at 2:12 PM, Brian Rak
<brak(a)gameservers.com> wrote:
> Try creating a blank file on the target system at
> /mnt/store01/virt/e7f75b9b-9ed4-4f7e-aa86-e481ab911d6f.qcow2 on 'dewey'.
>
Yes, tried that before posting. At least, with a simple "touch" command.
> Migrations really don't go well when the target disk doesn't exist. I'm
> not certain why this is, I think the migration feature was mainly built
> with shared storage in mind.
>
I appreciate that, but unless it's a documented and designed restriction,
it seems it oughta work. And I know for a fact that it does (details which
I will not include here).
Thank you for your time; much appreciated.
Shared storage migration was implemented first. Non-shared migration
was added after the fact, so you have to explicitly request it; and the
fact that libvirt still can't create the destination file itself is an
annoying limitation that we'd like to lift someday. It would also be
nice if libvirt could detect at least obvious cases of the destination
being incorrect (such as different file sizes) - except that in SOME
cases, you CAN migrate to different sizes (if the source is a single raw
file, but the destination is a brand-new qcow2 file with the original as
its backing, then the guest contents will be identical from either
source or destination perspective up until the point the destination
starts writing into the qcow2 wrapper file). So I'm not sure if any
heuristics can be added to help diagnose obvious problems.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org