[zones-discuss] template tsoldef
Hello, I've opensolaris nv_84 and I look in /etc/zones and see template SUNWtsoldef, what for is this zone ? Regards, -- Maciej Browarski ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] template tsoldef
Dan Price wrote: On Thu 03 Apr 2008 at 11:16AM, Maciej Browarski wrote: Hello, I've opensolaris nv_84 and I look in /etc/zones and see template SUNWtsoldef, what for is this zone ? I believe it is part of the trusted extensions architecture, which relies upon zones. If you're not in Trusted Extensions mode, you should not need to worry about it, and should not use it. -dp Hm, This isn't Time Shift Operation in which I very waiting for ? :) Regards, -- Maciej Browarski ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones + LiveUpgrade + SVM = cpio
Joe, liveupgrade uses a different logic for zones-root filesystems/mountpoints. If the physical mountpoint /zonesroot stays the same, then it copies the zone-root and renames the copy like: /zoneroot/zone_name_one -- /zoneroot/zone_name_one-s10u4-patched later on, if you boot the new environment, the old mountpoint for the zone may be named as /zoneroot/zone_name_one-s10u4 If you use a dedicated filesystem for each zones-root, then you might relocate like this (untested): -m /zoneroot/zone_name_one:/dev/md/dsk/d103:ufs,mirror \ -m /zoneroot/zone_name_one:/dev/md/dsk/d23:detach,attach,preserve This would detach the mirror for this zone, and recreate a new top-level metadevice but could avoid the copy (in subsequent LU runs, probably not the first since the path changes). So you have two choices: - copy all the zones-roots and stay in the same physical Filesystem with alternate zones-root-mountpoints (/etc/zones/* config gets adjusted) or - use a different Filesystem but each zone has it's own Filesystem If anyone knows other options, pls jump in :-). The above is from my experience on Nevada/OpenSolaris around 80-84.. Regards, Thomas On Wed, Mar 26, 2008 at 12:36:50PM -0700, Moore, Joe wrote: I'm seeing some odd behavior when I'm trying to upgrade my Solaris 10u4 (sparc) system. I have SVM configured with a mirrored root (d0) and /zoneroot (d3) filesystems: d0 -m d10 d20 d10 1 1 c1t0d0s0 d20 1 1 c1t1d0s0 d3 -m d13 d23 d13 1 1 c1t0d0s3 d23 1 1 c1t1d0s3 There's a sparse zone with zoneroot at /zoneroot. My lucreate command is: lucreate -n s10u4-patched \ -m /:/dev/md/dsk/d100:ufs,mirror \ -m /:/dev/md/dsk/d20:detach,attach,preserve \ -m /zoneroot:/dev/md/dsk/d103:ufs,mirror \ -m /zoneroot:/dev/md/dsk/d23:detach,attach,preserve So if I'm reading things right, this should split off the 2nd submirror from the 2 filesystems, and preserve their contents when creating the new BE. The BE creation should be (relatively) quick -- just the compare database generation. And when I don't have a zone defined (zoneadm detatch and zonecfg delete), it does go very quickly. But when the zone is present, lucreate does copy the zoneroot via cpio, even though that filesystem should have been preserved. Why? Can't zulu recognize that the filesystem (zoneroot) is already in place? Any thoughts? --Joe ___ zones-discuss mailing list zones-discuss@opensolaris.org -- Thomas Wagner +49-171-6135989 http://www.wagner-net.net ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] The quick dirty guide to zones on iSCSI LUNs
Ellard Roush writes: James Carlson wrote: That point in time is as soon as your application can start. It need not have any dependencies at all. Here is the other point that needs to be clarified. This is not an application. Applications do not start until much later. We have to get the cluster formed and cluster services established before applications run. We probably have different definitions of that term. For networking, an application is something that uses the services provided by a transport or (for raw sockets) network layer protocol. I'm not talking about user applications; just things that use networking services in some way. Your program (whatever it is) should not need dependencies on networking in order to be successful. As I suggested before, it's sometimes helpful to listen to routing sockets (you can get hints there about when it might be a good time to shorten a retry timer, and thus make your program respond more quickly), but it's not really a dependency issue. The internal interfaces that we had to use are not well documented. Your explanation helps understand what is probably going on. It's hinted at in the documentation, but not as well-documented as it should be. man -s 3socket connect says: underlying transport provider. Generally, stream sockets can successfully connect() only once. Datagram sockets can use [..] ECONNREFUSED The attempt to connect was forcefully rejected. The calling program should close(2) the socket descriptor, and issue another socket(3SOCKET) call to obtain a new descriptor before attempting another connect() call. That generally is also true for most unsuccessful connect() calls and the advice under ECONNREFUSED is actually true for pretty much all failures. The exceptions are the non-failure failures -- EALREADY, EINPROGRESS, and EWOULDBLOCK. I think that issue is what the text is trying to dance around. You're partly connected (at least bound) after the real failures, and getting back to a clean state is easiest just by close() and trying again. The usual references (Stevens and others) have more detailed discussions. The underlying problem is that for much of the BSD world, the code *is* the documentation, so whatever sockets did, well, that's what they do. (For what it's worth, this isn't even one of the darker corners. Raw socket behavior, for example, varies in mysterious ways across OS platforms and even across releases of a given OS.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Patches via Live Upgrade with 2 zones on Solaris 10 Update 4 failed
On Fri, Mar 7, 2008 at 7:41 AM, Paul Van Der Zwan wrote: I only ran into it with the servers enabled at boot in the zones, disabling the servers seems to fix the problem. The sockets apparently only were created when the server was running. Even though I had the zones halted the lucreate process started them enough to have the server processes started. I did get an error message from lucreate that the zone copy in the new BE was not created correctly. If you don't get that error you are probably running into something else. The CR number is 2154382, it's an old one but has been bumped up to P1. Paul, So it looks like that CR is definitely what I was running into. I see from http://bugs.opensolaris.org/view_bug.do?bug_id=2154382 that this has been fixed in Solaris 10 Update 5. Do you know if a patch will be made for Solaris 10 Update 4? I finally got a chance to retry the LU on my server yesterday 4/2. I started with the lumake and this time I got the following error. Copying root of zone ldap-supplc. ERROR: Zone ldap-supplc in BE sol10-2007-08: cannot copy root See /tmp/.lucopy.cpio_err.6730.ldap-supplc for details. Checking that error file I see the following. cpio: Cannot open ./root/var/Sun/mps/admin-serv/tmp/iwswatchdog.19207, skipped, errno 122, Operation not supported on transport endpoint cpio: Cannot open ./root/var/Sun/mps/admin-serv/tmp/iwsadmin.19208, skipped, errno 122, Operation not supported on transport endpoint 8052896 blocks 2 error(s) Sure enough these were sockets that were not cleaned up when I shutdown Directory Server 5.2P4. So I went ahead and manully ran rm on each socket file and tried lumake again. This time there were no errors. I did luactivate and booted to the ABE with no problem and the 2 zones started up fine. I then went back to the BE and applied my patches with PCA (yes I know PCA is not supported by Sun) with the following commands. lumount sol10p-20080402 ./pca -R /.alt.sol10p-20080402 --install luumount sol10p-20080402 Another luactivate of the ABE followed by an init 6 and all seems to be fine now. So, hopefully there will be a patch to cpio in the future, or I'll just have to pay closer attention to those lingering sockets. Thanks again to everyone's input and help. I really appreciate it. Regards, -Eric ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] The quick dirty guide to zones on iSCSI LUNs
Hi James, James Carlson wrote: Ellard Roush writes: James Carlson wrote: That point in time is as soon as your application can start. It need not have any dependencies at all. Here is the other point that needs to be clarified. This is not an application. Applications do not start until much later. We have to get the cluster formed and cluster services established before applications run. We probably have different definitions of that term. For networking, an application is something that uses the services provided by a transport or (for raw sockets) network layer protocol. I'm not talking about user applications; just things that use networking services in some way. OK. Now I understand what you mean. Your program (whatever it is) should not need dependencies on networking in order to be successful. As I suggested before, it's sometimes helpful to listen to routing sockets (you can get hints there about when it might be a good time to shorten a retry timer, and thus make your program respond more quickly), but it's not really a dependency issue. The internal interfaces that we had to use are not well documented. Your explanation helps understand what is probably going on. It's hinted at in the documentation, but not as well-documented as it should be. man -s 3socket connect says: underlying transport provider. Generally, stream sockets can successfully connect() only once. Datagram sockets can use [..] ECONNREFUSED The attempt to connect was forcefully rejected. The calling program should close(2) the socket descriptor, and issue another socket(3SOCKET) call to obtain a new descriptor before attempting another connect() call. That generally is also true for most unsuccessful connect() calls and the advice under ECONNREFUSED is actually true for pretty much all failures. The exceptions are the non-failure failures -- EALREADY, EINPROGRESS, and EWOULDBLOCK. I think that issue is what the text is trying to dance around. You're partly connected (at least bound) after the real failures, and getting back to a clean state is easiest just by close() and trying again. The usual references (Stevens and others) have more detailed discussions. The underlying problem is that for much of the BSD world, the code *is* the documentation, so whatever sockets did, well, that's what they do. (For what it's worth, this isn't even one of the darker corners. Raw socket behavior, for example, varies in mysterious ways across OS platforms and even across releases of a given OS.) Thanks for the explanation. Our Quorum Server uses the approach that you suggested. We discovered it the hard way. We are now attempting to use iSCSI devices as quorum devices. I will share your insight with the iSCSI people. Regards, Ellard ___ zones-discuss mailing list zones-discuss@opensolaris.org
