Re: [Xen-devel] Restore PVHVM DomU with a different MAC

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Sep 14, 2017 at 09:45:37AM +0800, Kangjie Xi wrote:
> 2017-09-13 17:24 GMT+08:00 Wei Liu <wei.liu2@xxxxxxxxxx>:
> > On Wed, Sep 13, 2017 at 04:25:17PM +0800, Kangjie Xi wrote:
> >> Hi,
> >>
> >> I created a Ubuntu-17.04-x64 PVHVM DomU, so I can use "xl
> >> network-attach/detach" to add/delete network interfaces, it works
> >> well.
> >>
> >> However I wanted to restore the DomU with a different MAC address, so
> >> before saving the checkpoit file, I deleted the network interface with
> >> "xl netwrok-detach", and assigned a different MAC in the configuration
> >> file and restored the DomU:
> >>
> >> # xl network-detach ubuntu 0
> >> # xl save ubuntu ubuntu.checkpoint
> >> # xl restore ubuntu.cfg ubuntu.checkpoint
> >>
> >
> > Doing this causes xl to ignore the saved state and use the provided
> > config file to construct the new guest iirc. I haven't checked the code
> > in detail though.
> >
> > The end result seems to be what you wanted.
> >
> >>  But the DomU didn't detect the new network interface. In Dom0, could
> >> see the DomU has new MAC.
> >>
> >> # xl network-list ubuntu
> >> Idx BE Mac Addr.         handle state evt-ch   tx-/rx-ring-ref BE-path
> >> 0   0  00:16:3e:eb:ca:67     0     1     -1    -1/-1
> >> /local/domain/0/backend/vif/139/0
> >>
> >
> > A vif is created but DomU can't find it. It is possible DomU kernel
> > doesn't go through the whole cycle of device probing and simply ignores
> > a vif that it doesn't know about during restore. As far as it is
> > concerned, the vif originally provided is already gone. The new vif
> > shows up out of nowhere.
> >
> > You may be able to manually generate a udev event to make the kernel
> > probe the new vif. I don't know.
> >
> >> If I add network interface manually after restoring, the DomU can
> >> detect new network interface automatically.
> >>
> >> # xl network-attach ubuntu type=vif mac=00:16:3e:eb:ca:68 bridge=virbr0
> >>
> >> # xl network-list ubuntu
> >> Idx BE Mac Addr.         handle state evt-ch   tx-/rx-ring-ref BE-path
> >> 0   0  00:16:3e:eb:ca:67     0     1     -1    -1/-1
> >> /local/domain/0/backend/vif/139/0
> >> 1   0  00:16:3e:eb:ca:68     1     4     -1   529/528
> >> /local/domain/0/backend/vif/139/1
> >>
> >> Is it a bug?
> >>
> >
> > Can't say for sure at this stage.
> 
> Windows with PV drivers DomU can restore with a new MAC address.
> 
> # xl network-detach windows 0
> # xl save windows windows.checkpoint
> # xl restore windows.cfg windows.checkpoint
> 
> After restoring, the Windows DomU can detect the new network interface
> automatically.
> 

Right. I'm afraid you will need to dig into Linux kernel source code to
pin down the root cause.  Windows can work suggests this is not a bug in
Xen toolstack, at least for now.

I vaguely remember there is a fast path in Linux kernel for resuming
which skips some setup steps.  Maybe you can force it to go through the
slow path somehow.

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