[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?



On Mon, Apr 30, 2018 at 5:16 PM, Jason Cooper <xen@xxxxxxxxxxxxxx> wrote:
> Hi Ian,
>
> On Mon, Apr 30, 2018 at 04:22:30PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("Re: [Xen-devel] reboot driver domain, vifX.Y = 
>> NO-CARRIER?"):
>> > To implement reuse_domid in a sane way, either the toolstack needs to
>> > manage all domids and always sets domid when creating domain or the
>> > hypervisor needs to cooperate -- to have interface to reserve /
>> > pre-allocate domids.
>>
>> I think this is entirely the wrong approach.
>
> Whew.  Glad I didn't start hacking yet...
>
>> I think the right answer is that this is simply a bug in the
>> frontends.  frontends should cope if the backend path pointer in the
>> frontend directory is updated, and should start reading the new
>> backend instead.
>
> Ok, so I'm new to the guts of Xen.  The bug, at a high level, is that
> "When a driver domain is rebooted (domid changed), previously connected
> client domUs can't gain network connectivity to/through the driver
> domain via 'xl network-attach client_domu mac=... bridge=...
> backend=drv_dom'"

Hang on -- just to clarify, something like the following doesn't work
(or wouldn't, you suspect, work)?

* Start driver domain
* Start domU A with no network
* xl network-attach A backend=drv_dom
* [do some stuff]
* xl network-detach A [network devid]
* Restart driver domain
* xl network-attach A backend=drv_dom

 -George

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.