I'm not sure what is going on. What I can offer now are some hints about how you can debug this.
"nictagadm list" can be used to show which nic tags the global zone knows about. You should verify that it shows the "dmz" tag. The zone's vnics are created by the code in /usr/lib/brand/jcommon/statechange. A brand hook executed by zoneadmd will run the code in statechange. I see that this script writes some info to stdout and some to syslog. Commands that fail may write to stderr. If you are running a platform image with the fix for OS-6834 stdout will be logged to /zones/$uuid/logs/platform.log. The fix for OS-6802 will also cause stderr to be logged to the same file. Everything that was logged via "logger" should be found in /var/adm/messages. You can use 'zoneadm -z $uuid boot -X' to cause the brand scripts to be executed in debug mode. This may offer additional hints as to what is going wrong. If you want to add more debugging statements or try to fix problems you find, a common way to do this is: # cp -r /usr/lib/brand /tmp # mount -F lofs -O /tmp/brand /usr/lib/brand At this point, you will be able to edit everything under /usr/lib/brand. Since the files you are editing are really on /tmp, they will be lost when the global zone is rebooted. The original files stored in the platform image will be present on reboot or when you utter "umount /usr/lib/brand". HTH, Mike On Wed, May 30, 2018 at 2:20 AM, Gareth Howell <[email protected]> wrote: > Several times :-) > I tried adding it into the global zone as well. Doing so manually worked > OK, but putting the config commands in /usbkey/config and either rebooting > or doing a ‘sysinfo -u’ didn’t. > > I saw a comment somewhere to the effect that with a kvm zone, unless the > adapter was plumbed in the global zone, it would appear in the kvm zone. (I > can’t remember where I saw this). Given that I can’t get the adapter’s > presence to persist across a reboot, should I be looking at this first? > > Unfortunately, there’s very little documentation on persisting adapter > information, beyond one example. > > Gareth > > On 29 May 2018 at 21:09:59, Mike Gerdts ([email protected]) wrote: > >> >> Taking a closer look at the initial output you provided, I can see that >> the zone with the first NIC is 4bc5b510-2d5d-e47e-c3bc-d492dfeae320. >> The "dladm show-vnic" output shows only one vnic in that zone. That makes >> it completely unsurprising that you don't see the second vnic in the guest. >> >> Did you reboot the kvm instance after updating the configuration? >> >> Mike >> > *smartos-discuss* | Archives > <https://www.listbox.com/member/archive/184463/=now> | Modify > <https://www.listbox.com/member/?> Your Subscription > <http://www.listbox.com> > ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125 Powered by Listbox: http://www.listbox.com
