Re: [Xen-devel] [Xen-users] 4.8.1 migration fails over 1st interface, works over 2nd

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 05/06/17 10:17, George Dunlap wrote:
> On Mon, May 29, 2017 at 10:04 AM, Andreas Pflug
> <pgadmin@xxxxxxxxxxxxxxxxx> wrote:
>> I've setup a fresh Debian stretch with xen 4.8.1 and shared storage via
>> custom block scripts on two machines.
>>
>> Both machine have one main interface with some VLAN stuff, the VM
>> bridges and the SAN interface connected to a switch, and another
>> interface directly interconnecting both machines. To insure packets
>> don't take weird routes, arp_announce=2/arp_ignore=1 is configured.
>> Everything on the primary interface seems to work flawlessly, e.g.
>> ssh-ing from one machine to the other (no firewall or other filter
>> involved).
>>
>> With xl migrate <testdom> <secondMachineDirectInterface>, migration
>> works as expected, bringing up the test domain fully functional back again.
>>
>> With xl migrate --debug <testdom> <secondMachinePrimaryInterface>, I get
>>     xc: info: Saving domain 17, type x86 PV
>>     xc: info: Found x86 PV domain from Xen 4.8
>>     xc: info: Restoring domain
>>
>> and migration will stop here. The target machine will show the incoming
>> VM, but nothing more happens. I have to kill xl on the target, Ctrl-C xl
>> on the source machine, and destroy the target VM--incoming
> Are you saying that migration works fine for you *unless* you add the
> `--debug` option?
>
> Andy / Wei, any ideas?

--debug adds a extra full memory copy, using memcmp() on the destination
side to spot if any memory got missed during the live phase.

It is only indented for development purposes, but it also expect it to
function normally in the way you've used it.

What does `xl -vvv migrate ...` say?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel