Just a small update, on the system where the network froze there are two zoneadmd processes that seem stuck.
root@jupiter-cemef:/export/home/alarcher# ps aux | grep zoneadmd root 3438 0.0 0.0 7004 4012 ? S janv. 29 5:26 zoneadmd -z build root 6907 0.0 0.0 5132 1712 ? S janv. 31 0:00 zoneadmd -z build0 I have halted and uninstalled the two zone earlier today. If I try to truss the processes I get: root@jupiter-cemef:/export/home/alarcher# pgrep zoneadmd 3438 6907 root@jupiter-cemef:/export/home/alarcher# truss -p 3438 truss: no such process: 3438 root@jupiter-cemef:/export/home/alarcher# truss -p 6907 truss: unanticipated system error: 6907 Is it expected? On Tue, Feb 1, 2022 at 10:57 PM Aurélien Larcher <[email protected]> wrote: > > > On Tue, Feb 1, 2022 at 10:53 PM Till Wegmueller <[email protected]> > wrote: > >> Huh? >> >> Does this not show the etherstub layout? >> > GZ: >> > root@pegasus:~# dladm show-vnic >> > LINK OVER SPEED MACADDRESS MACADDRTYPE >> > VID >> > br0 ether0 0 2:8:20:da:ec:bb random >> 0 >> > vnic0 ether0 0 2:8:20:cb:7b:85 random >> 0 >> > >> > NGZ: >> > root@build:~# dladm show-vnic >> > LINK OVER SPEED MACADDRESS MACADDRTYPE >> > VID >> > vnic0 ? 0 2:8:20:cb:7b:85 random >> 0 >> >> On OI CI in Hetzner my output looks like this. >> >> root@oidc1:~# dladm show-vnic >> LINK OVER SPEED MACADDRESS MACADDRTYPE VID >> oijenkins0 oinetint0 0 2:8:20:e0:f6:20 random 0 >> gzpublic0 public0 0 2:8:20:37:b7:54 random 0 >> oinetentry0 public0 0 2:8:20:3a:12:52 random 0 >> oinetentry1 oinetint0 0 2:8:20:67:a0:16 random 0 >> >> So I would expect your output to show at least VNIC0 and a VNIC1. >> > > The output below GZ shows both vnics while in the NGZ "build" it shows the > vnic but '?' instead of ether0, and nothing can be done on it. > > > >> Also ip-type=exclusive must be set for it to work. >> > > It is set to exclusive. > > Thank you > >> >> Greetings >> Till >> >> On 01.02.22 18:33, Aurélien Larcher wrote: >> > On Tue, Feb 1, 2022 at 10:27 PM Till Wegmueller <[email protected]> >> > wrote: >> > >> >> Hey Aurelian >> >> >> >> You need two VNIC's one for the Zone and one for the GZ. John names are >> >> hard to differentiate but in the example he also uses two VNICS. >> >> >> > >> > That's exactly what I have done. >> > >> > The vnic for the zone is not used in the GZ, not configured but fails >> to be >> > recognized in the zone. >> > >> > If I create a vnic without an etherstub then the vnic is seen in the >> zone. >> > >> >> >> >> Happy hacking >> >> Till >> >> >> >> On 01.02.22 18:00, Aurélien Larcher wrote: >> >>>> >> >>>> >> >>>> Do not use NWAM: >> >>>> # svcadm enable svc:/network/physical:default >> >>>> # ipadm create-addr -T dhcp bge0/v4 >> >>>> >> >>>> Do create an etherstub for your build NGZ: >> >>>> # dladm create-etherstub zonenet0 >> >>>> # dladm create-vnic -l zonenet0 gz0 >> >>>> # dladm create-vnic -l zonenet0 bz0 >> >>>> >> >>>> Do assign a private network to your etherstub: >> >>>> # ipadm create-addr -T static -a 192.168.0.1/24 gz0/v4 >> >>>> >> >>>> # cat <<EOF| zonecfg -z build -f - >> >>>> add net >> >>>> set allowed-address="192.168.0.2/24" >> >>>> set physical="bz0" >> >>>> set defrouter="192.168.0.1" >> >>>> end >> >>>> EOF >> >>>> >> >>>> Do use ipnat and IP Forwarding to allow your build NGZ to connect >> >>>> your university network: >> >>>> # cat /etc/ipf/ipnat.conf >> >>>> map bge0 192.168.0.0/24 -> 0/32 portmap tcp/udp auto >> >>>> # routeadm -e ipv4-forwarding >> >>>> # routeadm -u >> >>>> >> >>>> >> >>> Dear John, >> >>> thank you for your insightful suggestion and my apologies for the >> delay, >> >> I >> >>> have been busy with a handful of PhD students finishing soon... >> >>> >> >>> I have switched to network/physical:default and implemented your >> >> suggestion >> >>> with the etherstub. >> >>> >> >>> However I am very surprised that on both my systems this approach >> fails >> >> as >> >>> the network interface is not configured in the zone. >> >>> >> >>> Even stranger, it seems that the vnic is only partially exposed to the >> >> zone. >> >>> >> >>> For example: >> >>> >> >>> GZ: >> >>> root@pegasus:~# dladm show-vnic >> >>> LINK OVER SPEED MACADDRESS MACADDRTYPE >> >> VID >> >>> br0 ether0 0 2:8:20:da:ec:bb random >> 0 >> >>> vnic0 ether0 0 2:8:20:cb:7b:85 random >> 0 >> >>> >> >>> NGZ: >> >>> root@build:~# dladm show-vnic >> >>> LINK OVER SPEED MACADDRESS MACADDRTYPE >> >> VID >> >>> vnic0 ? 0 2:8:20:cb:7b:85 random >> 0 >> >>> >> >>> On the second machin the zone simply refused to boot and the zoneadm >> >>> service is stuck, I cannot boot any other zone. >> >>> >> >>> My setup without the etherstub led to a configured interface, in this >> >> case >> >>> the vnic was linked to the physical interface directly. >> >>> >> >>> I wonder if we have some limitations in vanilla illumos which may have >> >> been >> >>> fixed in e.g. smartos. >> >>> >> >>> >> >>> Kind regards, >> >>> >> >>> Aurélien >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>>> >> >>>> Happy hacking, >> >>>> John >> >>>> [email protected] >> >>>> >> >>>> _______________________________________________ >> >>>> openindiana-discuss mailing list >> >>>> [email protected] >> >>>> https://openindiana.org/mailman/listinfo/openindiana-discuss >> >>>> >> >>> >> >>> >> >> >> >> _______________________________________________ >> >> openindiana-discuss mailing list >> >> [email protected] >> >> https://openindiana.org/mailman/listinfo/openindiana-discuss >> >> >> > >> > >> >> _______________________________________________ >> openindiana-discuss mailing list >> [email protected] >> https://openindiana.org/mailman/listinfo/openindiana-discuss >> > > > -- > --- > Praise the Caffeine embeddings > -- --- Praise the Caffeine embeddings _______________________________________________ openindiana-discuss mailing list [email protected] https://openindiana.org/mailman/listinfo/openindiana-discuss
