Re: [zones-discuss] S10 branded zones
Rodney Lindner - SCT wrote: Hi all, has there been any thought of a S10 branded zone running under NV. Most of my servers run NV, but at times I need to test software that only runs on S10. Running up a branded zone would make my life very simple. We have the following RFE open. 646 Solaris 10 zones on OpenSolaris binary (supported) distributions Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] code review: native brand refactoring
I have updated the webrev at: http://cr.opensolaris.org/~gjelinek/webrev/ This includes the changes for the feedback I have received so far. I also added the zlogin.c file to the webrev with two bug fixes. One of these was for a bug I was hitting during testing of these changes and there is a second bug in zlogin that came in which I also fixed. So, at a minimum, it would be good to take a look at that additional file. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] S10 branded zones
Are you running sparc or x86? On x86, you can use Xen or Virtualbox today to run s10 guests. On sparc, you can use ldoms on sun4v. If you indeed need a zones-based solution, please elaborate on your requirements. -Thanks, -Steve L. On Sun, May 25, 2008 at 10:41:29AM +1000, Rodney Lindner - SCT wrote: Hi all, has there been any thought of a S10 branded zone running under NV. Most of my servers run NV, but at times I need to test software that only runs on S10. Running up a branded zone would make my life very simple. Regards Rodney -- = Rodney Lindner Services Chief Technologist Sun Microsystems Australia Phone: +61 (0)2 94669674 (EXTN:59674) Mobile +61 (0)404 815 842 Email: [EMAIL PROTECTED] = ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Installing a zone with JET
Hi,I meant to boot over the net a zonelikne boot net - install but you can't because you don't have OBP at that level Must be a flag into the zonecfg command or zoneadm. On Tue, May 27, 2008 at 2:32 AM, Henrik Johansson [EMAIL PROTECTED] wrote: Hello Team! On May 25, 2008, at 5:31 PM, Crambit Team wrote: Hi all, does anyone know how to jumpstart a new zone over net? Is there a kind of flag to set when you create a zone? JetZONES should handle zone related tasks in Jet, it is included in the Jet package available on sun.com, but there seems to be a later version available also: http://tech.groups.yahoo.com/group/JETJumpStart/message/1956 Regards Henrik ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] code review: native brand refactoring
On Tue, May 27, 2008 at 08:48:17AM -0600, Jerry Jelinek wrote: I have updated the webrev at: http://cr.opensolaris.org/~gjelinek/webrev/ This includes the changes for the feedback I have received so far. I also added the zlogin.c file to the webrev with two bug fixes. One of these was for a bug I was hitting during testing of these changes and there is a second bug in zlogin that came in which I also fixed. So, at a minimum, it would be good to take a look at that additional file. more comments below. all that's left is sw_support.c, i'll get to that tommorow. ed -- usr/src/cmd/zoneadm/zoneadm.c - isn't it kinda weird to have the brand specific cli options come before the brand name when cloning a zone? - why are you parsing arguments by hand in stead of using getopt()? this will result in non-standard argument parsing and probably break things that used to work like: zoneadm -z foo clone -mcopy -sexport/zones/[EMAIL PROTECTED] ... (note the lack of spaces between the flag and the option) or: zoneadm -z foo attach -Fu ... - in clone_func(), done: always calls zonecfg_release_lock_file(), but there are paths that can invoke goto done; without first calling zonecfg_grab_lock_file(). - in clone_func(), it seems like the is_system_labeled() check should be moved out of here and into the native brand postclone callback. - why is there no locking around the pre-detach hook? - in dryrun_get_brand(), use STDIN_FILENO instead of 0. - in dryrun_get_brand(), you might want to always read the manifest into a temporary file. with the current code specifying a manifest path of /dev/fd/0 (which is a standard substitute for -) won't work. - in the case of a forced attach why don't we run the brand callback? - might it simplify zoneadm to just include locking for help request subcommands? - in attach_func(), if the force flag is specified it seems like we'll always call zonecfg_release_lock_file(). (Even if we didn't aquire the lock beforehand.) - uninstall_func() has lots of error returns that don't call zonecfg_release_lock_file(). ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] code review: native brand refactoring
Hey Jerry,
Does this address this comment in 6621020:
This appears to point out at least one bug in zlogin, namely that it
keeps stdout_pipe[1] and stderr_pipe[1] from noninteractive_login()
open when returning to the parent.
Basically, I think the filer expected to see something like:
pipe(stdout);
pipe(stderr);
if (fork() == 0) {
/* in child, close pipe sides read by parent) */
close(stdout[0]);
close(stderr[0]);
.. write to std*[1]...
...
exit(..);
}
/* in parent, close pipe sides written by child */
close(stdout([1]);
close(stderr([1]);
... read from std*[0] ...
...
I think the in child part is handled by the closefrom on line 1559, but
the parent does not close the sides of the pipes that the child writes to.
-Steve
On Tue, May 27, 2008 at 08:48:17AM -0600, Jerry Jelinek wrote:
I have updated the webrev at:
http://cr.opensolaris.org/~gjelinek/webrev/
This includes the changes for the feedback I have
received so far. I also added the zlogin.c file
to the webrev with two bug fixes. One of these was for
a bug I was hitting during testing of these changes
and there is a second bug in zlogin that came in
which I also fixed. So, at a minimum, it would be
good to take a look at that additional file.
Thanks,
Jerry
___
zones-discuss mailing list
zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org
