Re: [zones-discuss] Newbie: Just upgraded from 2008.11 to 2009.06 and zone
the UID is not your problem. the problem is that uninstalled is not a valid zone state. (sorry, i just checked my sent emails and i did indeed tell you to set the state to uninstalled, my bad.) the proper state is configured. Aha ! That's suberb: thank you. Everything is back up and running again on that zone, so I'll go and play with all the others. And I'll remember not to use -F on the attach in future :) Thanks, -- Ian. -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] s10 brand code review
I need a code review for the fix for: ssh dumping core on maramba There is a webrev at: http://cr.opensolaris.org/~gjelinek/webrev.crypto/ Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Fwd: Re: snv domU + zones ?
this is just a heads up about: 6738714 guest domains should be able to use multiple unicast addresses this bug prevents zones from using vnics when inside of domUs. (it's an old bug but it just came to my attention, so i figured it might be news to others as well.) ed - Forwarded message from David Edmondson d...@sun.com - Date: Mon, 15 Jun 2009 16:21:20 +0100 From: David Edmondson d...@sun.com To: Edward Pilatowicz edward.pilatow...@sun.com Cc: Fajar A. Nugraha fa...@fajar.net, xen-disc...@opensolaris.org Subject: Re: snv domU + zones ? * edward.pilatow...@sun.com [2009-06-11 19:22:18] On Thu, Jun 11, 2009 at 03:35:52PM +0100, David Edmondson wrote: * fa...@fajar.net [2009-06-11 15:10:34] On Thu, Jun 11, 2009 at 2:58 PM, David Edmondsond...@sun.com wrote: VNICs inside a domU don't work very well (in fact, they work fine, they just don't get to see any traffic from outside the domU) Why is that? I had thought it would be somewhat similar to tun/tap + bridge in Linux, where you can have tun/tap interfaces and bridges in dom0, domU, or both, and they'd function correctly as expected. It's not similar to Linux in this respect. The VNIC implementation would be better described as a non-learning switch (e.g. you assign ports to VMs and each port has an assigned MAC address). There's an RFE to fix this (allow the guest to add more unicast MAC addresses), but it's not yet completed. what's the CR number for this RFE? 6738714 dme. -- David Edmondson, Sun Microsystems, http://dme.org - End forwarded message - ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand code review
- you might want to add the crypto libraries to the list of libraries to watch for breakage. ;) - to improve the readability of crypto_ioctl(), could you make a dedicated function or macro that just does translation between the s10 and nevada versions of crypto_get_function_list_t? - when you make the ioctl call, i see you can do a CT_TSET. in this scenario you only initialize native_param.fl_provider_id, and the rest of native_param is garbage. is that ok or should the rest of native_param be zeroed out? ed On Mon, Jun 15, 2009 at 10:39:39AM -0600, Jerry Jelinek wrote: I need a code review for the fix for: ssh dumping core on maramba There is a webrev at: http://cr.opensolaris.org/~gjelinek/webrev.crypto/ Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand code review
On Mon, Jun 15, 2009 at 11:54:46AM -0600, Jerry Jelinek wrote: Ed, Thanks for reviewing this. Edward Pilatowicz wrote: - you might want to add the crypto libraries to the list of libraries to watch for breakage. ;) Yep. :-) I'm also going to try to see if any of the other default devices that are inside of a zone might have had their ioctl params changes in any way. - to improve the readability of crypto_ioctl(), could you make a dedicated function or macro that just does translation between the s10 and nevada versions of crypto_get_function_list_t? Will do. - when you make the ioctl call, i see you can do a CT_TSET. in this scenario you only initialize native_param.fl_provider_id, and the rest of native_param is garbage. is that ok or should the rest of native_param be zeroed out? For CT_TSET that goes through the new ctfs_ioctl() function, not this new code for /dev/crypto. That function is the original code Jordan did which I just moved out into its own function for readability. oops. my bad. ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] s10 brand code review
Jordan Vaughan wrote: I have a few nits. Some of them (such at [3]) might be ridiculously trivial, so I won't complain if you don't take them into account. Jordan, Thanks for reviewing this. I'll make all of the simplifications you suggested. Thanks again, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] 2 line code review...
hey all, could i get a code review for this two line change: http://cr.opensolaris.org/~edp/onnv-bugs1/ 6850112 zonecfg verify should verify the native brand type thanks ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] 2 line code review...
On Mon 15 Jun 2009 at 03:42PM, Edward Pilatowicz wrote: hey all, could i get a code review for this two line change: http://cr.opensolaris.org/~edp/onnv-bugs1/ 6850112 zonecfg verify should verify the native brand type Looks good. I assume that on SXCE the native brand verify is a no-op? -dp -- Daniel Price, Solaris Kernel Engineeringhttp://blogs.sun.com/dp ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] 2 line code review...
On Mon, Jun 15, 2009 at 03:46:29PM -0700, Dan Price wrote: On Mon 15 Jun 2009 at 03:42PM, Edward Pilatowicz wrote: hey all, could i get a code review for this two line change: http://cr.opensolaris.org/~edp/onnv-bugs1/ 6850112 zonecfg verify should verify the native brand type Looks good. I assume that on SXCE the native brand verify is a no-op? yep. the native brand on SXCE does not supply any verify callbacks: ---8--- e...@jurassic-x4600$ grep verify /usr/lib/brand/native/config.xml verify_cfg/verify_cfg verify_adm/verify_adm ---8--- thanks ed ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] 2 line code review...
Edward Pilatowicz wrote: hey all, could i get a code review for this two line change: http://cr.opensolaris.org/~edp/onnv-bugs1/ 6850112 zonecfg verify should verify the native brand type thanks ed ___ zones-discuss mailing list zones-discuss@opensolaris.org LGTM. Jordan ___ zones-discuss mailing list zones-discuss@opensolaris.org
