[OmniOS-discuss] Test
This is only a test. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] TEST REQUEST - Running kvm in a zone verification
This most recent update to bloody has put the /dev/kvm device entry into non-global ipkg or lipkg zones. The idea is you can run KVM instances in zones, which is something not available in r151012 or earlier. Our standard methods for running KVM apply: http://omnios.omniti.com/wiki.php/VirtualMachinesKVM But you MUST FIRST dedicate a vnic to the zone in question from the global zone: by creating one in the global and then add net/set physical in zonecfg(1M). Furthemore, that vnic cannot be used for that zone's normal activity (so you'll likely need two vnics, unless you want the zone to do nothing but run KVM). You MUST also dedicate a filesystem to the zone using the dataset methods in zonecfg(1M). I've not been able to test this yet, so I cannot yet make the claim that you can run KVM in a zone starting with r151014. I would appreciate some community help here. I have *some* availability for questions and help, but I really would like someone to take this and run with it. Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] TEST REQUEST - Running kvm in a zone verification
On Mar 11, 2015, at 3:05 PM, Dan McDonald dan...@omniti.com wrote: Oh hell! I actually didn't add KVM into the platform.xml files. /dev/dld *is* in the zones, if you use exclusive-stack (and I don't know a good reason NOT to these days...). I've just pushed out an update to system/zones, which will require a new BE and a reboot, but it has the kvm in platform.xml for both ipkg and lipkg brands. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] TEST REQUEST - Running kvm in a zone verification
On Mar 11, 2015, at 2:23 PM, John D Groenveld jdg...@elvis.arl.psu.edu wrote: In message 5f988f8f-d3c4-4085-98c6-2d0d3d27e...@omniti.com, Dan McDonald writ es: This most recent update to bloody has put the /dev/kvm device entry into non-g lobal ipkg or lipkg zones. The idea is you can run KVM instances in zones, wh ich is something not available in r151012 or earlier. You can run a single KVM instance in a zone with r151012 but you must add /dev/dld and /dev/kvm. Oh hell! I actually didn't add KVM into the platform.xml files. /dev/dld *is* in the zones, if you use exclusive-stack (and I don't know a good reason NOT to these days...). So your script still needs to add /dev/kvm, until I patch illumos-omnios with /dev/kvm in the appropriate platform.xml files. I've not been able to test this yet, so I cannot yet make the claim that you can run KVM in a zone starting with r151014. I would appreciate some communi ty help here. I have *some* availability for questions and help, but I really would like someone to take this and run with it. Awesome! Now to hunt down some raw iron for bloody. I'm going to have to push this back: commit af30091afd0ccd9320c3aee83ac15318e8d9e78f Author: Dan McDonald dan...@omniti.com Date: Wed Mar 11 15:02:54 2015 -0400 Add kvm device accessability to ipkg/lipkg zones. diff --git a/usr/src/lib/brand/ipkg/zone/platform.xml b/usr/src/lib/brand/ipkg/zone/platform.xml index db40c9f..1e4fd5c 100644 --- a/usr/src/lib/brand/ipkg/zone/platform.xml +++ b/usr/src/lib/brand/ipkg/zone/platform.xml @@ -54,6 +54,7 @@ device match=fd / device match=ipnet / device match=kstat / + device match=kvm / device match=lo0 / device match=lofictl / device match=lofi / diff --git a/usr/src/lib/brand/lipkg/zone/platform.xml b/usr/src/lib/brand/lipkg/zone/platform.xml index c5c6041..7433d22 100644 --- a/usr/src/lib/brand/lipkg/zone/platform.xml +++ b/usr/src/lib/brand/lipkg/zone/platform.xml @@ -54,6 +54,7 @@ device match=fd / device match=ipnet / device match=kstat / + device match=kvm / device match=lo0 / device match=lofictl / device match=lofi / Thanks for the help and reality check! Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] TEST REQUEST - Running kvm in a zone verification
In message 5f988f8f-d3c4-4085-98c6-2d0d3d27e...@omniti.com, Dan McDonald writ
es:
This most recent update to bloody has put the /dev/kvm device entry into non-g
lobal ipkg or lipkg zones. The idea is you can run KVM instances in zones, wh
ich is something not available in r151012 or earlier.
You can run a single KVM instance in a zone with r151012
but you must add /dev/dld and /dev/kvm.
I've not been able to test this yet, so I cannot yet make the claim that you
can run KVM in a zone starting with r151014. I would appreciate some communi
ty help here. I have *some* availability for questions and help, but I really
would like someone to take this and run with it.
Awesome!
Now to hunt down some raw iron for bloody.
John
groenv...@acm.org
# cat /etc/release
OmniOS v11 r151012
Copyright 2014 OmniTI Computer Consulting, Inc. All rights reserved.
Use is subject to license terms
# zonecfg -z doors export
create -b
set zonepath=/var/opt/zones/doors
set brand=ipkg
set autoboot=false
set ip-type=exclusive
add net
set physical=vnic2
end
add net
set physical=vnic3
end
add device
set match=/dev/kvm
end
add device
set match=/dev/dld
end
#!/usr/bin/bash
# configuration
NAME=doors
VNIC=vnic3
HDD=/root/doors.raw
CD=/root/openSUSE-13.2-DVD-x86_64.iso
VNC=5
MEM=8192
mac=`dladm show-vnic -po macaddress $VNIC`
/usr/bin/qemu-system-x86_64 \
-name $NAME \
-boot cd \
-enable-kvm \
-vnc 0.0.0.0:$VNC \
-cpu host \
-smp 4 \
-m $MEM \
-no-hpet \
-usbdevice tablet \
-localtime \
-drive file=$HDD,if=ide,index=0 \
-drive file=$CD,media=cdrom,if=ide,index=2 \
-net nic,vlan=0,name=net0,model=e1000,macaddr=$mac \
-net vnic,vlan=0,name=net0,ifname=$VNIC,macaddr=$mac \
-vga cirrus \
-monitor unix:/tmp/$NAME.monitor,server,nowait,nodelay \
-daemonize
if [ $? -gt 0 ]; then
echo Failed to start VM
fi
port=`expr 5900 + $VNC`
public_nic=$(dladm show-vnic|grep vnic2|awk '{print $2}')
public_ip=$(ifconfig $public_nic|grep inet|awk '{print $2}')
echo Started VM:
echo Public: ${public_ip}:${port}
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] TEST REQUEST - Running kvm in a zone verification
On Wed, 11 Mar 2015, Dan McDonald wrote: ; ; On Mar 11, 2015, at 3:05 PM, Dan McDonald dan...@omniti.com wrote: ; ; ; Oh hell! I actually didn't add KVM into the platform.xml files. /dev/dld *is* in the zones, if you use exclusive-stack (and I don't know a good reason NOT to these days...). ; ; I've just pushed out an update to system/zones, which will require a new BE and a reboot, but it has the kvm in platform.xml for both ipkg and lipkg brands. Working fine for me in an lipkg zone. root@test:/root# zoneadm list -vc ID NAMESTATUS PATH BRANDIP 6 testrunning/ native excl root@test:/root# svccfg -s kvm svc:/system/kvm add bsd0 svc:/system/kvm select bsd0 svc:/system/kvm:bsd0 addpg config application svc:/system/kvm:bsd0 setprop config/vnic=bsd0 svc:/system/kvm:bsd0 setprop config/vnc=5 svc:/system/kvm:bsd0 setprop config/mem=4G svc:/system/kvm:bsd0 setprop config/hdd=/dev/zvol/rdsk/test/bsd/hdd0 svc:/system/kvm:bsd0 setprop config/iso=/FreeBSD-9.2-RELEASE-amd64-disc1.iso svc:/system/kvm:bsd0 end root@test:/root# svcadm enable kvm:bsd0 root@test:/root# svcs kvm:bsd0 STATE STIMEFMRI online 0:23:08 svc:/system/kvm:bsd0 oot@test:/root# netstat -an | grep 590 *.5905 *.*0 0 128000 0 LISTEN 172.29.0.95.5905 172.29.0.10.5404389984 0 128872 0 ESTABLISHED *.5905*.* 0 0 128000 0 LISTEN root@test:/root# cat /var/svc/log/system-kvm:bsd0.log [ Mar 12 00:29:52 Executing start method (/lib/svc/method/kvm start). ] svcprop: Couldn't find property `config/extra' for instance `svc:/system/kvm:bsd0'. STARTING WITH: /usr/bin/qemu-system-x86_64 -name bsd0 -enable-kvm -vnc :5 -smp 10 -m 4G -no-hpet-localtime -drive file=/dev/zvol/rdsk/test/bsd/hdd0,if=ide,index=0 -net nic,vlan=0,name=net0,model=e1000,macaddr=2:8:20:25:52:33 -net vnic,vlan=0,name=net0,ifname=bsd0,macaddr=2:8:20:25:52:33 -vga std -daemonize -drive file=/FreeBSD-9.2-RELEASE-amd64-disc1.iso,media=cdrom,if=ide,index=2 -boot cd multiticks: timer_create: Not owner multiticks: could not create timer; disabling timer_create: Not owner Dynamic Ticks disabled qemu-system-x86_64: -net vnic,vlan=0,name=net0,ifname=bsd0,macaddr=2:8:20:25:52:33: vnic dhcp disabled qemu-system-x86_64: -net vnic,vlan=0,name=net0,ifname=bsd0,macaddr=2:8:20:25:52:33: can't ioctl: Invalid argument -- Citrus IT Limited | +44 (0)870 199 8000 | enquir...@citrus-it.co.uk Rock House Farm | Green Moor | Wortley | Sheffield | S35 7DQ Registered in England and Wales | Company number 4899123 ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] test omnios on OI machine / ehh
Did a cold reboot and controller = seen I did my stuff. After a while I did a devfsadm -Cv , removed path_to_inst and a reboot -- -r and controller = gone It's indeed the c11 (see previous message), prtconf -c configure c11 , does nothing (causes no log messages either). Is there a way to configure this manually without having to reboot? The strange thing is that the OI has no problem with this at all. R From: sim@live.nl To: omnios-discuss@lists.omniti.com Date: Wed, 3 Dec 2014 18:04:43 +0100 Subject: Re: [OmniOS-discuss] test omnios on OI machine Thank you very much for the hint, indeed helpful. Subject: Re: [OmniOS-discuss] test omnios on OI machine From: richard.ell...@richardelling.com Date: Wed, 3 Dec 2014 08:58:43 -0800 CC: omnios-discuss@lists.omniti.com To: sim@live.nl I'm glad you got it running ok. Helpful hint below... On Dec 3, 2014, at 2:37 AM, Randy S sim@live.nl wrote: Anybody else had problems with two or more sas hba's in an omnios system ? How was this solved? From: sim@live.nl To: omnios-discuss@lists.omniti.com Date: Wed, 3 Dec 2014 01:45:12 +0100 Subject: Re: [OmniOS-discuss] test omnios on OI machine Hi, was indeed intended for the list. dmesg | grep mptsas dmesg is brain dead. All it does is (from the script itself, /usr/bin/dmesg): /usr/bin/cat -sv `/usr/bin/ls -tr1 /var/adm/messages.? 2/dev/null` \ /var/adm/messages | /usr/bin/tail -200 to show you the last 200 lines in the messages file. For a large system, there can easily be 1000+ lines of boot-time messages. You're better off looking at the messagesfile directly: grep mptsas /var/adm/messages For a better method of identifying loaded drivers, use prtconf: prtconf -Dshows the device tree and the attached drivers. HTH -- richard gives nothing (no output). Hope you have an idea of what to do next. Going to test a current omnios with one hba by adding another to it to see what happens tomorrow. Will be testing with new Dell hardware and solarflare cards probably in the comming weeks also. If you are interrested, will keep you posted. Subject: Re: [OmniOS-discuss] test omnios on OI machine From: dan...@omniti.com Date: Tue, 2 Dec 2014 19:22:15 -0500 CC: dan...@omniti.com To: sim@live.nl Please share these with the community in the future, unless you're sharing confidential data of some sort. On Dec 2, 2014, at 6:59 PM, Randy S sim@live.nl wrote: Hi Dan, It's been a while... I wanted to stay on r10 since that has been in use by quite a community for quite a while now. R12 is still new so usually unforseen hicups can be expected. (We are not frontrunners regarding systems intended for serious use ;-) ). Have been testing omnios for quite a while on systems with one hba now. All was satisfactory. forgot to mention, I did do an fmdump -ev and saw Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:35:17.6783 ereport.sensor.failure 0x02cd95a4cde05801 Dec 02 23:35:17.6868 ereport.sensor.failure 0x02cd9dbb53605801 I guess this is because the one controller cannot be found. That's a fair assessment. dmesg | grep mpt_sa (done just now (not sleepy yet)) gives : Dec 3 00:42:44 omni scsi: [ID 583861 kern.info] sd68 at mpt_sas3: unit-address w5000c50057ad9161,0: w5000c50057ad9161,0 Dec 3 00:42:44 omni scsi: [ID 583861 kern.info] sd69 at mpt_sas3: unit-address w5000c50057adb269,0: w5000c50057adb269,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] sd70 at mpt_sas3: unit-address w5000c50057adea91,0: w5000c50057adea91,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] ses2 at mpt_sas3: unit-address w5003048000b18d3d,0: w5003048000b18d3d,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] mpt_sas4 at mpt_sas0: scsi-iport 20 Dec 3 00:42:45 omni genunix: [ID 936769 kern.info] mpt_sas4 is /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@20 Dec 3 00:42:45 omni genunix: [ID 408114 kern.info] /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@20 (mpt_sas4) online Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] sd71 at mpt_sas4: unit-address w5001517bb27f79f7,0: w5001517bb27f79f7,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] mpt_sas5 at mpt_sas0: scsi-iport v0 Dec 3 00:42:45 omni genunix: [ID 936769 kern.info] mpt_sas5 is /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@v0 Dec 3 00:42:45 omni genunix: [ID 408114 kern.info] /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@v0 (mpt_sas5) online Interesting... note that two mpt_sas controllers (4 and 5) came online. I wonder why one isn't showing up? Grep for mptsas as well, just in case? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com
Re: [OmniOS-discuss] test omnios on OI machine
Anybody else had problems with two or more sas hba's in an omnios system ? How was this solved? From: sim@live.nl To: omnios-discuss@lists.omniti.com Date: Wed, 3 Dec 2014 01:45:12 +0100 Subject: Re: [OmniOS-discuss] test omnios on OI machine Hi, was indeed intended for the list. dmesg | grep mptsas gives nothing (no output). Hope you have an idea of what to do next. Going to test a current omnios with one hba by adding another to it to see what happens tomorrow. Will be testing with new Dell hardware and solarflare cards probably in the comming weeks also. If you are interrested, will keep you posted. Subject: Re: [OmniOS-discuss] test omnios on OI machine From: dan...@omniti.com Date: Tue, 2 Dec 2014 19:22:15 -0500 CC: dan...@omniti.com To: sim@live.nl Please share these with the community in the future, unless you're sharing confidential data of some sort. On Dec 2, 2014, at 6:59 PM, Randy S sim@live.nl wrote: Hi Dan, It's been a while... I wanted to stay on r10 since that has been in use by quite a community for quite a while now. R12 is still new so usually unforseen hicups can be expected. (We are not frontrunners regarding systems intended for serious use ;-) ). Have been testing omnios for quite a while on systems with one hba now. All was satisfactory. forgot to mention, I did do an fmdump -ev and saw Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:35:17.6783 ereport.sensor.failure 0x02cd95a4cde05801 Dec 02 23:35:17.6868 ereport.sensor.failure 0x02cd9dbb53605801 I guess this is because the one controller cannot be found. That's a fair assessment. dmesg | grep mpt_sa (done just now (not sleepy yet)) gives : Dec 3 00:42:44 omni scsi: [ID 583861 kern.info] sd68 at mpt_sas3: unit-address w5000c50057ad9161,0: w5000c50057ad9161,0 Dec 3 00:42:44 omni scsi: [ID 583861 kern.info] sd69 at mpt_sas3: unit-address w5000c50057adb269,0: w5000c50057adb269,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] sd70 at mpt_sas3: unit-address w5000c50057adea91,0: w5000c50057adea91,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] ses2 at mpt_sas3: unit-address w5003048000b18d3d,0: w5003048000b18d3d,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] mpt_sas4 at mpt_sas0: scsi-iport 20 Dec 3 00:42:45 omni genunix: [ID 936769 kern.info] mpt_sas4 is /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@20 Dec 3 00:42:45 omni genunix: [ID 408114 kern.info] /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@20 (mpt_sas4) online Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] sd71 at mpt_sas4: unit-address w5001517bb27f79f7,0: w5001517bb27f79f7,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] mpt_sas5 at mpt_sas0: scsi-iport v0 Dec 3 00:42:45 omni genunix: [ID 936769 kern.info] mpt_sas5 is /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@v0 Dec 3 00:42:45 omni genunix: [ID 408114 kern.info] /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@v0 (mpt_sas5) online Interesting... note that two mpt_sas controllers (4 and 5) came online. I wonder why one isn't showing up? Grep for mptsas as well, just in case? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] test omnios on OI machine
when I do cfgadm -al Ap_Id Type Receptacle Occupant Condition c7 scsi-sas connectedconfigured unknown c7::dsk/c7t50E118E31592d0 disk connectedconfigured unknown c9 scsi-sas connectedconfigured unknown c9::dsk/c9t5000C50055B2A5B1d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2A9A9d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2A139d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2A245d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2B081d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2B249d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2B255d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2BD6Dd0 disk connectedconfigured unknown c9::es/ses0ESI connectedconfigured unknown c9::es/ses1ESI connectedconfigured unknown c9::es/ses2ESI connectedconfigured unknown c9::smp/expd0 smp connectedconfigured unknown c9::smp/expd1 smp connectedconfigured unknown c9::smp/expd2 smp connectedconfigured unknown c10scsi-sas connectedconfigured unknown c10::dsk/c10t5001517BB27F79F7 disk connectedconfigured unknown c11scsi-sas connectedunconfigured unknown usb2/1 usb-hub connectedconfigured ok usb2/1.1 unknown emptyunconfigured ok usb2/1.2 unknown emptyunconfigured ok usb2/1.3 unknown emptyunconfigured ok usb2/1.4 unknown emptyunconfigured ok usb2/1.5 unknown emptyunconfigured ok usb2/1.6 unknown emptyunconfigured ok usb2/2 unknown emptyunconfigured ok usb3/1 usb-hub connectedconfigured ok usb3/1.1 unknown emptyunconfigured ok usb3/1.2 unknown emptyunconfigured ok usb3/1.3 unknown emptyunconfigured ok usb3/1.4 usb-device connectedconfigured ok usb3/1.5 unknown emptyunconfigured ok usb3/1.6 unknown emptyunconfigured ok usb3/1.7 unknown emptyunconfigured ok usb3/1.8 unknown emptyunconfigured ok usb3/2 unknown emptyunconfigured ok i see c11 as unconfigured. Could this be the cause ? From: sim@live.nl To: omnios-discuss@lists.omniti.com Date: Wed, 3 Dec 2014 11:37:31 +0100 Subject: Re: [OmniOS-discuss] test omnios on OI machine Anybody else had problems with two or more sas hba's in an omnios system ? How was this solved? From: sim@live.nl To: omnios-discuss@lists.omniti.com Date: Wed, 3 Dec 2014 01:45:12 +0100 Subject: Re: [OmniOS-discuss] test omnios on OI machine Hi, was indeed intended for the list. dmesg | grep mptsas gives nothing (no output). Hope you have an idea of what to do next. Going to test a current omnios with one hba by adding another to it to see what happens tomorrow. Will be testing with new Dell hardware and solarflare cards probably in the comming weeks also. If you are interrested, will keep you posted. Subject: Re: [OmniOS-discuss] test omnios on OI machine From: dan...@omniti.com Date: Tue, 2 Dec 2014 19:22:15 -0500 CC: dan...@omniti.com To: sim@live.nl Please share these with the community in the future, unless you're sharing confidential data of some sort. On Dec 2, 2014, at 6:59 PM, Randy S sim@live.nl wrote: Hi Dan, It's been a while... I wanted to stay on r10 since that has been in use by quite a community for quite a while now. R12 is still new so usually unforseen hicups can be expected. (We are not frontrunners regarding systems intended for serious use ;-) ). Have been testing omnios for quite a while on systems with one hba now. All was satisfactory. forgot to mention, I did do an fmdump -ev and saw Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:35:17.6783 ereport.sensor.failure 0x02cd95a4cde05801 Dec 02 23:35:17.6868 ereport.sensor.failure 0x02cd9dbb53605801 I guess this is because the one controller cannot
Re: [OmniOS-discuss] test omnios on OI machine / solved
As a last resort I just turned off the machine and kept it off for a few minutes. Turned it back on and both controllers are now properly detected. R From: sim@live.nl To: omnios-discuss@lists.omniti.com Date: Wed, 3 Dec 2014 11:59:11 +0100 Subject: Re: [OmniOS-discuss] test omnios on OI machine when I do cfgadm -al Ap_Id Type Receptacle Occupant Condition c7 scsi-sas connectedconfigured unknown c7::dsk/c7t50E118E31592d0 disk connectedconfigured unknown c9 scsi-sas connectedconfigured unknown c9::dsk/c9t5000C50055B2A5B1d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2A9A9d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2A139d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2A245d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2B081d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2B249d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2B255d0 disk connectedconfigured unknown c9::dsk/c9t5000C50055B2BD6Dd0 disk connectedconfigured unknown c9::es/ses0ESI connectedconfigured unknown c9::es/ses1ESI connectedconfigured unknown c9::es/ses2ESI connectedconfigured unknown c9::smp/expd0 smp connectedconfigured unknown c9::smp/expd1 smp connectedconfigured unknown c9::smp/expd2 smp connectedconfigured unknown c10scsi-sas connectedconfigured unknown c10::dsk/c10t5001517BB27F79F7 disk connectedconfigured unknown c11scsi-sas connectedunconfigured unknown usb2/1 usb-hub connectedconfigured ok usb2/1.1 unknown emptyunconfigured ok usb2/1.2 unknown emptyunconfigured ok usb2/1.3 unknown emptyunconfigured ok usb2/1.4 unknown emptyunconfigured ok usb2/1.5 unknown emptyunconfigured ok usb2/1.6 unknown emptyunconfigured ok usb2/2 unknown emptyunconfigured ok usb3/1 usb-hub connectedconfigured ok usb3/1.1 unknown emptyunconfigured ok usb3/1.2 unknown emptyunconfigured ok usb3/1.3 unknown emptyunconfigured ok usb3/1.4 usb-device connectedconfigured ok usb3/1.5 unknown emptyunconfigured ok usb3/1.6 unknown emptyunconfigured ok usb3/1.7 unknown emptyunconfigured ok usb3/1.8 unknown emptyunconfigured ok usb3/2 unknown emptyunconfigured ok i see c11 as unconfigured. Could this be the cause ? From: sim@live.nl To: omnios-discuss@lists.omniti.com Date: Wed, 3 Dec 2014 11:37:31 +0100 Subject: Re: [OmniOS-discuss] test omnios on OI machine Anybody else had problems with two or more sas hba's in an omnios system ? How was this solved? From: sim@live.nl To: omnios-discuss@lists.omniti.com Date: Wed, 3 Dec 2014 01:45:12 +0100 Subject: Re: [OmniOS-discuss] test omnios on OI machine Hi, was indeed intended for the list. dmesg | grep mptsas gives nothing (no output). Hope you have an idea of what to do next. Going to test a current omnios with one hba by adding another to it to see what happens tomorrow. Will be testing with new Dell hardware and solarflare cards probably in the comming weeks also. If you are interrested, will keep you posted. Subject: Re: [OmniOS-discuss] test omnios on OI machine From: dan...@omniti.com Date: Tue, 2 Dec 2014 19:22:15 -0500 CC: dan...@omniti.com To: sim@live.nl Please share these with the community in the future, unless you're sharing confidential data of some sort. On Dec 2, 2014, at 6:59 PM, Randy S sim@live.nl wrote: Hi Dan, It's been a while... I wanted to stay on r10 since that has been in use by quite a community for quite a while now. R12 is still new so usually unforseen hicups can be expected. (We are not frontrunners regarding systems intended for serious use ;-) ). Have been testing omnios for quite a while on systems with one hba now. All was satisfactory. forgot to mention, I did do an fmdump -ev and saw Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1
Re: [OmniOS-discuss] test omnios on OI machine
I'm glad you got it running ok. Helpful hint below... On Dec 3, 2014, at 2:37 AM, Randy S sim@live.nl wrote: Anybody else had problems with two or more sas hba's in an omnios system ? How was this solved? From: sim@live.nl To: omnios-discuss@lists.omniti.com Date: Wed, 3 Dec 2014 01:45:12 +0100 Subject: Re: [OmniOS-discuss] test omnios on OI machine Hi, was indeed intended for the list. dmesg | grep mptsas dmesg is brain dead. All it does is (from the script itself, /usr/bin/dmesg): /usr/bin/cat -sv `/usr/bin/ls -tr1 /var/adm/messages.? 2/dev/null` \ /var/adm/messages | /usr/bin/tail -200 to show you the last 200 lines in the messages file. For a large system, there can easily be 1000+ lines of boot-time messages. You're better off looking at the messages file directly: grep mptsas /var/adm/messages For a better method of identifying loaded drivers, use prtconf: prtconf -D shows the device tree and the attached drivers. HTH -- richard gives nothing (no output). Hope you have an idea of what to do next. Going to test a current omnios with one hba by adding another to it to see what happens tomorrow. Will be testing with new Dell hardware and solarflare cards probably in the comming weeks also. If you are interrested, will keep you posted. Subject: Re: [OmniOS-discuss] test omnios on OI machine From: dan...@omniti.com Date: Tue, 2 Dec 2014 19:22:15 -0500 CC: dan...@omniti.com To: sim@live.nl Please share these with the community in the future, unless you're sharing confidential data of some sort. On Dec 2, 2014, at 6:59 PM, Randy S sim@live.nl wrote: Hi Dan, It's been a while... I wanted to stay on r10 since that has been in use by quite a community for quite a while now. R12 is still new so usually unforseen hicups can be expected. (We are not frontrunners regarding systems intended for serious use ;-) ). Have been testing omnios for quite a while on systems with one hba now. All was satisfactory. forgot to mention, I did do an fmdump -ev and saw Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:35:17.6783 ereport.sensor.failure 0x02cd95a4cde05801 Dec 02 23:35:17.6868 ereport.sensor.failure 0x02cd9dbb53605801 I guess this is because the one controller cannot be found. That's a fair assessment. dmesg | grep mpt_sa (done just now (not sleepy yet)) gives : Dec 3 00:42:44 omni scsi: [ID 583861 kern.info] sd68 at mpt_sas3: unit-address w5000c50057ad9161,0: w5000c50057ad9161,0 Dec 3 00:42:44 omni scsi: [ID 583861 kern.info] sd69 at mpt_sas3: unit-address w5000c50057adb269,0: w5000c50057adb269,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] sd70 at mpt_sas3: unit-address w5000c50057adea91,0: w5000c50057adea91,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] ses2 at mpt_sas3: unit-address w5003048000b18d3d,0: w5003048000b18d3d,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] mpt_sas4 at mpt_sas0: scsi-iport 20 Dec 3 00:42:45 omni genunix: [ID 936769 kern.info] mpt_sas4 is /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@20 Dec 3 00:42:45 omni genunix: [ID 408114 kern.info] /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@20 (mpt_sas4) online Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] sd71 at mpt_sas4: unit-address w5001517bb27f79f7,0: w5001517bb27f79f7,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] mpt_sas5 at mpt_sas0: scsi-iport v0 Dec 3 00:42:45 omni genunix: [ID 936769 kern.info] mpt_sas5 is /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@v0 Dec 3 00:42:45 omni genunix: [ID 408114 kern.info] /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@v0 (mpt_sas5) online Interesting... note that two mpt_sas controllers (4 and 5) came online. I wonder why one isn't showing up? Grep for mptsas as well, just in case? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] test omnios on OI machine
Thank you very much for the hint, indeed helpful. Subject: Re: [OmniOS-discuss] test omnios on OI machine From: richard.ell...@richardelling.com Date: Wed, 3 Dec 2014 08:58:43 -0800 CC: omnios-discuss@lists.omniti.com To: sim@live.nl I'm glad you got it running ok. Helpful hint below... On Dec 3, 2014, at 2:37 AM, Randy S sim@live.nl wrote: Anybody else had problems with two or more sas hba's in an omnios system ? How was this solved? From: sim@live.nl To: omnios-discuss@lists.omniti.com Date: Wed, 3 Dec 2014 01:45:12 +0100 Subject: Re: [OmniOS-discuss] test omnios on OI machine Hi, was indeed intended for the list. dmesg | grep mptsas dmesg is brain dead. All it does is (from the script itself, /usr/bin/dmesg): /usr/bin/cat -sv `/usr/bin/ls -tr1 /var/adm/messages.? 2/dev/null` \ /var/adm/messages | /usr/bin/tail -200 to show you the last 200 lines in the messages file. For a large system, there can easily be 1000+ lines of boot-time messages. You're better off looking at the messagesfile directly: grep mptsas /var/adm/messages For a better method of identifying loaded drivers, use prtconf: prtconf -Dshows the device tree and the attached drivers. HTH -- richard gives nothing (no output). Hope you have an idea of what to do next. Going to test a current omnios with one hba by adding another to it to see what happens tomorrow. Will be testing with new Dell hardware and solarflare cards probably in the comming weeks also. If you are interrested, will keep you posted. Subject: Re: [OmniOS-discuss] test omnios on OI machine From: dan...@omniti.com Date: Tue, 2 Dec 2014 19:22:15 -0500 CC: dan...@omniti.com To: sim@live.nl Please share these with the community in the future, unless you're sharing confidential data of some sort. On Dec 2, 2014, at 6:59 PM, Randy S sim@live.nl wrote: Hi Dan, It's been a while... I wanted to stay on r10 since that has been in use by quite a community for quite a while now. R12 is still new so usually unforseen hicups can be expected. (We are not frontrunners regarding systems intended for serious use ;-) ). Have been testing omnios for quite a while on systems with one hba now. All was satisfactory. forgot to mention, I did do an fmdump -ev and saw Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:35:17.6783 ereport.sensor.failure 0x02cd95a4cde05801 Dec 02 23:35:17.6868 ereport.sensor.failure 0x02cd9dbb53605801 I guess this is because the one controller cannot be found. That's a fair assessment. dmesg | grep mpt_sa (done just now (not sleepy yet)) gives : Dec 3 00:42:44 omni scsi: [ID 583861 kern.info] sd68 at mpt_sas3: unit-address w5000c50057ad9161,0: w5000c50057ad9161,0 Dec 3 00:42:44 omni scsi: [ID 583861 kern.info] sd69 at mpt_sas3: unit-address w5000c50057adb269,0: w5000c50057adb269,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] sd70 at mpt_sas3: unit-address w5000c50057adea91,0: w5000c50057adea91,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] ses2 at mpt_sas3: unit-address w5003048000b18d3d,0: w5003048000b18d3d,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] mpt_sas4 at mpt_sas0: scsi-iport 20 Dec 3 00:42:45 omni genunix: [ID 936769 kern.info] mpt_sas4 is /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@20 Dec 3 00:42:45 omni genunix: [ID 408114 kern.info] /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@20 (mpt_sas4) online Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] sd71 at mpt_sas4: unit-address w5001517bb27f79f7,0: w5001517bb27f79f7,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] mpt_sas5 at mpt_sas0: scsi-iport v0 Dec 3 00:42:45 omni genunix: [ID 936769 kern.info] mpt_sas5 is /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@v0 Dec 3 00:42:45 omni genunix: [ID 408114 kern.info] /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@v0 (mpt_sas5) online Interesting... note that two mpt_sas controllers (4 and 5) came online. I wonder why one isn't showing up? Grep for mptsas as well, just in case? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] test omnios on OI machine
Sorry should have send this to the list. Subject: RE: [OmniOS-discuss] test omnios on OI machine Date: Wed, 3 Dec 2014 00:59:33 +0100 Hi Dan, It's been a while... I wanted to stay on r10 since that has been in use by quite a community for quite a while now. R12 is still new so usually unforseen hicups can be expected. (We are not frontrunners regarding systems intended for serious use ;-) ). Have been testing omnios for quite a while on systems with one hba now. All was satisfactory. forgot to mention, I did do an fmdump -ev and saw Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:35:17.6783 ereport.sensor.failure0x02cd95a4cde05801 Dec 02 23:35:17.6868 ereport.sensor.failure0x02cd9dbb53605801 I guess this is because the one controller cannot be found. dmesg | grep mpt_sa (done just now (not sleepy yet)) gives : Dec 3 00:42:44 omni scsi: [ID 583861 kern.info] sd68 at mpt_sas3: unit-address w5000c50057ad9161,0: w5000c50057ad9161,0 Dec 3 00:42:44 omni scsi: [ID 583861 kern.info] sd69 at mpt_sas3: unit-address w5000c50057adb269,0: w5000c50057adb269,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] sd70 at mpt_sas3: unit-address w5000c50057adea91,0: w5000c50057adea91,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] ses2 at mpt_sas3: unit-address w5003048000b18d3d,0: w5003048000b18d3d,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] mpt_sas4 at mpt_sas0: scsi-iport 20 Dec 3 00:42:45 omni genunix: [ID 936769 kern.info] mpt_sas4 is /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@20 Dec 3 00:42:45 omni genunix: [ID 408114 kern.info] /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@20 (mpt_sas4) online Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] sd71 at mpt_sas4: unit-address w5001517bb27f79f7,0: w5001517bb27f79f7,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] mpt_sas5 at mpt_sas0: scsi-iport v0 Dec 3 00:42:45 omni genunix: [ID 936769 kern.info] mpt_sas5 is /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@v0 Dec 3 00:42:45 omni genunix: [ID 408114 kern.info] /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@v0 (mpt_sas5) online Thanks, R Subject: Re: [OmniOS-discuss] test omnios on OI machine From: dan...@omniti.com Date: Tue, 2 Dec 2014 18:35:42 -0500 CC: omnios-discuss@lists.omniti.com To: sim@live.nl On Dec 2, 2014, at 6:17 PM, Randy S sim@live.nl wrote: Hi, I have an OI 7 machine running for quite a while now and installed Omnios r10 into a boot env to see how it behaves on the same hardware. Try upgrading r10 to r12 and see if the same thing happens please. Next, utter dmesg | grep mpt_sas to see if there are any complaints from the kernel. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] test omnios on OI machine
Hi, was indeed intended for the list. dmesg | grep mptsas gives nothing (no output). Hope you have an idea of what to do next. Going to test a current omnios with one hba by adding another to it to see what happens tomorrow. Will be testing with new Dell hardware and solarflare cards probably in the comming weeks also. If you are interrested, will keep you posted. Subject: Re: [OmniOS-discuss] test omnios on OI machine From: dan...@omniti.com Date: Tue, 2 Dec 2014 19:22:15 -0500 CC: dan...@omniti.com To: sim@live.nl Please share these with the community in the future, unless you're sharing confidential data of some sort. On Dec 2, 2014, at 6:59 PM, Randy S sim@live.nl wrote: Hi Dan, It's been a while... I wanted to stay on r10 since that has been in use by quite a community for quite a while now. R12 is still new so usually unforseen hicups can be expected. (We are not frontrunners regarding systems intended for serious use ;-) ). Have been testing omnios for quite a while on systems with one hba now. All was satisfactory. forgot to mention, I did do an fmdump -ev and saw Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:32:37.1675 ereport.fs.zfs.vdev.open_failed 0x0077a03af6b1 Dec 02 23:35:17.6783 ereport.sensor.failure 0x02cd95a4cde05801 Dec 02 23:35:17.6868 ereport.sensor.failure 0x02cd9dbb53605801 I guess this is because the one controller cannot be found. That's a fair assessment. dmesg | grep mpt_sa (done just now (not sleepy yet)) gives : Dec 3 00:42:44 omni scsi: [ID 583861 kern.info] sd68 at mpt_sas3: unit-address w5000c50057ad9161,0: w5000c50057ad9161,0 Dec 3 00:42:44 omni scsi: [ID 583861 kern.info] sd69 at mpt_sas3: unit-address w5000c50057adb269,0: w5000c50057adb269,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] sd70 at mpt_sas3: unit-address w5000c50057adea91,0: w5000c50057adea91,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] ses2 at mpt_sas3: unit-address w5003048000b18d3d,0: w5003048000b18d3d,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] mpt_sas4 at mpt_sas0: scsi-iport 20 Dec 3 00:42:45 omni genunix: [ID 936769 kern.info] mpt_sas4 is /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@20 Dec 3 00:42:45 omni genunix: [ID 408114 kern.info] /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@20 (mpt_sas4) online Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] sd71 at mpt_sas4: unit-address w5001517bb27f79f7,0: w5001517bb27f79f7,0 Dec 3 00:42:45 omni scsi: [ID 583861 kern.info] mpt_sas5 at mpt_sas0: scsi-iport v0 Dec 3 00:42:45 omni genunix: [ID 936769 kern.info] mpt_sas5 is /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@v0 Dec 3 00:42:45 omni genunix: [ID 408114 kern.info] /pci@0,0/pci8086,3c04@2/pci1000,3030@0/iport@v0 (mpt_sas5) online Interesting... note that two mpt_sas controllers (4 and 5) came online. I wonder why one isn't showing up? Grep for mptsas as well, just in case? Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
