[zones-discuss] per-zone SNMP?
What's the status of SNMP in zones? Does it work, and if so, as of what build? Was playing with a limited version of an SNMP browser and network monitoring tool, and realized that my non-global zone (this is all at home, now) wasn't set up for SNMP. (Of course, this is with other distractions like a Mac, a network printer, another Sun (Solaris 9), and other gadgets.) Wondering how much is possible along those lines: getting the ifTable would be basic, system id info, per-zone performance, process, disk space, process monitoring, etc would be wonderful. Small words please, haven't been working with SNMP for all that long... -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Is it possible to determine from the zone as the global zone is called
Hi, i'm new here and i have a question: Is it possible to determine from the zone as the global zone is called? Is there a command in the zone like zoneadm list , which show me the name of the global-zone. I need it for a script in the zone. AFAIK, there is no standard way to do that. Some people create zones with a file containing the hostname of the global zone. Others might put that in oem-banner, or use sneep to put it in nvramrc, along with hardware serial numbers and such.http://wikis.sun.com/display/sneep/Home But none of those are a built-in solution. I like the idea of putting it in nvram better than putting it in a file, since if the zone is moved to another server, it should then show the new location without having to update a file. -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Branded zones and external hardware
hello, I would like to upgrade a Thumper we use as a staging server for backups form Solaris 10 to OpenSolaris. The backup application (NetVault) is only supported on Solaris. So my question is: can a branded Solaris 10 zone access the external tape vault? If so are there likely to be any issues with running an application like NetVault within a branded zone? Devices can be assigned to zones. With a disk, that could be a security issue (a corrupted filesystem could crash the whole system, for example). A tape probably wouldn't be as much of a threat, but that's not the same as saying it would be safe. In general, one should consider very carefully the security and reliability implications of assigning devices to zones. I don't know if anyone has used NetVault within a zone, let alone a branded zone. -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Can a guest LDOM discover the identity of the host system?
That is...is there a mechanism provided to do this? As an afterthought, this also applies to non-global zones, although one can stick something in the oem-banner eeprom variable that is identically visible on all the zones, which is not the case on LDOMs. However, that's not a supported mechanism. Having something that was would be better. Ideal if the same mechanism (on what might or might not be a zone, LDOM, or virtualized instance running under for example Xvm (xen) or VirtualBox) could be used for a guest of any of those sorts to determine its current host for informational purposes only - and for no other purpose, if one wishes to leave migration of guests unaffected! If such a mechanism existed, I imagine that a null string response could be construed as running directly on hardware. If a situation were to exist where both LDOMs and zones within a guest LDOM were in effect (or some other hypothetical nested virtualization), it should only be report its parent. Come to think of it, this facility could even be applicable to dynamic domains, although less important there, since AFAIK there's no mechanism for moving them from one frame to another. In a support situation, we may have monitoring software (perhaps BigBrother or Hobbit, or something more; but those are extensible and more or less open). Even if a monitored system is down, the monitoring history can still be seen. If a client could report where it was running, and had problems, that would simplify investigating whether the host was having problems, how to obtain console access (dynamic if guests get moved around), etc. If there were a standard mechanism that worked with multiple virtualization situations, it would also be helpful in that it could make it possible for the monitoring software to look up the details of providing remote console access. I really think this would help to make virtualization more manageable, particularly if it applied equally to all the different techniques. -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Do sparse root zones share pages of inherited files in the page cache?
Do sparse root zones share pages of inherited files in the page cache across zones? If so, doesn't that mean that, even though whole root on cloned zfs would result in the same _disk_ savings as a sparse zone, it wouldn't get similar savings in the page cache? Has anyone actually measured the impact of this, i.e. of having multiple rather than single copies of libc and various other OS libs and programs resident at once? If that works the way I think it might, I imagine that systems with lots of sparse zones might be likely to take a noticable hit changing over to the whole root plus zfs clone approach. I ask since with SXCE going away, and sparse root zones AFAIK not (yet?) supported in OpenSolaris, that might catch some folks by surprise. -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Do sparse root zones share pages of inherited files in the page cache?
FWIW, I would imagine that the ideal solution, if possible, would be that pages backed by multiply-referenced blocks (snapshots, clones, or maybe even de-duping) would be internally handled like copy-on-write pages, so that the page and its backing store diverge together. I wouldn't be surprised if that's already happening, in which case there's no loss of page cache efficiency that I was worrying about. This is way more complicated than I think I could answer for myself from the code in a reasonable amount of time... -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] nice if pgrep had a -Z flag...
...to print the zone name as well as whatever other output. That's because ps ORs multiple selection options together, but pgrep ANDs them together, which sure would be nice in the global zone; for example, it would be handy to be able to do something like pgrep -Z -x -z zone01,zone02 -u user01,user02 -l -x process_name and get back 123 zone01 process_name 4567 zone02 process_name and so on. But more than that, I think there would be some use for either a new ps option to tell it to combine selection options like pgrep does (ANDing distinct options, while ORing multiple values in a list), or better, an entirely new command; say a pfind command, with find-like syntax (plus format specification of capability comparable to what ps has). That would allow much more complicated selection and output in a variety of situations. This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: Re: [nfs-discuss] NFS server in zones
Tom Haynes wrote: What about the case where the customer wants to administer the zone they purchased and they do not want the global zone admins to have local access to their data? That would violate basics of the zones model. The global zone admin has complete access to all devices attached to the system. How would you prevent the GZ admin from halting the zone, manually mounting the non-global zone's disk partitions into the global zone, and accessing the data? Preventing the global zone from accessing certain hardware components would open a very large can of worms. In terms of that sort of isolation, even hardware domain config (on something like an E25K for example) has to be controlled by _someone_; and said someone probably also has physical access to the hardware, which trumps everything else. I suppose you can have guarded datacenters and complicated two-man rules for hardware or SC/Dom0/global zone root access; short of that, keeping out the folks that control the overall config is a pipe dream. Filesystem encryption would help a little, but top-level privs plus advanced tracing facilities could capture the data in unencrypted form, since to process it, it has to be decrypted sometime. Ultimately everything comes down to minutes required for someone sufficiently capable and well-equipped to get away undetected (at least in the short term) with accessing or modifying something they're not supposed to. That even applies to bank vaults. It's just how much you're willing to pay to protect data of value x from threat y; managed risk (assuming a proper understanding of the factors and available methods for dealing with them), nothing more. Maybe a deity can provide absolute security in some metaphysical sense (although evidence suggests that doesn't usually keep their supporters from getting killed); nothing less than omni-everything is up to the job. The point of that rant is that the _customer_ needs to be made to understand that _nothing_ provides that absolute security, that _they_ should be expected to pay for the level of security they want, and maybe that it would probably be useful if there were a standard approximation of an answer to their obvious question how much more security does the next more expensive approach actually get me? (not neglecting that perhaps spending more on background checks for your global zone admins, rigorous procedures, configuration control, tripwire/ASET/auditing with offsite logs, etc might be a good idea too...) Maybe there's even a legal angle; think of the warning labels on everything including disposable lighters that basically say that if it's abused, bad things can happen. So you don't want to fail to warn the customer if their expectations are grossly unreasonable. Short of separate boxes not sharing SAN (i.e. something with _no_ single point of control), I'd say it's more fault isolation that goes up with more expensive choices (zones, virtualization, logical domains, hardware domains) than it is overall security isolation. This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
