All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jason Cooper <xen@lakedaemon.net>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: reboot driver domain, vifX.Y = NO-CARRIER?
Date: Fri, 27 Apr 2018 16:11:39 +0100	[thread overview]
Message-ID: <1735e92a-7a38-a08d-2b5b-1481409b3dbd@citrix.com> (raw)
In-Reply-To: <20180427150346.GA17249@io.lakedaemon.net>

On 27/04/18 16:03, Jason Cooper wrote:
> All,
>
> On Gentoo Xen 4.9.1, I've been creating minimal Linux DomU's to create a
> virtual, segregated network infrastructure.  This has been going really
> well, and I'm slowly progressing toward a self-updating system.
>
> My main snag has to do with re-attaching VMs to a driver domain after
> rebooting the driver domain.  e.g.
>
>
>                               +-----+
>                             /-| VM1 |
>                            /  +-----+
>        +----+   +-------+ /   +-----+
> ISP ---| SW |---| GW/FW |-----| VM2 |
>        +----+   +-------+ \   +-----+
>         DD        DD       \  +-----+
>                             \-| VMN |
>                               +-----+
>
> So, in this diagram, SW, GW/FW, and VM1 are mini-VMs.  VM2, and the rest
> are full fledged Linux PV VMs.
>
> Only SW, and GW/FW are driver domains.  SW has the physical nic via
> pci-passthrough.  There are actually 7 GW/FW mini-VMs (for 7 public IPs,
> and 7 different networks), and a trunk mini-VM that aren't shown.
>
> The problem occurs when I reboot a driver domain.  Regardless of the
> type of guest attached to it, I'm unable to re-establish connectivity
> between the driver domain and the re-attached guest.  e.g. I reboot
> GW/FW, then re-attach VM1, VM2 and the rest.  No matter how I do it, I
> get:
>
> $ ip link
> ...
> 11: vif20.1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br10 qlen 32
>     link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
>
> In the driver domain.  At this point, absolutely no packets flow between
> the two VMs.  Not even ARP.  The only solution, so far, is to unnecessarily
> reboot the PV guests.  After that, networking is fine.
>
> Any thoughts?

XenServer found this when we investigated using device driver domains in
a similar way.

The underlying problem is that the frontend/backend setup in xenstore
encodes the domid in path, and changing that isn't transparent to the
guest at all.

The best idea we came up with was to reboot the driver domain and reuse
its old domid, at which point all the xenstore paths would remain
valid.  There is support in Xen for explicitly choosing the domid of a
domain, but I don't think that it is wired up sensibly in xl.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-04-27 15:13 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-27 15:03 reboot driver domain, vifX.Y = NO-CARRIER? Jason Cooper
2018-04-27 15:11 ` Andrew Cooper [this message]
2018-04-27 15:35   ` Jason Cooper
2018-04-27 15:52     ` Andrew Cooper
2018-04-27 16:14       ` Jason Cooper
2018-04-27 16:58         ` Wei Liu
2018-04-27 17:27           ` Jason Cooper
2018-05-01 11:29             ` Wei Liu
2018-04-27 17:02         ` Andrew Cooper
2018-04-27 17:13           ` Wei Liu
2018-04-30 15:22             ` Ian Jackson
2018-04-30 16:16               ` Jason Cooper
2018-04-30 16:26                 ` Ian Jackson
2018-04-30 18:14                   ` Jason Cooper
2018-05-01 11:20                     ` Wei Liu
2018-04-30 16:38                 ` George Dunlap
2018-04-30 18:17                   ` Jason Cooper
2018-04-30 18:23                     ` Jason Cooper
2018-05-01 10:25                     ` George Dunlap
2018-05-01 12:37                       ` Jason Cooper
2018-05-01 12:53                         ` Jason Cooper
2018-05-04 22:13                           ` Rich Persaud
2018-05-04 23:03                             ` Marek Marczykowski-Górecki
2018-05-06 15:45                               ` Jason Cooper
2018-05-07 12:04                                 ` Jason Andryuk
2018-05-01 11:50                 ` Wei Liu
2018-05-01 12:49                   ` Jason Cooper
2018-04-27 16:56       ` Wei Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1735e92a-7a38-a08d-2b5b-1481409b3dbd@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xen@lakedaemon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.