[zones-discuss] Zone Isolation Host Protection (vbox in a zone panics system)
Hello everyone, I recently took on a project to run a VirtualBox guest within a whole Solaris zone. The idea was to protect the Solaris system from any crashes vbox might have. I need to run vbox on a production system, but I didn't want to put the whole system at risk. I was using Solaris 5/09 x86 with VirtualBox 2.2.2. Vbox would run ok as long as I didn't try to power-off the virtual machine. When I would power off a vbox guest, within just a few mins the Solaris host would panic with the following message in syslog: [i]genunix: [ID 335743 kern.notice] BAD TRAP: type=e (#pf Page fault) rp=d55a3ccc addr=490070e4 occurred in module genunix due to an illegal access to a user address[/i] This was easily repeatable... and in two cases even made the host OS unbootable -- device driver couldn't be loaded. Without vbox running, the zone would function as expected and run indefinitely without issue. As a result of this, I had to change the version of vbox I was using and run the vbox within the global zone (risky). It seems to be running rock solid so far, but the whole experience has left me seriously questioning the safety of Solaris zones. Plus, I don't have the option of isolating the vbox machines as I originally had hoped. This is where I need help. I may simply have a misunderstanding of what a zone can do. My understanding was that applications (ie vbox) running within a zone would be completely isolated from the host system. Bad software, security breaches, etc. would all be contained within the zone and the host system, and any other zones, would be protected from a problem zone. As I have explained above, this was not the case. So, what should I expect from zones? Since they are not fully isolated from the global zone and underlying host, what degree of confidence should I put into their resiliency and their security? If, as I experienced, a rogue application can cause a system panic, wouldn't a potential intruder be able to do the same thing? I really was falling in love with Zones and the potential I thought they would offer me, but this experience has really made me question my decision to use them and I need some help understanding exactly what went wrong. If anyone can offer some insight, I'd be grateful. Thanks to all in advance, -Michael -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] FSS and processor sets
I read somewhere which says FSS can be assigned to processor sets, resulting in more sensitive control of priorities on a server than raw processor sets can any one tell me how we can assign FSS to processor set and how it works ? Thanx . -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] FSS and processor sets
On 06/11/09 08:38, Ketan wrote: I read somewhere which says FSS can be assigned to processor sets, resulting in more sensitive control of priorities on a server than raw processor sets can any one tell me how we can assign FSS to processor set and how it works ? Thanx . If you create manual resource pools, you can also assign shares to the zones assigned to the pool so they can 'share' the CPUs in the pool. So if you create a resource pool P with N CPUs, and you assign zones a, b, and c to pool P, with shares of 100, 200, and 300, respectively, when all N CPUs are utilized by the zones, the scheduler with give zone a 100/600*N, zone b 200/600*N, and zone c 300/600*N of the resources (barring other constraints such as blocking on I/O). This does not work if you use the dedicated-cpu directive, as it create a resource pool for the zone, and there is one-to-one relationship between the pool and the zone. Within a zone you can also use FSS for projects. Steffen ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Zone Isolation Host Protection (vbox in a zone panics system)
On Thu, Jun 11, 2009 at 2:06 AM, Michael McKnightno-re...@opensolaris.org wrote: Hello everyone, I recently took on a project to run a VirtualBox guest within a whole Solaris zone. The idea was to protect the Solaris system from any crashes vbox might have. I need to run vbox on a production system, but I didn't want to put the whole system at risk. I was using Solaris 5/09 x86 with VirtualBox 2.2.2. Vbox would run ok as long as I didn't try to power-off the virtual machine. When I would power off a vbox guest, within just a few mins the Solaris host would panic with the following message in syslog: [i]genunix: [ID 335743 kern.notice] BAD TRAP: type=e (#pf Page fault) rp=d55a3ccc addr=490070e4 occurred in module genunix due to an illegal access to a user address[/i] This was easily repeatable... and in two cases even made the host OS unbootable -- device driver couldn't be loaded. Without vbox running, the zone would function as expected and run indefinitely without issue. As a result of this, I had to change the version of vbox I was using and run the vbox within the global zone (risky). It seems to be running rock solid so far, but the whole experience has left me seriously questioning the safety of Solaris zones. Plus, I don't have the option of isolating the vbox machines as I originally had hoped. This is where I need help. I may simply have a misunderstanding of what a zone can do. My understanding was that applications (ie vbox) running within a zone would be completely isolated from the host system. Bad software, security breaches, etc. would all be contained within the zone and the host system, and any other zones, would be protected from a problem zone. As I have explained above, this was not the case. So, what should I expect from zones? Since they are not fully isolated from the global zone and underlying host, what degree of confidence should I put into their resiliency and their security? If, as I experienced, a rogue application can cause a system panic, wouldn't a potential intruder be able to do the same thing? I really was falling in love with Zones and the potential I thought they would offer me, but this experience has really made me question my decision to use them and I need some help understanding exactly what went wrong. If anyone can offer some insight, I'd be grateful. Michael, Your experience shows that zones have a high degree of isolation for user-level applications, but that the isolation can be significantly reduced whenever the kernel is modified in some way. I am assuming that when you installed VirtualBox, you installed the SUNWvboxkern package in the global zone. That package adds a kernel module to the kernel. That software runs independently of the zones framework. If there is a bug in that software - or any other kernel module - it has the potential to cause the kernel to panic. As you have seen, this affects all zones on the system. The same is true if you add a 3rd party file system which requires a kernel module or device driver. I suggest discussing the symptom experienced by your system at http://forums.virtualbox.org/ , or reporting this as a bug at: http://www.virtualbox.org/wiki/Bugtracker . --JeffV ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zonestat 1.4.1 problem
On Wed, Jun 10, 2009 at 4:03 PM, Phil Freundno-re...@opensolaris.org wrote: I have a couple of servers that are still running U1 but I'd still like to use zonestat to get as much info as I can. I get the following output when I run zonestat 1.4.1 with debug turned on: root zonestat -l -N /usr/sbin/prtconf /bin/pagesize /bin/echo 'pages_pp_maximum/D;segspt_minfree/D' | mdb -k /usr/sbin/zoneadm list -v /usr/sbin/psrinfo /usr/bin/svcs -H pools svcs: Pattern 'pools' doesn't match any instances /bin/ps -eo zone,pset,pid,comm | grep ' [z]*sched' /usr/bin/ipcs -mbZ Attempt to access disallowed key 'caps' in a restricted hash at zonestat line 502. root Any ideas on how to fix this? Temporarily, you can fix this by commenting out these lines in the zonestat script: $statname = sprintf swapresv_zone_%d, $zoneid{$z}; $vm_use[$zoneid{$z}] = $kstat-{caps}{$zoneid{$z}}{$statname}{usage}; $vm_use_sum += $vm_use[$zoneid{$z}]; $vm_cap[$zoneid{$z}] = $kstat-{caps}{$zoneid{$z}}{$statname}{value}; That kstat wasn't added until the swap cap was added, in S10 5/08. Solaris releases older than that will all have that problem. Sorry about that. This bug is on my list to fix for v1.5 of zonestat. --JeffV ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Can a non-global zone mount an NFS file system from its own global zone?
I'd like to hear the latest on this topic. (in the zones FAQ since 2005) I'm exploring the idea of running lx-brand zones on a Solaris 10-x86 Sunray server, to do light interactive work needing Linux eg: rsh lxzone xterm Potentially, there could be a resource-capped lx-brand zone for each user. It would be awesome to lofs mount our /prj space from the global zone (a 5000+ entry automount map) and leverage Sun's automounter rather than via Linux. Yes, read/write access is required. FYI: I can lofs mount an AFS filesystem (readonly of course), and it works as expected. Thanks, Rob -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Can a non-global zone mount an NFS file system from its own global zone?
You should give exact version. It's unsupported on S10. And any attempt to obtain a fix (even with some automagic automounter feature which would transform mount into a lofs) is returned as a NO WAY !. It would be fun to have some sort of survey to see how many people would be interested in such feature. Nico ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zonestat 1.4.1 problem
Jeff, Those lines were already commented out. It looks like the problem is in these lines: 500 # Get amount and cap of memory locked by processes in each zone. 501 $kstat-update(); 502 my $zh = $kstat-{caps}; 503 foreach my $z (keys(%$zh)) { 504($lkd_use[$z], $lkd_cap[$z]) = @{$kstat-{caps}{$z} 505 {lockedmem_zone_.$z}}{qw(usage value)}; 506 #printf (kstat: lkd_use[$z 507$lkd_use_sum += $lkd_use[$z]; 508 # $lkd_cap[$z] = $lkd_cap[$z]/1024; 509 # printf ($z:lkd:%d MB / %d %s.\n, $lkd_use[$z]/1024/1024, 510 #$lkd_cap[$z](1024^3) ? $lkd_cap[$z]/1024/1024/1024 : $lkd_cap[$z]/1024, 511 #$lkd_cap[$z](1024^3) ? TB : MB); 512 513($vm_use[$z], $vm_cap[$z]) = @{$kstat-{caps}{$z} 514 {swapresv_zone_.$z}}{qw(usage value)}; 515$vm_use_sum += $vm_use[$z]; Thanks, Phil -- This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org