FireBoard Site Syndication http://www.nexenta.com/corp Mon, 06 Sep 2010 06:56:10 -0700 FireBoard 1.0.5RC2 http://www.nexenta.com/corp/components/com_fireboard/template/default_ex/images/english/emoticons/rss.gif http://www.nexenta.com/corp FireBoard Site Syndication http://www.nexenta.com/corp/forum?func=view&catid=6&id=1312#1316 Hi, It would be helpful if you could post your vmkernel message into http://pastebin.com/ Best wishes, Przemo Fri, 03 Sep 2010 07:04:45 -0700 http://www.nexenta.com/corp/forum?func=view&catid=5&id=1021#1315 We are having this issue and no one really answered it. My Guess is using ESX/ESXi 4 with the developer version is a no go area. What is not clear is is ESX/ESXi compatible with version 3 community edition? Fri, 03 Sep 2010 04:52:36 -0700 http://www.nexenta.com/corp/forum?func=view&catid=6&id=1314#1314 Hi I am trying to adopt Nexenta at a client they have four servers two with full versions paid for, and the development department were using two developer version editions, (2.4 or some thing). One of the developer edition systems has issues, see previous posts, I have said I think it may be something wrong with the developer edition and that I would like to upgrade to the community edition. He says that looking at the table http://www.nexenta.com/corp exentastor-overview exentastor-versions Which shows that the commercial "module target for virtual LUN mapping" is not compatible. Means that the community edition is not compatible with vmware for use with iSCSI. I dont get this as I have been using it with VMware, what is more I can not find a commercial module "target for virtual LUN mapping" Can I use community edition as an iSCSI server with Vmware esx, if so what would be the benefit of the commercial module "target for virtual LUN mapping" It may mean the Target 2.0 Plugin which enables users to create block storage. Does this then mean that the community edition does not work with say VMware esxi? Fri, 03 Sep 2010 03:11:55 -0700 http://www.nexenta.com/corp/forum?func=view&catid=9&id=1311#1311 If you issue the command: setup appliance nms restart on a an appliance that is running the HA plug-in the RSF-1 cluster is stopped and then started, which causes the volumes on the appliance to fail-over. Is there a work-around that will allow you to leave the services running and restart the NMS? Thank you, Davin Wed, 01 Sep 2010 11:11:59 -0700 http://www.nexenta.com/corp/forum?func=view&catid=6&id=1305#1310 Hello, for surviving creation of system checkpoints (for example during nexenta software upgrades) the additional kernel parameters must be added in the script /usr/bin/apt-clone, actual in line 652 (search for 'xpv.*ZFS-BOOT' ). @NEXENTA: Should this be made configurable? (change/feature request) Wed, 01 Sep 2010 05:39:16 -0700 http://www.nexenta.com/corp/forum?func=view&catid=6&id=1237#1308 I found the problem. I manually configured the nexenta box to use two of our Domain Controllers as the WINS servers. First get to a root shell (!bash when logged in as root), then sharectl set -p wins_server_1= smb. Then `setup appliance nms restart` after exiting the root shell. Now I appear to be working fine. The "smbd: DC discovery failed" error message was a red herring and is a known bug according to SunSolve. Tue, 31 Aug 2010 10:57:14 -0700 http://www.nexenta.com/corp/forum?func=view&catid=9&id=1306#1306 Hi, sometimes my NexentaStor system freezes, in particular under load. Shortly before freezing some commands executed in bash (like "df -k" ) return "bash: fork: Not enough space". I realized a process "zdb" which is consuming a great amount of memory: [code] root@NexentaStor1:/# ps -efl | sort +9 | tail -1 F S UID PID PPID C PRI NI ADDR SZ STIME TTY TIME CMD 0 O root 26613 24190 2 39 25 ? 604425 21:43:13 ? 0:09 zdb -D vpool2 [/code] A manual started "zdb" command seems to work normal: [code] root@NexentaStor1:/# zdb syspool: version: 26 name: 'syspool' state: 0 txg: 2784639 pool_guid: 11787533257023609197 hostid: 12889753 hostname: '' vdev_children: 1 vdev_tree: type: 'root' id: 0 guid: 11787533257023609197 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 3361789273443573125 path: '/dev/dsk/c0t0d0s0' devid: 'id1,sd@f0087dc254c647cd30007ca910005/a' phys_path: '/pci@0,0/pci8086,3595@2/pci8086,330@0/pci1028,16d@e/sd@0,0:a' whole_disk: 0 metaslab_array: 30 metaslab_shift: 29 ashift: 9 asize: 72673656832 is_log: 0 create_txg: 4 vpool2: version: 26 name: 'vpool2' state: 0 txg: 2828971 pool_guid: 16551832510698580570 hostid: 12889753 hostname: 'NexentaStor1' vdev_children: 1 vdev_tree: type: 'root' id: 0 guid: 16551832510698580570 create_txg: 4 children[0]: type: 'mirror' id: 0 guid: 885624399223011382 metaslab_array: 31 metaslab_shift: 33 ashift: 9 asize: 1407972540416 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 9436378730494715283 path: '/dev/dsk/c2t0d0s0' devid: 'id1,sd@x2000000339000a64/a' phys_path: '/pci@0,0/pci8086,3599@6/pci8086,32a@0,2/pcie11,101@3/fp@0,0/disk@w2100000339000a64,0:a' whole_disk: 1 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 9378420716003030377 path: '/dev/dsk/c3t0d0s0' devid: 'id1,sd@x20000003390009f2/a' phys_path: '/pci@0,0/pci8086,3599@6/pci8086,32a@0,2/pcie11,101@3,1/fp@0,0/disk@w21000003390009f2,0:a' whole_disk: 1 create_txg: 4 [/code] It seems the system is running out of memory (negative value for "used"!): [code] nmc@NexentaStor1:/$ show appliance memory PROPERTY VALUE total : 3071MB unusable : 8MB kernel : 774MB locked : 1811MB free : 913MB paging : 0 used : -436MB [/code] The big "zdb" command is still running. Killing this process clears the memory situation: [code] nmc@NexentaStor1:/$ show appliance memory PROPERTY VALUE total : 3071MB unusable : 8MB kernel : 824MB locked : 1804MB free : 127MB paging : 0 used : 305MB [/code] After that two "zdb" commands appear in the process list every 20 seconds, but these commands end immediately and have only a little memory footprint: [code] root@NexentaStor1:/# ps -efl | grep zdb F S UID PID PPID C PRI NI SZ STIME TTY TIME CMD 0 O root 27061 24190 1 83 25 5605 21:56:20 ? 0:00 zdb -D vpool2 root@NexentaStor1:/# ps -efl | grep -v grep | grep zdb 0 S root 27073 24190 1 95 25 8308 21:56:41 ? 0:00 zdb -D syspool root@NexentaStor1:/# ps -efl | grep -v grep | grep zdb 0 S root 27124 24190 1 64 25 7948 21:57:04 ? 0:00 zdb -D syspool root@NexentaStor1:/# ps -efl | grep -v grep | grep zdb 0 O root 27128 24190 0 59 25 5382 21:57:05 ? 0:00 zdb -D vpool2 [/code] It seems that "zdb" sometimes runs into an endless loop. I guess "zdb" is called by the trigger "volume-check". Is this trigger essentual for the appliance or could it be disabled? Is there another possible solution? Thanks in advance! J. Fri, 27 Aug 2010 11:14:28 -0700 http://www.nexenta.com/corp/forum?func=view&catid=11&id=1304#1304 We're considering moving to NexentaStor from a Solaris 10 ZFS server to work around a fairly nasty issue that we believe has been fixed in OpenSolaris (and thus Nexenta). We'd like to preserve the contents of our Solaris 10 created zpool. Is this possible when doing a Nexenta install? How easy? I just don't want the installer to automatically wipe out our data if possible. :) Tue, 24 Aug 2010 10:06:24 -0700 http://www.nexenta.com/corp/forum?func=view&catid=6&id=1299#1303 It seems to be caused by the apci settings. Adding ",apci-user-options=2" to the kernel line in the grub configuration did it. Thanks! Sun, 22 Aug 2010 10:22:13 -0700 http://www.nexenta.com/corp/forum?func=view&catid=11&id=1301#1302 Figured out that I need to install x and gnome, gdm or xfce desktop post install of nexentacore. However I didnt configure lo0 at the time of install. How to configure lo0 post install. Sun, 22 Aug 2010 03:29:19 -0700 http://www.nexenta.com/corp/forum?func=view&catid=9&id=1298#1298 I am attempting to install Nexenta Community Edition for evaluation (long-term we need a HA solution, but need to assess performance first). I am using a Dell PERC 6/i controller, with 6x750GB disks in RAID10. When attempting to auto-partition the disks I get: [code]Cannot auto-partition /dev/rdsk/c0t0d0p0 disk with error: '54674c' is out of range[/code] OpenSolaris install works fine. Tue, 10 Aug 2010 00:06:18 -0700