Peter Memishian wrote:
> It's not clear to me if you're agreeing or disagreeing with the idea of
> the "namespace manipulations", but I think they're necessary to address
> other problems. For instance, without its own private link namespace (or
> carved-out part of the global link namespace), there is no way for the
> local zone to be sure that it will be able to create a link with a given
> name at any point in time.
As my first paragraph said, we need to be able to create local names
inside zones, to allow it to create names (tunnels now, aggregations and
VLANs down the road.)
But I don't see a need to have names created in the global zone be
removed from the global zone (or have their name changed) as a result of
the global zone giving ownership to another zone.
There are two things that are not clear to me (because I haven't thought
about the tradeoffs)
- should we allow a ngz to vanity name links assigned to it by the gz
(it can vanity name the links it creates without any added complexity I
suspect)
- whether the gz should be able to see (with some qualification to the
name) the links that are created in the ngz. (From the ownership model
it can't modify them, but it might be useful to see that there is a
"zoneA/aggr0" link created by zoneA.)
> DR is another generally thorny issue when it comes to links in zones.
> Seems like one would have to shut down all of the zones using links above
> a given device in order to DR that device out of the system, which is
> unfortunate. But fixing that would probably require a pretty big overhaul
> of the way DR works (maybe to be modeled as a "link down" operation, as
> we'd discussed a while ago).
I think that Xen implicitly takes us down the 'link down' path in any
case, and exploiting that for all NIC DR seems like a significant
simplification to DR.
But short of that, if a physical device is used by a zone that zone has
to be shut down in order to DR out the device.
Erik
