On (05/21/10 06:56), Erik Nordmark wrote:
>
> Yes, it would be very odd if the ngz admin was not able to set persistent
> interface properties, such as an mtu, just because the IP addresses were
> provided from the global zone.
:
> Most of your comments above, while correct, are about implementation and not
> about the architectural and interface aspects of the proposal.
It's not that simple. Even architecturally, the "from_gz" address object type
will quickly hit the incompleteness in the current ipadm model around
address objects when they have more than one address. Here is why.
The example that you listed itself highlights the problem. You had suggested
> That way the ngz admin will see something like
> vnic0/_a from_gz ok 11.1.1.1/24
> vnic0/_b from_gz ok 12.2.3.4/16
this has issues:
1. that's misleading, because it leads me to believe that I can do
# ipadm delete-addr vnic0/_a
or
# ipadm set-addrprop -p foo=bar vnic0/_a
while leaving _b untouched. If the whole address object is a set,
I'm not supposed to be able to do that. We could prevent it
by having some command-specific filters in libipadm, but that then leads to:
2. how should I co-relate the name of each address in the set
to the one used with create-addr? e.g., if the command used to
create from-gz was
ipadm create-addr -T from_gz vnic0/one-name-for-all-of-it
how do I co-relate "_a" with "one-name-for-all-of-it"?
If, on the other hand, I have a single address object name for the
"from_gz" addresses, then how should show-addrprop correctly present
that 11.1.1.1 has a /24 prefixlen, and 12.2.3.4 has a /16 prefixlen?
> I think the added architectural material is a "from_gz" (or whatever it
> makes sense to call it) type of address object, that has the same type of
> behavior as seen by the ngz administrator as the addrconf or dhcp type of
> address objects.
DHCPv4 address objects today only have a single address, and the behavior
for ipadm/IPv6 has the naming problem I list above for
"show-addrprop". Today, ipadm is actually unusable for setting/showing
addrprops (thus avoiding confronting issues like showing prefixlen
correctly).
We just discussed the proposal below on the phone, and it solves all of
the requirements that you mention, and can still be extended to plug
into the ipadm "address object with multiple props" later, when that
model is more complete
To re-enumerate the requirements:
> Yes, it would be very odd if the ngz admin was not able to set persistent
> interface properties, such as an mtu, just because the IP addresses were
> provided from the global zone.
plus other things that have been mentioned, namely
a. show-addr should clearly show the origin as "from_gz",
b. the administrator should be able to persistently create/delete the interface
after the first boot
c. the administrator should not be able to persistently delete/modify a single
address out of a "from_gz" group (i.e., persistent operations, if
supported, apply to the whole group of addresses in the object)
d. it would be preferable if ipadm could be used for everything, instead of
ifconfig.
e. the address values within an object should be based on the allowed-ips
limitations from the GZ.
the steps below even allow the NGZ to never have to fall back to ifconfig:
- on the first boot (and only on the first reboot), ipmgmtd will create
the interface persistently, so that those properties and interface
itself can be accessed through ipadm. I'm also proposing that the
addresses will be created temporarily.
- interfaces with allowed_ips constraints from the GZ will be marked
IFF_L3PROTECT (new, read-only flag) and persistent addresses may not
be created on these (ipadm will return EPERM, and print the appropriate
error message, something like "Cannot create persistent addresses on
interfaces managed by the global zone"). The IFF_L3PROTECT will
be listed in ifconfig output, as well as by a "Z" flag in show-if
output.
- In subsequent boots, any interface that has persistent information
in ipadm.conf and IP address information from the GZ will be
reconstructed using /sbin/ipadm enable-if.
- the administrator can do a delete-if of the l3protect-ed interfaces
at any time to stop /lib/svc/method/net-physical from recreating
these on reboot.
- you can temporarily do set-addrprop on individual addrs from GZ at
any time. The show-addrprop will also work correctly.
- show-addr of addresses on 'Z' interfaces will print origin as
"static/from_gz". Attempts to do "ipadm create-addr -T from_gz" will
print an error message like "Unsupported address type".
There's one aspect here, that Seb quickly noticed- while all this
is flexible when it comes to modifications in the allowed-ips set,
there's no well-defined way here to recognize changes in the set
of assigned datalinks itself (e.g., on this boot, I had vnic1, but
then the GZ generously decides to give me (vnic1 and vnic2) for the
next reboot). The behavior for modifications to the set of datalinks
follows the model in exclusive IP zones, not shared-IP zones.
--Sowmini
_______________________________________________
opensolaris-arc mailing list
[email protected]
