Re: [zones-discuss] dhcp zone
A local zone can be a DHCP client/server if you can use IP Instance: http://opensolaris.org/os/project/crossbow/faq/#ipinst_dhcpclient -- Renaud Caroline Carol wrote: Hi all, Is dhcp working in local zone ? May be there is a version for this issue. Thanks a lot for your answer. carol Ne gardez plus qu'une seule adresse mail ! Copiez vos mails http://fr.rd.yahoo.com/mail/mail_taglines/trueswitch/*http://www.trueswitch.com/yahoo-fr/ vers Yahoo! Mail ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones roadmap?
Matty wrote: I was looking through the zone community documentation on opensolaris.org, but was unable to dig up a roadmap. Does anyone happen to know if one exists? I am curious which features are planned for 2008 and 2009. We made an internal roadmap almost a year ago but I don't think we ever posted it on opensolaris.org. We haven't revisited that since then but I think the overall priorities are probably still pretty much the same. I'll see if there is any reason not to post that, and if not, put a copy on the zones page. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zones roadmap?
On Jan 14, 2008 11:09 AM, Jerry Jelinek [EMAIL PROTECTED] wrote: Mads Toftum wrote: On Mon, Jan 14, 2008 at 07:00:36AM -0700, Jerry Jelinek wrote: We made an internal roadmap almost a year ago but I don't think we ever posted it on opensolaris.org. We haven't revisited that since then but I think the overall priorities are probably still pretty much the same. I'll see if there is any reason not to post that, and if not, put a copy on the zones page. That would be incredibly useful. Bonus points for coupling with a list of features and which sxce/s10 they went into. The roadmap is more about looking ahead than back to what we have already done. Here is the main features for S10, working backwards. Sorry, I have a hard time keeping track of the dates that marketing assigns to the S10 update releases. For the sxce releases all of these have been integrated for quite a while, except for S8MA, so unless you are going back more than 6 months you have all of this in any recent sxce build. S10 08/07 (update 4) Improved Resource Management (duckhorn) IP Instances Live Upgrade support BrandZ and the lx brand Solaris 8 Migration Assistant (unbundled) S10 update 3 Rename and Move Clone (ZFS integration currently only in opensolaris) Migration Configurable privileges DTrace support Boot arguments TX S10 update 2 ZFS integration (delegated datasets, not cloning) Is there a roadmap for opensolaris?I am curious which features are planned for 2008 / 2009. Thanks, - Ryan -- UNIX Administrator http://prefetch.net ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] libvirt for Zones
Now that we have libvirt support for both xVM and LDoms, are there any plans to add libvirt support for Zones too? Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
dbus-daemon cannot be run in non-global zones Sure sounds like the question is why not?. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ?: lofs of NFS-mounted file system into a non-global zone
Steffen Weiberle wrote: I have a customer who is restricting NFS access to their data. Thus, instead of authorizing each non-global zone to be a client, would like to authorize only the global zone, and then lofs mount the NFS-mounted file system into the non-global zone. This work manually, but fails when configured via zonecfg. globalzone# zoneadm -z amp1 boot cannot verify fs /net/nfsserver/export/rw/code: NFS mounted file-system. A local file-system must be used. zoneadm: zone amp1 failed to verify Per this old email, there is some reason for preventing this. Anybody know the details, and is doing this manually putting the non-global zones or the system at risk? Some of the comments from the following RFE apply to this case as well: 4963321 RFE: hosting root filesystems for zones on NFS servers Since the comments aren't public I pasted the relevant stuff here: They're primariliy necessary due to (among other things) the fact that an NFS operation may translate to an over-the-wire call, and in fact may open a TCP/UDP connection to the server (if the mount has been inactive for long enough, or there is a failover, or a number of other reasons). While the semantics of process P in zone A doing a read(2) that causes zone B to do network activity on its behalf merely seemed odd (recall that zones have distinct network identities), the scenario of zone A performing a mount, and subsequently zone B opening a new connection to the server such that the client appears to have migrated from zone A to zone B seemed downright wrong. Besides this is the fact that NFS talks to various userland entities (such as statd and lockd) in the course of normal operation; a process in zone A using a mount belonging to zone B would naturally be unable to communicate with these processes due to our restrictions on inter-zone communication. Also recall that zone A and B don't necessarily share the same UID-to-user mappings, and have different host keys and principles which would cause severe problems when attempting to use something like secure or kerberized NFS. Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
I thought I answered that. The dbus-daemon is using a UNIX domain rendezvous file in /tmp in the global zone. The non-global zones have their own instances of /tmp, so the rendezvous file does not exist in their namespace. Even if it did, there would be other problems because the devices that get reported to HAL by the dbus-daemon don't exist in the non-global zones. HAL isn't zone-aware. --Glenn Jordan Brown (Sun) wrote: dbus-daemon cannot be run in non-global zones Sure sounds like the question is why not?. ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] ?: lofs of NFS-mounted file system into a non-global zone
Jerry Jelinek wrote: Steffen Weiberle wrote: I have a customer who is restricting NFS access to their data. Thus, instead of authorizing each non-global zone to be a client, would like to authorize only the global zone, and then lofs mount the NFS-mounted file system into the non-global zone. This work manually, but fails when configured via zonecfg. globalzone# zoneadm -z amp1 boot cannot verify fs /net/nfsserver/export/rw/code: NFS mounted file-system. A local file-system must be used. zoneadm: zone amp1 failed to verify Per this old email, there is some reason for preventing this. Anybody know the details, and is doing this manually putting the non-global zones or the system at risk? Some of the comments from the following RFE apply to this case as well: 4963321 RFE: hosting root filesystems for zones on NFS servers Hi Jerry, Thanks. Without looking at the RFE, Since the comments aren't public I pasted the relevant stuff here: They're primariliy necessary due to (among other things) the fact that an NFS operation may translate to an over-the-wire call, and in fact may open a TCP/UDP connection to the server (if the mount has been inactive for long enough, or there is a failover, or a number of other reasons). While the semantics of process P in zone A doing a read(2) that causes zone B to do network activity on its behalf merely seemed odd (recall that zones have distinct network identities), the scenario of zone A performing a mount, and subsequently zone B opening a new connection to the server such that the client appears to have migrated from zone A to zone B seemed downright wrong. I don't follow the A to B argument. Zone A (the global zone, or the kernel which may be best identified by the global zone) is always making the requests, and hiding that it is B, or C, or D... who may be consuming or creating the data. Similar to how lofs seems to work for local file systems. The understanding I have when loopback mounting a file into a zone is that in the end the global zone has the definitive view of the data. It does seem more direct with local FS, where no other processes are involved. In contrast, when I delegate a ZFS file system to a zone, only that zone can interact with the data. I have explicitly chosen to remove global knowledge of and access to that file system. That is similar to when I mount an NFS file system in a zone. Besides this is the fact that NFS talks to various userland entities (such as statd and lockd) in the course of normal operation; a process in zone A using a mount belonging to zone B would naturally be unable to communicate with these processes due to our restrictions on inter-zone communication. Yes, the global zones is acting as a proxy, intentionally, when I choose to make this mount available to a non-global zone. Thus all access to the origin are from the perspective of the global zone. Also recall that zone A and B don't necessarily share the same UID-to-user mappings, and have different host keys and principles which would cause severe problems when attempting to use something like secure or kerberized NFS. Good point regarding secure NFS. But for all others, the mapping of IDs is already at risk of being different on any loopback mount, whether it is local or NFS. Regarding the behavior I saw, it seems to come down to where is a difference in manual vs. automatic mounts to be handled. Should mount have tested for this and failed? Mount does not directly know that the mount point is in a zone. zoneadm[d] knows this is on behalf of zone, and denies an operation that I can do manually. Is the operation of the system any different in the end whether it is done automatically or manually, or just easier to ignore the manual case? And if this were using secure NFS, would the manual loopback mount operation still work? [Oddly, I just came across this difference again today, on some work I had done a while back. I create the mount manually, and also configured the zone to do this on its next reboot, which happened today, and only now was I reminded that this operation should[?] not be done.] Thanks Steffen Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] dbus in local zones
Glenn Faden wrote: I thought I answered that. The dbus-daemon is using a UNIX domain rendezvous file in /tmp in the global zone. The non-global zones have their own instances of /tmp, so the rendezvous file does not exist in their namespace. Even if it did, there would be other problems because the devices that get reported to HAL by the dbus-daemon don't exist in the non-global zones. HAL isn't zone-aware. I understood that. What I didn't understand was why there wasn't a completely separate instance of the dbus-daemon running in each zone, with its own rendezvous file for communicating with clients in that zone. Why would you expect there to be cross-zone communication here? ___ zones-discuss mailing list zones-discuss@opensolaris.org
