[OmniOS-discuss] Ang: Re: Ang: Re: r151014 KVM crash
Jorge, I thought you would jump in on this thread!
Are you asking me or Michael?
I'm not running ivy bridge on this machine, it's an older westmere...
Yeah, I pass --cpu=host
Can you provide your config file, pls?
Mine is like this:
root@omni2:/usr/bin# cat vmedu14041.sh
#!/usr/bin/bash
# on omnios command is /usr/bin/qemu-system-x86_64
# configuration
NAME=EDU14041
NUM=4
VNIC0=ltsp0
VNIC1=ltsp1
VNIC2=ltsptl0
HDD0=/dev/zvol/rdsk/mainpool/vm/edu/os
HDD1=/dev/zvol/rdsk/mainpool/vm/edu/opt
CD=/mainpool/iso/edu14041.iso
HDD2=/dev/zvol/rdsk/mainpool/vm/edu/home
HDD3=/dev/zvol/rdsk/mainpool/vm/edu/swap
MEM=8192
# don't change below here!
TLN=`expr 7000 + $NUM`
mac0=`dladm show-vnic -po macaddress $VNIC0`
mac1=`dladm show-vnic -po macaddress $VNIC1`
mac2=`dladm show-vnic -po macaddress $VNIC2`
/usr/bin/qemu-system-x86_64 \
-name $NAME \
-boot cd \
-enable-kvm \
-vnc 0.0.0.0:$NUM \
-smp cores=2,threads=2 \
-m $MEM \
-no-hpet \
-localtime \
-drive file=$HDD0,if=virtio,index=0 \
-drive file=$HDD1,if=virtio,index=2 \
-drive file=$CD,media=cdrom,if=ide,index=1 \
-drive file=$HDD2,if=virtio,index=3 \
-drive file=$HDD3,if=virtio,index=4 \
-net nic,vlan=0,name=net0,model=virtio,macaddr=$mac0 \
-net vnic,vlan=0,name=net0,ifname=$VNIC0,macaddr=$mac0 \
-net nic,vlan=1,name=net1,model=virtio,macaddr=$mac1 \
-net vnic,vlan=1,name=net1,ifname=$VNIC1,macaddr=$mac1 \
-net nic,vlan=2,name=net2,model=virtio,macaddr=$mac2 \
-net vnic,vlan=2,name=net2,ifname=$VNIC2,macaddr=$mac2 \
-vga std \
-cpu host \
-pidfile /mainpool/vm/edu/pids/$NAME.pid \
-monitor telnet:localhost:$TLN,server,nowait,nodelay \
-daemonize
if [ $? -gt 0 ]; then
echo Failed to start VM
exit
fi
port=`expr 5900 + $NUM`
public_nic=$(dladm show-vnic|grep vnic0|awk '{print $2}')
public_ip=$(ifconfig $public_nic|grep inet|awk '{print $2}')
echo Started VM: $NAME
echo VNC available at: host IP ${public_ip} port ${port}
echo QEMU Monitor, do: # telnet localhost $TLN. Note: use Control ] to exit
monitor before quit!
Rgrds Johan
-OmniOS-discuss omnios-discuss-boun...@lists.omniti.com skrev: -
Till: Michael Rasmussen m...@miras.org
Från: Jorge Schrauwen
Sänt av: OmniOS-discuss
Datum: 2015-04-06 19:06
Kopia: omnios-discuss@lists.omniti.com
Ärende: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash
Out of curiosity, are you passing --cpu=host? I had issues with that on
my ivy bridge.
I currently use: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 which seems to make
a lot of things smoother.
I stil get these but qemu does not crash for me:
Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info]
kvm_lapic_reset: vcpu=ff21ff94c000, id=0, base_msr= fee00100 PRIx64
base_address=fee0
Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs
revision_id = 10
Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info]
kvm_lapic_reset: vcpu=ff21ff944000, id=1, base_msr= fee0 PRIx64
base_address=fee0
Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs
revision_id = 10
Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info]
kvm_lapic_reset: vcpu=ff21ff93c000, id=2, base_msr= fee0 PRIx64
base_address=fee0
Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs
revision_id = 10
Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info]
kvm_lapic_reset: vcpu=ff2201f14000, id=3, base_msr= fee0 PRIx64
base_address=fee0
Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs
revision_id = 10
Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info]
kvm_lapic_reset: vcpu=ff2201f0c000, id=4, base_msr= fee0 PRIx64
base_address=fee0
Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs
revision_id = 10
Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info]
kvm_lapic_reset: vcpu=ff2201f04000, id=5, base_msr= fee0 PRIx64
base_address=fee0
Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs
revision_id = 10
Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info]
kvm_lapic_reset: vcpu=ff2201efc000, id=6, base_msr= fee0 PRIx64
base_address=fee0
Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs
revision_id = 10
Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info]
kvm_lapic_reset: vcpu=ff2201f54000, id=7, base_msr= fee0 PRIx64
base_address=fee0
Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs
revision_id = 10
Regards
Jorge
On 2015-04-06 18:03, Michael Rasmussen wrote:
On Mon, 6 Apr 2015 11:55:27 -0400
Dan McDonald dan...@omniti.com wrote:
I'm talking with the illumos KVM folks. They mentioned that Ivy
Bridge Xeons (i.e. Xeon E5-26xx v2, where v2 means Ivy Bridge) have
erratum that can cause problems. That you do not seem to see these in
r151012, however, is very odd.
There is also E3-12xx v2 which is Ivy Bridge based. Are these affected
by this erratum as well?
___
OmniOS-discuss
Re: [OmniOS-discuss] Ang: Re: Ang: Re: r151014 KVM crash
On 2015-04-06 19:55, Michael Rasmussen wrote: On Mon, 6 Apr 2015 19:22:08 +0200 Johan Kragsterman johan.kragster...@capvert.se wrote: -smp cores=2,threads=2 \ I would use: cores=1,threads=4 Notable exception is for illumos, it barfs on that and dies. But yeah for other OS's that valid advice. instead since smp tense to give problems if VM OS is having problems with smp. 99% of the time cores=1,threads=x performs smoother and better than cores=x,threads=y and without proper numa implementation using cores 1 does not add anything to the picture. smp is first interesting in qemu-2.2 when numa is introduced. ___ 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] New MB
On Mon, 6 Apr 2015 13:23:28 -0400 Eric Sproul eric.spr...@circonus.com wrote: Modulo actually being able to mount the weird form-factor in a standard case (note that you need enough of the mounting holes to line up, not just that the dimensions fit!), I would expect OmniOS to work. This is my biggest concern since drilling hules in motherboards is not for the faint of heart;-) I think before making the final decision I will make an inquiry to the local Supermicro dealer. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael at rasmussen dot cc http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD3C9A00E mir at datanom dot net http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE501F51C mir at miras dot org http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE3E80917 -- /usr/games/fortune -es says: A classic is something that everyone wants to have read and nobody wants to read. -- Mark Twain, The Disappearance of Literature pgp0bKhi6ZYAK.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Ang: Re: Ang: Re: Ang: Re: r151014 KVM crash
Nope :)
https://github.com/hadfl/kvmadm/
Regards
Jorge
On 2015-04-06 19:42, Johan Kragsterman wrote:
Thnks, Jorge!
Yeah, I'm the one with the problems...
So you're using kvmadm...? Is that from smartOS, huh? How did you
manage to get it to work on OmniOS?
Rgrds Johan
-Jorge Schrauwen sjorge...@blackdot.be skrev: -
Till: Johan Kragsterman johan.kragster...@capvert.se
Från: Jorge Schrauwen sjorge...@blackdot.be
Datum: 2015-04-06 19:25
Kopia: Michael Rasmussen m...@miras.org,
omnios-discuss@lists.omniti.com
Ärende: Re: Ang: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash
Who ever is having the problem :)
It was a bit hard to follow, I'm using kvmadm and this is my config:
{
cosmos : {
nics : [
{
index : 0,
nic_name : vcosmos0,
model : virtio,
vlan_id : 10
},
{
index : 1,
nic_name : vcosmos1,
model : virtio
}
],
cpu_type : qemu64,+aes,+sse4.2,+sse4.1,+ssse3,
hpet : true,
usb_tablet : true,
disks : [
{
index : 0,
boot : true,
disk_path : main/vms/hosts/cosmos/disk0,
model : virtio
}
],
shutdown : acpi_kill,
boot_order : cd,
vcpus : sockets=1,cores=4,threads=2,
serials : [
{
index : 0,
serial_name : console
}
],
cleanup : true,
ram : 6144,
time_base : utc
}
}
Which turns into:
-(~)-[!]-{ pfexec pargs 616
}-(sjorge@core)-
616: /usr/bin/qemu-system-x86_64 -name cosmos -enable-kvm -m 6144
-cpu qemu64,+aes,+
argv[0]: /usr/bin/qemu-system-x86_64
argv[1]: -name
argv[2]: cosmos
argv[3]: -enable-kvm
argv[4]: -m
argv[5]: 6144
argv[6]: -cpu
argv[7]: qemu64,+aes,+sse4.2,+sse4.1,+ssse3
argv[8]: -smp
argv[9]: sockets=1,cores=4,threads=2
argv[10]: -rtc
argv[11]: base=utc,driftfix=slew
argv[12]: -pidfile
argv[13]: /var/run/kvm/cosmos.pid
argv[14]: -monitor
argv[15]: unix:/var/run/kvm/cosmos.monitor,server,nowait,nodelay
argv[16]: -vga
argv[17]: none
argv[18]: -nographic
argv[19]: -drive
argv[20]:
file=/dev/zvol/rdsk/main/vms/hosts/cosmos/disk0,if=virtio,media=disk,index=0,cache=none,boot=on
argv[21]: -boot
argv[22]: order=cd
argv[23]: -device
argv[24]:
virtio-net-pci,mac=02:08:20:f5:95:f4,tx=timer,x-txtimer=20,x-txburst=128,vlan=10
argv[25]: -net
argv[26]: vnic,vlan=10,name=net0,ifname=vcosmos0
argv[27]: -device
argv[28]:
virtio-net-pci,mac=02:08:20:0c:08:d2,tx=timer,x-txtimer=20,x-txburst=128,vlan=0
argv[29]: -net
argv[30]: vnic,vlan=0,name=net1,ifname=vcosmos1
argv[31]: -chardev
argv[32]:
socket,id=serial0,path=/var/run/kvm/cosmos.console,server,nowait
argv[33]: -serial
argv[34]: chardev:serial0
argv[35]: -usb
argv[36]: -usbdevice
argv[37]: tablet
argv[38]: -daemonize
PS: shout out to dan for introducing me to pgrep and pargs!
Regards
Jorge
On 2015-04-06 19:22, Johan Kragsterman wrote:
Jorge, I thought you would jump in on this thread!
Are you asking me or Michael?
I'm not running ivy bridge on this machine, it's an older westmere...
Yeah, I pass --cpu=host
Can you provide your config file, pls?
Mine is like this:
root@omni2:/usr/bin# cat vmedu14041.sh
#!/usr/bin/bash
# on omnios command is /usr/bin/qemu-system-x86_64
# configuration
NAME=EDU14041
NUM=4
VNIC0=ltsp0
VNIC1=ltsp1
VNIC2=ltsptl0
HDD0=/dev/zvol/rdsk/mainpool/vm/edu/os
HDD1=/dev/zvol/rdsk/mainpool/vm/edu/opt
CD=/mainpool/iso/edu14041.iso
HDD2=/dev/zvol/rdsk/mainpool/vm/edu/home
HDD3=/dev/zvol/rdsk/mainpool/vm/edu/swap
MEM=8192
# don't change below here!
TLN=`expr 7000 + $NUM`
mac0=`dladm show-vnic -po macaddress $VNIC0`
mac1=`dladm show-vnic -po macaddress $VNIC1`
mac2=`dladm show-vnic -po macaddress $VNIC2`
/usr/bin/qemu-system-x86_64 \
-name $NAME \
-boot cd \
-enable-kvm \
-vnc 0.0.0.0:$NUM \
-smp cores=2,threads=2 \
-m $MEM \
-no-hpet \
-localtime \
-drive file=$HDD0,if=virtio,index=0 \
-drive file=$HDD1,if=virtio,index=2 \
-drive file=$CD,media=cdrom,if=ide,index=1 \
-drive file=$HDD2,if=virtio,index=3 \
-drive file=$HDD3,if=virtio,index=4 \
-net nic,vlan=0,name=net0,model=virtio,macaddr=$mac0 \
-net vnic,vlan=0,name=net0,ifname=$VNIC0,macaddr=$mac0 \
-net nic,vlan=1,name=net1,model=virtio,macaddr=$mac1 \
-net vnic,vlan=1,name=net1,ifname=$VNIC1,macaddr=$mac1 \
-net nic,vlan=2,name=net2,model=virtio,macaddr=$mac2 \
-net vnic,vlan=2,name=net2,ifname=$VNIC2,macaddr=$mac2 \
-vga std \
-cpu host \
-pidfile /mainpool/vm/edu/pids/$NAME.pid \
-monitor telnet:localhost:$TLN,server,nowait,nodelay \
-daemonize
if [ $? -gt 0 ]; then
echo Failed to start VM
exit
fi
port=`expr 5900 + $NUM`
public_nic=$(dladm show-vnic|grep vnic0|awk '{print $2}')
public_ip=$(ifconfig $public_nic|grep inet|awk '{print $2}')
echo Started VM: $NAME
echo VNC available at: host IP ${public_ip} port ${port}
echo QEMU Monitor, do: # telnet
Re: [OmniOS-discuss] Ang: Re: Ang: Re: r151014 KVM crash
On Mon, 6 Apr 2015 19:22:08 +0200 Johan Kragsterman johan.kragster...@capvert.se wrote: -smp cores=2,threads=2 \ I would use: cores=1,threads=4 instead since smp tense to give problems if VM OS is having problems with smp. 99% of the time cores=1,threads=x performs smoother and better than cores=x,threads=y and without proper numa implementation using cores 1 does not add anything to the picture. smp is first interesting in qemu-2.2 when numa is introduced. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael at rasmussen dot cc http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD3C9A00E mir at datanom dot net http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE501F51C mir at miras dot org http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE3E80917 -- /usr/games/fortune -es says: You work very hard. Don't try to think as well. pgp0ne4sIiEyR.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Ang: Re: Ang: Re: Ang: Re: Ang: Re: r151014 KVM crash
Yep I find it useful.
Cons, euhm none come to mind actually. The developer is pretty good with
feedback and input so all the cons there were are now gone due to me
excessive bug opening haha.
Pros:
- json structure for configuring vm's
- No messing around with custom scripts and smf wrappers
Regards
Jorge
On 2015-04-06 19:50, Johan Kragsterman wrote:
Ahh, that one!
Thanks again! I'll have a look at it! Since you use it, I guess you
find it useful?
Any pro's and con's as you see it?
Rgrds Johan
-Jorge Schrauwen sjorge...@blackdot.be skrev: -
Till: Johan Kragsterman johan.kragster...@capvert.se
Från: Jorge Schrauwen sjorge...@blackdot.be
Datum: 2015-04-06 19:44
Kopia: Michael Rasmussen m...@miras.org,
omnios-discuss@lists.omniti.com
Ärende: Re: Ang: Re: Ang: Re: [OmniOS-discuss] Ang: Re: r151014 KVM
crash
Nope :)
https://github.com/hadfl/kvmadm/
Regards
Jorge
On 2015-04-06 19:42, Johan Kragsterman wrote:
Thnks, Jorge!
Yeah, I'm the one with the problems...
So you're using kvmadm...? Is that from smartOS, huh? How did you
manage to get it to work on OmniOS?
Rgrds Johan
-Jorge Schrauwen sjorge...@blackdot.be skrev: -
Till: Johan Kragsterman johan.kragster...@capvert.se
Från: Jorge Schrauwen sjorge...@blackdot.be
Datum: 2015-04-06 19:25
Kopia: Michael Rasmussen m...@miras.org,
omnios-discuss@lists.omniti.com
Ärende: Re: Ang: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash
Who ever is having the problem :)
It was a bit hard to follow, I'm using kvmadm and this is my config:
{
cosmos : {
nics : [
{
index : 0,
nic_name : vcosmos0,
model : virtio,
vlan_id : 10
},
{
index : 1,
nic_name : vcosmos1,
model : virtio
}
],
cpu_type : qemu64,+aes,+sse4.2,+sse4.1,+ssse3,
hpet : true,
usb_tablet : true,
disks : [
{
index : 0,
boot : true,
disk_path : main/vms/hosts/cosmos/disk0,
model : virtio
}
],
shutdown : acpi_kill,
boot_order : cd,
vcpus : sockets=1,cores=4,threads=2,
serials : [
{
index : 0,
serial_name : console
}
],
cleanup : true,
ram : 6144,
time_base : utc
}
}
Which turns into:
-(~)-[!]-{ pfexec pargs 616
}-(sjorge@core)-
616: /usr/bin/qemu-system-x86_64 -name cosmos -enable-kvm -m 6144
-cpu qemu64,+aes,+
argv[0]: /usr/bin/qemu-system-x86_64
argv[1]: -name
argv[2]: cosmos
argv[3]: -enable-kvm
argv[4]: -m
argv[5]: 6144
argv[6]: -cpu
argv[7]: qemu64,+aes,+sse4.2,+sse4.1,+ssse3
argv[8]: -smp
argv[9]: sockets=1,cores=4,threads=2
argv[10]: -rtc
argv[11]: base=utc,driftfix=slew
argv[12]: -pidfile
argv[13]: /var/run/kvm/cosmos.pid
argv[14]: -monitor
argv[15]: unix:/var/run/kvm/cosmos.monitor,server,nowait,nodelay
argv[16]: -vga
argv[17]: none
argv[18]: -nographic
argv[19]: -drive
argv[20]:
file=/dev/zvol/rdsk/main/vms/hosts/cosmos/disk0,if=virtio,media=disk,index=0,cache=none,boot=on
argv[21]: -boot
argv[22]: order=cd
argv[23]: -device
argv[24]:
virtio-net-pci,mac=02:08:20:f5:95:f4,tx=timer,x-txtimer=20,x-txburst=128,vlan=10
argv[25]: -net
argv[26]: vnic,vlan=10,name=net0,ifname=vcosmos0
argv[27]: -device
argv[28]:
virtio-net-pci,mac=02:08:20:0c:08:d2,tx=timer,x-txtimer=20,x-txburst=128,vlan=0
argv[29]: -net
argv[30]: vnic,vlan=0,name=net1,ifname=vcosmos1
argv[31]: -chardev
argv[32]:
socket,id=serial0,path=/var/run/kvm/cosmos.console,server,nowait
argv[33]: -serial
argv[34]: chardev:serial0
argv[35]: -usb
argv[36]: -usbdevice
argv[37]: tablet
argv[38]: -daemonize
PS: shout out to dan for introducing me to pgrep and pargs!
Regards
Jorge
On 2015-04-06 19:22, Johan Kragsterman wrote:
Jorge, I thought you would jump in on this thread!
Are you asking me or Michael?
I'm not running ivy bridge on this machine, it's an older westmere...
Yeah, I pass --cpu=host
Can you provide your config file, pls?
Mine is like this:
root@omni2:/usr/bin# cat vmedu14041.sh
#!/usr/bin/bash
# on omnios command is /usr/bin/qemu-system-x86_64
# configuration
NAME=EDU14041
NUM=4
VNIC0=ltsp0
VNIC1=ltsp1
VNIC2=ltsptl0
HDD0=/dev/zvol/rdsk/mainpool/vm/edu/os
HDD1=/dev/zvol/rdsk/mainpool/vm/edu/opt
CD=/mainpool/iso/edu14041.iso
HDD2=/dev/zvol/rdsk/mainpool/vm/edu/home
HDD3=/dev/zvol/rdsk/mainpool/vm/edu/swap
MEM=8192
# don't change below here!
TLN=`expr 7000 + $NUM`
mac0=`dladm show-vnic -po macaddress $VNIC0`
mac1=`dladm show-vnic -po macaddress $VNIC1`
mac2=`dladm show-vnic -po macaddress $VNIC2`
/usr/bin/qemu-system-x86_64 \
-name $NAME \
-boot cd \
-enable-kvm \
-vnc 0.0.0.0:$NUM \
-smp cores=2,threads=2 \
-m $MEM \
-no-hpet \
-localtime \
-drive file=$HDD0,if=virtio,index=0 \
-drive file=$HDD1,if=virtio,index=2 \
-drive file=$CD,media=cdrom,if=ide,index=1 \
-drive
Re: [OmniOS-discuss] Ang: Re: Ang: Re: r151014 KVM crash
Who ever is having the problem :)
It was a bit hard to follow, I'm using kvmadm and this is my config:
{
cosmos : {
nics : [
{
index : 0,
nic_name : vcosmos0,
model : virtio,
vlan_id : 10
},
{
index : 1,
nic_name : vcosmos1,
model : virtio
}
],
cpu_type : qemu64,+aes,+sse4.2,+sse4.1,+ssse3,
hpet : true,
usb_tablet : true,
disks : [
{
index : 0,
boot : true,
disk_path : main/vms/hosts/cosmos/disk0,
model : virtio
}
],
shutdown : acpi_kill,
boot_order : cd,
vcpus : sockets=1,cores=4,threads=2,
serials : [
{
index : 0,
serial_name : console
}
],
cleanup : true,
ram : 6144,
time_base : utc
}
}
Which turns into:
-(~)-[!]-{ pfexec pargs 616
}-(sjorge@core)-
616:/usr/bin/qemu-system-x86_64 -name cosmos -enable-kvm -m 6144
-cpu qemu64,+aes,+
argv[0]: /usr/bin/qemu-system-x86_64
argv[1]: -name
argv[2]: cosmos
argv[3]: -enable-kvm
argv[4]: -m
argv[5]: 6144
argv[6]: -cpu
argv[7]: qemu64,+aes,+sse4.2,+sse4.1,+ssse3
argv[8]: -smp
argv[9]: sockets=1,cores=4,threads=2
argv[10]: -rtc
argv[11]: base=utc,driftfix=slew
argv[12]: -pidfile
argv[13]: /var/run/kvm/cosmos.pid
argv[14]: -monitor
argv[15]: unix:/var/run/kvm/cosmos.monitor,server,nowait,nodelay
argv[16]: -vga
argv[17]: none
argv[18]: -nographic
argv[19]: -drive
argv[20]:
file=/dev/zvol/rdsk/main/vms/hosts/cosmos/disk0,if=virtio,media=disk,index=0,cache=none,boot=on
argv[21]: -boot
argv[22]: order=cd
argv[23]: -device
argv[24]:
virtio-net-pci,mac=02:08:20:f5:95:f4,tx=timer,x-txtimer=20,x-txburst=128,vlan=10
argv[25]: -net
argv[26]: vnic,vlan=10,name=net0,ifname=vcosmos0
argv[27]: -device
argv[28]:
virtio-net-pci,mac=02:08:20:0c:08:d2,tx=timer,x-txtimer=20,x-txburst=128,vlan=0
argv[29]: -net
argv[30]: vnic,vlan=0,name=net1,ifname=vcosmos1
argv[31]: -chardev
argv[32]:
socket,id=serial0,path=/var/run/kvm/cosmos.console,server,nowait
argv[33]: -serial
argv[34]: chardev:serial0
argv[35]: -usb
argv[36]: -usbdevice
argv[37]: tablet
argv[38]: -daemonize
PS: shout out to dan for introducing me to pgrep and pargs!
Regards
Jorge
On 2015-04-06 19:22, Johan Kragsterman wrote:
Jorge, I thought you would jump in on this thread!
Are you asking me or Michael?
I'm not running ivy bridge on this machine, it's an older westmere...
Yeah, I pass --cpu=host
Can you provide your config file, pls?
Mine is like this:
root@omni2:/usr/bin# cat vmedu14041.sh
#!/usr/bin/bash
# on omnios command is /usr/bin/qemu-system-x86_64
# configuration
NAME=EDU14041
NUM=4
VNIC0=ltsp0
VNIC1=ltsp1
VNIC2=ltsptl0
HDD0=/dev/zvol/rdsk/mainpool/vm/edu/os
HDD1=/dev/zvol/rdsk/mainpool/vm/edu/opt
CD=/mainpool/iso/edu14041.iso
HDD2=/dev/zvol/rdsk/mainpool/vm/edu/home
HDD3=/dev/zvol/rdsk/mainpool/vm/edu/swap
MEM=8192
# don't change below here!
TLN=`expr 7000 + $NUM`
mac0=`dladm show-vnic -po macaddress $VNIC0`
mac1=`dladm show-vnic -po macaddress $VNIC1`
mac2=`dladm show-vnic -po macaddress $VNIC2`
/usr/bin/qemu-system-x86_64 \
-name $NAME \
-boot cd \
-enable-kvm \
-vnc 0.0.0.0:$NUM \
-smp cores=2,threads=2 \
-m $MEM \
-no-hpet \
-localtime \
-drive file=$HDD0,if=virtio,index=0 \
-drive file=$HDD1,if=virtio,index=2 \
-drive file=$CD,media=cdrom,if=ide,index=1 \
-drive file=$HDD2,if=virtio,index=3 \
-drive file=$HDD3,if=virtio,index=4 \
-net nic,vlan=0,name=net0,model=virtio,macaddr=$mac0 \
-net vnic,vlan=0,name=net0,ifname=$VNIC0,macaddr=$mac0 \
-net nic,vlan=1,name=net1,model=virtio,macaddr=$mac1 \
-net vnic,vlan=1,name=net1,ifname=$VNIC1,macaddr=$mac1 \
-net nic,vlan=2,name=net2,model=virtio,macaddr=$mac2 \
-net vnic,vlan=2,name=net2,ifname=$VNIC2,macaddr=$mac2 \
-vga std \
-cpu host \
-pidfile /mainpool/vm/edu/pids/$NAME.pid \
-monitor telnet:localhost:$TLN,server,nowait,nodelay \
-daemonize
if [ $? -gt 0 ]; then
echo Failed to start VM
exit
fi
port=`expr 5900 + $NUM`
public_nic=$(dladm show-vnic|grep vnic0|awk '{print $2}')
public_ip=$(ifconfig $public_nic|grep inet|awk '{print $2}')
echo Started VM: $NAME
echo VNC available at: host IP ${public_ip} port ${port}
echo QEMU Monitor, do: # telnet localhost $TLN. Note: use Control ]
to exit monitor before quit!
Rgrds Johan
-OmniOS-discuss omnios-discuss-boun...@lists.omniti.com skrev:
-
Till: Michael Rasmussen m...@miras.org
Från: Jorge Schrauwen
Sänt av: OmniOS-discuss
Datum: 2015-04-06 19:06
Kopia: omnios-discuss@lists.omniti.com
Ärende: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash
Out of curiosity, are you passing --cpu=host? I had issues with that on
my ivy bridge.
I currently use: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 which seems to make
a lot of things smoother.
I stil get these but qemu does not crash for me:
Apr 1 19:47:28
Re: [OmniOS-discuss] New MB
On Mon, Apr 6, 2015 at 2:04 PM, Michael Rasmussen m...@miras.org wrote: On Mon, 6 Apr 2015 13:23:28 -0400 Eric Sproul eric.spr...@circonus.com wrote: Modulo actually being able to mount the weird form-factor in a standard case (note that you need enough of the mounting holes to line up, not just that the dimensions fit!), I would expect OmniOS to work. This is my biggest concern since drilling hules in motherboards is not for the faint of heart;-) I think before making the final decision I will make an inquiry to the local Supermicro dealer. The manual for that board strongly suggests that users only employ this board as part of the full system 5018A-AR12L http://www.supermicro.com/products/system/1U/5018/SSG-5018A-AR12L.cfm That should tell you something. ;) ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] IPS group/feature packages in 014: What to do with them?
Hi Dan! [I guess you don't receive my mails so I am CC'ing the list.] I see that you have included some feature IPS packages in 014: # pkg list -avf group/feature/\* FMRI IFO pkg://omnios/group/feature/amp@0.5.11-0.151014:20150402T184306Z --- pkg://omnios/group/feature/developer-gnu@0.5.11-0.151014:20150402T184306Z --- pkg://omnios/group/feature/multi-user-desktop@0.5.11-0.151014:20150402T184307Z --- But they are obviously not in synch with the rest of the packages in the 014 repo. (There will not be a multi-user-desktop feature soon, I'd wager ;-). But some of them could be useful. Take feature/developer-gnu. It would be nice to just install it and have a working environment with the Gnu tools. However, it's just an upstream copy which does not map well to the OmniOS versions of the various packages: # pkg contents -rt depend -Ho fmri group/feature/developer-gnu developer/build/autoconf developer/build/automake-110 developer/build/automake-111 developer/build/automake-19 developer/build/gnu-make developer/build/libtool developer/build/make developer/debug/gdb developer/gcc-47 developer/gnu-binutils developer/lexer/flex developer/macro/gnu-m4 developer/parser/bison developer/versioning/cvs developer/versioning/git developer/versioning/mercurial developer/versioning/subversion system/header system/library/gcc-4-runtime Most of these packages do exist in the 014 repo but some have slightly different names and/or versions. An easy fix would be to just change the depends to developer/build/autoconf developer/build/automake developer/build/gnu-make developer/build/libtool developer/build/make developer/gcc48 developer/gnu-binutils developer/lexer/flex developer/macro/gnu-m4 developer/parser/bison developer/versioning/git developer/versioning/mercurial developer/versioning/subversion system/header system/library/gcc-4-runtime Missing are gdb, cvs, and subversion, if we don't include the pkgs on ms.omniti.com. Maybe gdb and SVN could even be brought over into 014 proper. :-) A similar change could be done for group/feature/amp. So what are your plans with feature pkgs? Regards -- Volker -- Volker A. Brandt Consulting and Support for Oracle Solaris Brandt Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46 Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt When logic and proportion have fallen sloppy dead ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] New MB
On Sat, Apr 4, 2015 at 11:57 AM, Michael Rasmussen m...@miras.org wrote: Hi all, I have been looking at this motherboard for a low-power storage server: http://supermicro.nl/products/motherboard/Atom/X10/A1SA7-2750F.cfm I wonder whether there should be any problems in Omnios for this board? It is packed with a LSI 2116 controller which is also used in LSISAS9200-16e and LSISAS9201-16i LSI SAS2116 is either pciex1000,64 or ,65. Both appear to be supported by mpt_sas in OmniOS 014. You should be good there. Nics is based on Intel i354. Supported in recent stable releases that contain (or got backported) https://www.illumos.org/issues/4431 1 internal SATA 3 with SATA DOM power connector which I consider use for OS. I believe the C2000 SoC SATA ports are standard AHCI and should just work. Modulo actually being able to mount the weird form-factor in a standard case (note that you need enough of the mounting holes to line up, not just that the dimensions fit!), I would expect OmniOS to work. Eric ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Ang: Re: Ang: Re: Ang: Re: r151014 KVM crash
Thnks, Jorge!
Yeah, I'm the one with the problems...
So you're using kvmadm...? Is that from smartOS, huh? How did you manage to get
it to work on OmniOS?
Rgrds Johan
-Jorge Schrauwen sjorge...@blackdot.be skrev: -
Till: Johan Kragsterman johan.kragster...@capvert.se
Från: Jorge Schrauwen sjorge...@blackdot.be
Datum: 2015-04-06 19:25
Kopia: Michael Rasmussen m...@miras.org, omnios-discuss@lists.omniti.com
Ärende: Re: Ang: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash
Who ever is having the problem :)
It was a bit hard to follow, I'm using kvmadm and this is my config:
{
cosmos : {
nics : [
{
index : 0,
nic_name : vcosmos0,
model : virtio,
vlan_id : 10
},
{
index : 1,
nic_name : vcosmos1,
model : virtio
}
],
cpu_type : qemu64,+aes,+sse4.2,+sse4.1,+ssse3,
hpet : true,
usb_tablet : true,
disks : [
{
index : 0,
boot : true,
disk_path : main/vms/hosts/cosmos/disk0,
model : virtio
}
],
shutdown : acpi_kill,
boot_order : cd,
vcpus : sockets=1,cores=4,threads=2,
serials : [
{
index : 0,
serial_name : console
}
],
cleanup : true,
ram : 6144,
time_base : utc
}
}
Which turns into:
-(~)-[!]-{ pfexec pargs 616
}-(sjorge@core)-
616: /usr/bin/qemu-system-x86_64 -name cosmos -enable-kvm -m 6144
-cpu qemu64,+aes,+
argv[0]: /usr/bin/qemu-system-x86_64
argv[1]: -name
argv[2]: cosmos
argv[3]: -enable-kvm
argv[4]: -m
argv[5]: 6144
argv[6]: -cpu
argv[7]: qemu64,+aes,+sse4.2,+sse4.1,+ssse3
argv[8]: -smp
argv[9]: sockets=1,cores=4,threads=2
argv[10]: -rtc
argv[11]: base=utc,driftfix=slew
argv[12]: -pidfile
argv[13]: /var/run/kvm/cosmos.pid
argv[14]: -monitor
argv[15]: unix:/var/run/kvm/cosmos.monitor,server,nowait,nodelay
argv[16]: -vga
argv[17]: none
argv[18]: -nographic
argv[19]: -drive
argv[20]:
file=/dev/zvol/rdsk/main/vms/hosts/cosmos/disk0,if=virtio,media=disk,index=0,cache=none,boot=on
argv[21]: -boot
argv[22]: order=cd
argv[23]: -device
argv[24]:
virtio-net-pci,mac=02:08:20:f5:95:f4,tx=timer,x-txtimer=20,x-txburst=128,vlan=10
argv[25]: -net
argv[26]: vnic,vlan=10,name=net0,ifname=vcosmos0
argv[27]: -device
argv[28]:
virtio-net-pci,mac=02:08:20:0c:08:d2,tx=timer,x-txtimer=20,x-txburst=128,vlan=0
argv[29]: -net
argv[30]: vnic,vlan=0,name=net1,ifname=vcosmos1
argv[31]: -chardev
argv[32]:
socket,id=serial0,path=/var/run/kvm/cosmos.console,server,nowait
argv[33]: -serial
argv[34]: chardev:serial0
argv[35]: -usb
argv[36]: -usbdevice
argv[37]: tablet
argv[38]: -daemonize
PS: shout out to dan for introducing me to pgrep and pargs!
Regards
Jorge
On 2015-04-06 19:22, Johan Kragsterman wrote:
Jorge, I thought you would jump in on this thread!
Are you asking me or Michael?
I'm not running ivy bridge on this machine, it's an older westmere...
Yeah, I pass --cpu=host
Can you provide your config file, pls?
Mine is like this:
root@omni2:/usr/bin# cat vmedu14041.sh
#!/usr/bin/bash
# on omnios command is /usr/bin/qemu-system-x86_64
# configuration
NAME=EDU14041
NUM=4
VNIC0=ltsp0
VNIC1=ltsp1
VNIC2=ltsptl0
HDD0=/dev/zvol/rdsk/mainpool/vm/edu/os
HDD1=/dev/zvol/rdsk/mainpool/vm/edu/opt
CD=/mainpool/iso/edu14041.iso
HDD2=/dev/zvol/rdsk/mainpool/vm/edu/home
HDD3=/dev/zvol/rdsk/mainpool/vm/edu/swap
MEM=8192
# don't change below here!
TLN=`expr 7000 + $NUM`
mac0=`dladm show-vnic -po macaddress $VNIC0`
mac1=`dladm show-vnic -po macaddress $VNIC1`
mac2=`dladm show-vnic -po macaddress $VNIC2`
/usr/bin/qemu-system-x86_64 \
-name $NAME \
-boot cd \
-enable-kvm \
-vnc 0.0.0.0:$NUM \
-smp cores=2,threads=2 \
-m $MEM \
-no-hpet \
-localtime \
-drive file=$HDD0,if=virtio,index=0 \
-drive file=$HDD1,if=virtio,index=2 \
-drive file=$CD,media=cdrom,if=ide,index=1 \
-drive file=$HDD2,if=virtio,index=3 \
-drive file=$HDD3,if=virtio,index=4 \
-net nic,vlan=0,name=net0,model=virtio,macaddr=$mac0 \
-net vnic,vlan=0,name=net0,ifname=$VNIC0,macaddr=$mac0 \
-net nic,vlan=1,name=net1,model=virtio,macaddr=$mac1 \
-net vnic,vlan=1,name=net1,ifname=$VNIC1,macaddr=$mac1 \
-net nic,vlan=2,name=net2,model=virtio,macaddr=$mac2 \
-net vnic,vlan=2,name=net2,ifname=$VNIC2,macaddr=$mac2 \
-vga std \
-cpu host \
-pidfile /mainpool/vm/edu/pids/$NAME.pid \
-monitor telnet:localhost:$TLN,server,nowait,nodelay \
-daemonize
if [ $? -gt 0 ]; then
echo Failed to start VM
exit
fi
port=`expr 5900 + $NUM`
public_nic=$(dladm show-vnic|grep vnic0|awk '{print $2}')
public_ip=$(ifconfig $public_nic|grep inet|awk '{print $2}')
echo Started VM: $NAME
echo VNC available at: host IP ${public_ip} port ${port}
echo QEMU Monitor, do: # telnet localhost $TLN. Note: use
[OmniOS-discuss] Ang: Re: Ang: Re: Ang: Re: Ang: Re: r151014 KVM crash
Ahh, that one!
Thanks again! I'll have a look at it! Since you use it, I guess you find it
useful?
Any pro's and con's as you see it?
Rgrds Johan
-Jorge Schrauwen sjorge...@blackdot.be skrev: -
Till: Johan Kragsterman johan.kragster...@capvert.se
Från: Jorge Schrauwen sjorge...@blackdot.be
Datum: 2015-04-06 19:44
Kopia: Michael Rasmussen m...@miras.org, omnios-discuss@lists.omniti.com
Ärende: Re: Ang: Re: Ang: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash
Nope :)
https://github.com/hadfl/kvmadm/
Regards
Jorge
On 2015-04-06 19:42, Johan Kragsterman wrote:
Thnks, Jorge!
Yeah, I'm the one with the problems...
So you're using kvmadm...? Is that from smartOS, huh? How did you
manage to get it to work on OmniOS?
Rgrds Johan
-Jorge Schrauwen sjorge...@blackdot.be skrev: -
Till: Johan Kragsterman johan.kragster...@capvert.se
Från: Jorge Schrauwen sjorge...@blackdot.be
Datum: 2015-04-06 19:25
Kopia: Michael Rasmussen m...@miras.org,
omnios-discuss@lists.omniti.com
Ärende: Re: Ang: Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash
Who ever is having the problem :)
It was a bit hard to follow, I'm using kvmadm and this is my config:
{
cosmos : {
nics : [
{
index : 0,
nic_name : vcosmos0,
model : virtio,
vlan_id : 10
},
{
index : 1,
nic_name : vcosmos1,
model : virtio
}
],
cpu_type : qemu64,+aes,+sse4.2,+sse4.1,+ssse3,
hpet : true,
usb_tablet : true,
disks : [
{
index : 0,
boot : true,
disk_path : main/vms/hosts/cosmos/disk0,
model : virtio
}
],
shutdown : acpi_kill,
boot_order : cd,
vcpus : sockets=1,cores=4,threads=2,
serials : [
{
index : 0,
serial_name : console
}
],
cleanup : true,
ram : 6144,
time_base : utc
}
}
Which turns into:
-(~)-[!]-{ pfexec pargs 616
}-(sjorge@core)-
616: /usr/bin/qemu-system-x86_64 -name cosmos -enable-kvm -m 6144
-cpu qemu64,+aes,+
argv[0]: /usr/bin/qemu-system-x86_64
argv[1]: -name
argv[2]: cosmos
argv[3]: -enable-kvm
argv[4]: -m
argv[5]: 6144
argv[6]: -cpu
argv[7]: qemu64,+aes,+sse4.2,+sse4.1,+ssse3
argv[8]: -smp
argv[9]: sockets=1,cores=4,threads=2
argv[10]: -rtc
argv[11]: base=utc,driftfix=slew
argv[12]: -pidfile
argv[13]: /var/run/kvm/cosmos.pid
argv[14]: -monitor
argv[15]: unix:/var/run/kvm/cosmos.monitor,server,nowait,nodelay
argv[16]: -vga
argv[17]: none
argv[18]: -nographic
argv[19]: -drive
argv[20]:
file=/dev/zvol/rdsk/main/vms/hosts/cosmos/disk0,if=virtio,media=disk,index=0,cache=none,boot=on
argv[21]: -boot
argv[22]: order=cd
argv[23]: -device
argv[24]:
virtio-net-pci,mac=02:08:20:f5:95:f4,tx=timer,x-txtimer=20,x-txburst=128,vlan=10
argv[25]: -net
argv[26]: vnic,vlan=10,name=net0,ifname=vcosmos0
argv[27]: -device
argv[28]:
virtio-net-pci,mac=02:08:20:0c:08:d2,tx=timer,x-txtimer=20,x-txburst=128,vlan=0
argv[29]: -net
argv[30]: vnic,vlan=0,name=net1,ifname=vcosmos1
argv[31]: -chardev
argv[32]:
socket,id=serial0,path=/var/run/kvm/cosmos.console,server,nowait
argv[33]: -serial
argv[34]: chardev:serial0
argv[35]: -usb
argv[36]: -usbdevice
argv[37]: tablet
argv[38]: -daemonize
PS: shout out to dan for introducing me to pgrep and pargs!
Regards
Jorge
On 2015-04-06 19:22, Johan Kragsterman wrote:
Jorge, I thought you would jump in on this thread!
Are you asking me or Michael?
I'm not running ivy bridge on this machine, it's an older westmere...
Yeah, I pass --cpu=host
Can you provide your config file, pls?
Mine is like this:
root@omni2:/usr/bin# cat vmedu14041.sh
#!/usr/bin/bash
# on omnios command is /usr/bin/qemu-system-x86_64
# configuration
NAME=EDU14041
NUM=4
VNIC0=ltsp0
VNIC1=ltsp1
VNIC2=ltsptl0
HDD0=/dev/zvol/rdsk/mainpool/vm/edu/os
HDD1=/dev/zvol/rdsk/mainpool/vm/edu/opt
CD=/mainpool/iso/edu14041.iso
HDD2=/dev/zvol/rdsk/mainpool/vm/edu/home
HDD3=/dev/zvol/rdsk/mainpool/vm/edu/swap
MEM=8192
# don't change below here!
TLN=`expr 7000 + $NUM`
mac0=`dladm show-vnic -po macaddress $VNIC0`
mac1=`dladm show-vnic -po macaddress $VNIC1`
mac2=`dladm show-vnic -po macaddress $VNIC2`
/usr/bin/qemu-system-x86_64 \
-name $NAME \
-boot cd \
-enable-kvm \
-vnc 0.0.0.0:$NUM \
-smp cores=2,threads=2 \
-m $MEM \
-no-hpet \
-localtime \
-drive file=$HDD0,if=virtio,index=0 \
-drive file=$HDD1,if=virtio,index=2 \
-drive file=$CD,media=cdrom,if=ide,index=1 \
-drive file=$HDD2,if=virtio,index=3 \
-drive file=$HDD3,if=virtio,index=4 \
-net nic,vlan=0,name=net0,model=virtio,macaddr=$mac0 \
-net vnic,vlan=0,name=net0,ifname=$VNIC0,macaddr=$mac0 \
-net
Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V
___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Best infrastructure for VSphere/Hyper-V
Update: I disabled cstates and mwaits and that fixed the crashes i was getting when,the system was slow. But I still got the qlogic target dropouts during certain ios.after lots of research, I guessed that I was having a queuing problem. To alleviate that I did a couple things: 1. Reconfigured all my host and target views so that each host port only saw one target port. Formerly I had all four of my target ports mapped to both initiators on each host. This led to a situation where i had eight mpio paths on each host. 2. Assuming an incoming queue depth of 256 (right?) for each fibre target port, a round robin mpio infrastructure was bound to flood the target ports. Some documentation on qlogic indicated the default per lun outgoing queue depth was 32. After some calculations I dropped this to 16. As of now, each host only has two mpio paths in round robin with an outgoing queue depth of 16. I tried to test it under io load and was unable to get it to drop out in scenarios that would cause qlt to drop out in the past. (Multiple io operations while running a backup and destroying a hyperv checkpoint, etc.) system appears stable. So far. Thanks for the help everyone. Will update. -Nate___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] New MB
On Mon, 6 Apr 2015 14:16:38 -0400 Eric Sproul eric.spr...@circonus.com wrote: The manual for that board strongly suggests that users only employ this board as part of the full system 5018A-AR12L http://www.supermicro.com/products/system/1U/5018/SSG-5018A-AR12L.cfm That should tell you something. ;) I know. Anyways, the inquiry has been send to support and when I receive an answer I will report back to the list. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael at rasmussen dot cc http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD3C9A00E mir at datanom dot net http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE501F51C mir at miras dot org http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE3E80917 -- /usr/games/fortune -es says: If in doubt, mumble. pgpSk9TbpMI94.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue
On Mon, Apr 6, 2015 at 9:30 AM, Dan McDonald dan...@omniti.com wrote: On Apr 6, 2015, at 5:50 AM, Hafiz Rafiyev rafibe...@gmail.com wrote: only log I see from omnios side is: nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local hostname binding for transport tcp6 - delegations will not be available on this transport Are you having DNS problems? This error is in an unchanged subsystem, the NFSv4 callback daemon. The error looks like something caused by a naming-services failure. I'd say this is a red-herring. ESXi 5.5 will only use NFSv3. However, DNS resolution is critical for ESXi NFS mounts even when mounting via IP address. I always put host entries in /etc/hosts on each ESXi host for all other hosts, vCenter and NFS servers. The same on the NFS server side. I learned this years ago on a 3 AM call to VMware support. :) -Chip I'll forward your note along to an illumos-community NFS expert, I may find out more. 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] zfs performance vis-a-vis cpu cores
Hi all, Any benchmarks available which profes coherence between number of cpu cores and zfs performance? And does it matter whether it is real cores or threads? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael at rasmussen dot cc http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD3C9A00E mir at datanom dot net http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE501F51C mir at miras dot org http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE3E80917 -- /usr/games/fortune -es says: So much food; so little time! pgp7rDH_CmPRE.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Problem with VNIC in KVM
On Mon, 6 Apr 2015 22:05:25 + (UTC) Andy Fiddaman omn...@citrus-it.net wrote: Evening all, I'm having a problem with network interfaces inside KVM and wondered if anyone has any ideas? Is hardware checksum offloading on for the nic? Hardware checksum offloading is a notorious problem for virtualized environments. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael at rasmussen dot cc http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD3C9A00E mir at datanom dot net http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE501F51C mir at miras dot org http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE3E80917 -- /usr/games/fortune -es says: Avoid multiple exits from loops. - The Elements of Programming Style (Kernighan Plaugher) pgpVzPDg_qJXb.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] 014 NGZ: beadm problems
On Apr 6, 2015, at 4:13 PM, Volker A. Brandt v...@bb-c.de wrote: The zone works fine. However, when I look at the current BEs inside the NGZ I get this: omnit1# beadm list BE Active Mountpoint Space Policy Created zbe xNb2015-04-06 18:35 / 510M static 2015-04-06 18:35 Yeah, that's very odd. I just created a zone on one of my 014 vms, and didn't see your problem. I *did* have an old zone from 012 previously on that particular one. So I tried again on one I'm pretty sure never saw a zone prior to a fresh-from-ISO-or-kayak installation. No problems there either. To make a long story short, testing on another zone with the ipkg as opposed to the lipkg brand produces the same result. The only relevant bug I could find is #3845 but that is marked resolved: https://www.illumos.org/issues/3845 What am I doing wrong? How could I tackle this? I have checked the obvious, i.e. a missing libuuid, but it is there and gets pulled in properly. I'm honestly not sure what you're doing wrong. I noticed only one difference just now, but that really shouldn't matter: I use exclusive-stack zones... exclusively. You used shared-stack. I can't believe that'd make a difference... ... and it didn't. It's working for me. I'll try a fresh install on this VM, just to make sure it's all good. Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] 014 NGZ: beadm problems
On Apr 6, 2015, at 4:59 PM, Dan McDonald dan...@omniti.com wrote: I'll try a fresh install on this VM, just to make sure it's all good. I couldn't reproduce your bug installing my VM from the r151014 ISO. I got this upon zone login (exclusive-stack, though): root@danmcd-ob:/root# zlogin -C tz2 [Connected to zone 'tz2' console] 111/111 Hostname: tz2 tz2 console login: root Password: Apr 6 21:16:01 tz2 login: Solaris_audit getaddrinfo(tz2) failed[node name or service name not known]: Error 0 Apr 6 21:16:01 tz2 login: Solaris_audit adt_get_local_address failed, no Audit IP address available, faking loopback and error: Network is down Apr 6 21:16:01 tz2 login: pam_unix_cred: cannot load ttyname: Network is down, continuing. Apr 6 21:16:01 tz2 login: ROOT LOGIN /dev/console OmniOS 5.11 omnios-a708424 April 2015 root@tz2:/root# beadm list BE Active Mountpoint Space Policy Created zbe NR / 1.04G static 2015-04-06 21:12 root@tz2:/root# beadm create zbe-69 Created successfully root@tz2:/root# beadm list BE Active Mountpoint Space Policy Created zbeNR / 1.04G static 2015-04-06 21:12 zbe-69 - - 1.00K static 2015-04-06 21:16 root@tz2:/root# beadm destroy zbe-69 Are you sure you want to destroy zbe-69? This action cannot be undone (y/[n]): y 'Destroyed successfully root@tz2:/root# exit logout tz2 console login: tz2 console login: Connection to danmcd-ob closed. I'm not sure what you can or should do. Maybe your pool has some corruption? (Long shot I know, but perhaps zpool scrub might be in order?) Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] 014 NGZ: beadm problems
Dan McDonald writes: I noticed only one difference just now, but that really shouldn't matter: I use exclusive-stack zones... exclusively. You used shared-stack. I can't believe that'd make a difference... ... and it didn't. It's working for me. I'll try a fresh install on this VM, just to make sure it's all good. Just to cross-check, I'll try an ip-type=exclusive zone... tomorrow. :-) Thanks for looking into this. Regards -- Volker -- Volker A. Brandt Consulting and Support for Oracle Solaris Brandt Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgröße: 46 Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt When logic and proportion have fallen sloppy dead ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Realtek ethernet driver
I'm sorry for not replying earlier but the nic is working. I went out on Saturday and bought an intel nic and after installing the new card I tried the Realtek nic again and it worked fine. No idea of what happened and why. Frank On Mon, Apr 06, 2015 at 10:08:12AM -0400, Eric Sproul wrote: On Sat, Apr 4, 2015 at 12:31 AM, Frank Pittel f...@deepthought.com wrote: I have an addon ethernet board in my machine that uses a RTL8169 chip. The driver loads and I am able to configure it and assign the nic an IP address. However when I connect a cable to it the nic doesn't respond to ping, ssh, etc. The intel onboard nic works without issue. The relevent entry from lspci is: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10) Is there a known issue with the driver? Frank, This chip is ostensibly supported by rge(7D), but there are many revisions of that chip, used in a wide variety of adapters. These are usually found more on desktop/enthusiast systems than server hardware, so the driver, rge, doesn't get a whole lot of attention. The last substantive update to it was back in the OpenSolaris days, when Sun thought that developer laptops were a good distro target. :/ It's possible there are newer revisions of the chip that have different enough PHYs that the driver doesn't know how to initialize the link. If you could share the PCI ID of that part (`prtconf -d | grep RTL8169`), that would be helpful, but my guess would be that someone will have to take up the task of updating rge(7D) to support more parts. And.. if it were me, I'd just forget about it and use the Intel port. If you need a second NIC, go Intel. Eric ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade
Thank you for that detailed analysis. I have massive context switching happening later this week, and again next week, but I want to remember this so I can do something about it. Thank you again, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Problem with VNIC in KVM
On Mon, 6 Apr 2015 23:42:55 + (UTC) Andy Fiddaman omn...@citrus-it.net wrote: I've just tried it on and off and no difference (host and VM). The annoying thing is that I've had this working fine in the lab before the machine was rebuilt and put into production. Must be missing something! Ok. Could it be some missing ipf? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael at rasmussen dot cc http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD3C9A00E mir at datanom dot net http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE501F51C mir at miras dot org http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE3E80917 -- /usr/games/fortune -es says: Culus OH MY GOD NOT A RANDOM QUOTE GENERATOR netgod surely you didnt think that was static? how lame would that be? :-) pgpz7cskwkeJH.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade
7 апреля 2015 г. 3:32:23 CEST, Dan McDonald dan...@omniti.com пишет: Thank you for that detailed analysis. I have massive context switching happening later this week, and again next week, but I want to remember this so I can do something about it. Thank you again, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss Chris, about a month or two ago i replied on an illumos-related list regarding a similar problem (maybe this popped up for hipster users more than once). Searching for those might add more details to your context ;) Short story is that /opt is part of a namespace managed by the Solaris packaging and as such is part of a BE fs tree. If you have privately managed packages under certain subdirs, turn those sub-dirs into separate datasets instead. Alternately see my write-up on split-root installs (in OI wiki), i have some script scaffolding (now on github) to manage similar setups and explain that in the wiki. For now this is a bolt-on workaround. I'd be happy if someone ported that into illumos-gate properly, bugs were filed years ago ;) HTH, Jim Klimov -- Typos courtesy of K-9 Mail on my Samsung Android ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] r151014 KVM crash
Hi! I switched one of my development machines over to r151014. On that machine I got a few KVM VM's. One of them is a Linux terminal server, and when I wanted to update/upgrade it, both the general OS and the chroot environments I got in it, it crashed. I tried several times, and every time I did it, it crashed. It seems to run without problems when I don't do any heavy work on it, but with this update/upgrade, it runs for about ~5 min, then it crashes. It can't get started again, until I reboot the server. The following msg is from /var/adm/messages: 40b, id=1, base_msr= fee0 PRIx64 base_address=fee0 Apr 4 20:45:45 omni2 kvm: [ID 710719 kern.info] vmcs revision_id = f Apr 4 20:45:45 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ff06140a8000 , id=2, base_msr= fee0 PRIx64 base_address=fee0 Apr 4 20:45:45 omni2 kvm: [ID 710719 kern.info] vmcs revision_id = f Apr 4 20:45:45 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ff0614236000 , id=3, base_msr= fee0 PRIx64 base_address=fee0 Apr 4 20:45:45 omni2 kvm: [ID 710719 kern.info] vmcs revision_id = f Apr 4 20:45:52 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x1010101 data fd 7fffdfe8e0 Apr 4 20:45:52 omni2 last message repeated 3 times Apr 4 20:45:52 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0xff3d0f9c data f d7fffdfe8b0 Apr 4 20:45:52 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x0 data 0 Apr 4 20:45:52 omni2 last message repeated 6 times Apr 4 20:45:52 omni2 kvm: [ID 291337 kern.info] vcpu 1 received sipi with vector # 10 Apr 4 20:45:52 omni2 kvm: [ID 291337 kern.info] vcpu 2 received sipi with vector # 10 Apr 4 20:45:52 omni2 kvm: [ID 291337 kern.info] vcpu 3 received sipi with vector # 10 Apr 4 20:45:52 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ff06140b , id=1, base_msr= fee00800 PRIx64 base_address=fee0 Apr 4 20:45:52 omni2 kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ff06140a8000 , id=2, base_msr= fee00800 PRIx64 base_address=fee0 Then it goes on like this: Apr 4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 800 01 Apr 4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 800 01 Apr 4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 800 01 Apr 4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 800 01 Apr 4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 800 01 Apr 4 20:46:25 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:46:25 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 800 01 Apr 4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 200 001 Apr 4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 200 001 Apr 4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 200 001 Apr 4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 200 001 Apr 4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 200 001 Apr 4 20:46:34 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:46:34 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x525f2f data 200 And like this: Apr 4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr 4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr 4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr 4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr 4 20:50:45 omni2 kvm: [ID 713435 kern.info] unhandled rdmsr: 0xff311c4c Apr 4 20:50:45 omni2 kvm: [ID 391722 kern.info] unhandled wrmsr: 0x526835 data 8 Apr 4 20:50:45 omni2 kvm: [ID 713435
[OmniOS-discuss] pkgrecv r151014
Hi, I am trying to pkgrecv r151014 into my own repository and keep bumping into this: pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) Is there a problem with this package in the repository? -- Al Slater ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] pkgrecv r151014
On 06/04/15 11:03, Al Slater wrote: Hi, I am trying to pkgrecv r151014 into my own repository and keep bumping into this: pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) Is there a problem with this package in the repository? Same happens with pkg install... # pkg install pkg:/developer/sunstudio12.1@12.1-0.151014 Packages to install: 1 Create boot environment: No Create backup boot environment: No DOWNLOADPKGS FILESXFER (MB) SPEED developer/sunstudio12.1 0/1 5042/7006 203.1/256.3 3.0M/s Errors were encountered while attempting to retrieve package or file data for the requested operation. Details follow: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) regards -- Al Slater Technical Director SCL Phone : +44 (0)1273 07 Fax : +44 (0)1273 01 email : al.sla...@scluk.com Stanton Consultancy Ltd Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU Registered in England Company number: 1957652 VAT number: GB 760 2433 55 ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue
After upgrade from r151012 to r151014 i have issue with nfs server, after upgrade, some of Esxi 5.5 nfs datastores connecting and some not, and it's being randomly,after omnios restart again some datastores connected and some not when looking omnios side,nfs server up and running, note:before upgrade all esxi datastores were connected and running,omnios running as VM,disks connected with HBA passthruogh mode only log I see from omnios side is: nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local hostname binding for transport tcp6 - delegations will not be available on this transport regards Hafiz. ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] All SSD pool advice
Thanks everyone. Regarding the expanders, our 4U servers are on the following chassis: http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm We are using all SAS disks, except for the SSDs. How big is the risk here when it comes to SAS - SATA conversion? Our newer servers have direct connections on each lane to the disk. Chris Chris Nagele Co-founder, Wildbit Beanstalk, Postmark, dploy.io On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes d...@will.to wrote: We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro is the current favorite). They work great for IOPS. Here's my take. 1) you don't need a dedicated zil. Just let the zpool intersperse it amongst the existing zpool devices. They are plenty fast enough. 2) you don't need an L2arc for the same reason. a smaller number of dedicated devices would likely cause more of a bottleneck than serving off the existing pool devices (unless you were to put it on one of those giant RDRAM things or similar, but that adds a lot of expense) On 4/4/2015 3:07 PM, Chris Nagele wrote: We've been running a few 4U Supermicro servers using ZeusRAM for zil and SSDs for L2. The main disks are regular 1TB SAS. I'm considering moving to all SSD since the pricing has dropped so much. What things should I know or do when moving to all SSD pools? I'm assuming I don't need L2 and that I should keep the ZeusRAM. Should I only use certain types of SSDs? Thanks, Chris -- Chris Nagele Co-founder, Wildbit Beanstalk, Postmark, dploy.io ___ 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
[OmniOS-discuss] Fwd: All SSD pool advice
Sorry, forget to forward to the list ... -- Forwarded message -- From: Fábio Rabelo fa...@fabiorabelo.wiki.br Date: 2015-04-06 10:51 GMT-03:00 Subject: Re: [OmniOS-discuss] All SSD pool advice To: Chris Nagele nag...@wildbit.com I never get my hands at that 4U model ... I have 2 of this babys in a customer of mine : http://www.supermicro.com/products/chassis/2U/216/SC216BA-R1K28LP.cfm Each one with 24 1TB Samsung 850PRO for a litle over an year, OminOS+Napp-it , no issue whatsoever ... Expanded Chassis brings me lots and lots of headaches ... Fábio Rabelo 2015-04-06 10:41 GMT-03:00 Chris Nagele nag...@wildbit.com: Thanks everyone. Regarding the expanders, our 4U servers are on the following chassis: http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm We are using all SAS disks, except for the SSDs. How big is the risk here when it comes to SAS - SATA conversion? Our newer servers have direct connections on each lane to the disk. Chris Chris Nagele Co-founder, Wildbit Beanstalk, Postmark, dploy.io On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes d...@will.to wrote: We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro is the current favorite). They work great for IOPS. Here's my take. 1) you don't need a dedicated zil. Just let the zpool intersperse it amongst the existing zpool devices. They are plenty fast enough. 2) you don't need an L2arc for the same reason. a smaller number of dedicated devices would likely cause more of a bottleneck than serving off the existing pool devices (unless you were to put it on one of those giant RDRAM things or similar, but that adds a lot of expense) On 4/4/2015 3:07 PM, Chris Nagele wrote: We've been running a few 4U Supermicro servers using ZeusRAM for zil and SSDs for L2. The main disks are regular 1TB SAS. I'm considering moving to all SSD since the pricing has dropped so much. What things should I know or do when moving to all SSD pools? I'm assuming I don't need L2 and that I should keep the ZeusRAM. Should I only use certain types of SSDs? Thanks, Chris -- Chris Nagele Co-founder, Wildbit Beanstalk, Postmark, dploy.io ___ 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 ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Fwd: All SSD pool advice
On Mon, Apr 6, 2015 at 8:53 AM, Fábio Rabelo fa...@fabiorabelo.wiki.br wrote: Sorry, forget to forward to the list ... -- Forwarded message -- From: Fábio Rabelo fa...@fabiorabelo.wiki.br Date: 2015-04-06 10:51 GMT-03:00 Subject: Re: [OmniOS-discuss] All SSD pool advice To: Chris Nagele nag...@wildbit.com I never get my hands at that 4U model ... I have 2 of this babys in a customer of mine : http://www.supermicro.com/products/chassis/2U/216/SC216BA-R1K28LP.cfm Each one with 24 1TB Samsung 850PRO for a litle over an year, OminOS+Napp-it , no issue whatsoever ... Expanded Chassis brings me lots and lots of headaches ... The system I've built with interposers has SAS expanders and gives me no problems. Samsung SSDs are the only SSD I've found that works well with the interposer. -Chip Fábio Rabelo 2015-04-06 10:41 GMT-03:00 Chris Nagele nag...@wildbit.com: Thanks everyone. Regarding the expanders, our 4U servers are on the following chassis: http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm We are using all SAS disks, except for the SSDs. How big is the risk here when it comes to SAS - SATA conversion? Our newer servers have direct connections on each lane to the disk. Chris Chris Nagele Co-founder, Wildbit Beanstalk, Postmark, dploy.io On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes d...@will.to wrote: We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro is the current favorite). They work great for IOPS. Here's my take. 1) you don't need a dedicated zil. Just let the zpool intersperse it amongst the existing zpool devices. They are plenty fast enough. 2) you don't need an L2arc for the same reason. a smaller number of dedicated devices would likely cause more of a bottleneck than serving off the existing pool devices (unless you were to put it on one of those giant RDRAM things or similar, but that adds a lot of expense) On 4/4/2015 3:07 PM, Chris Nagele wrote: We've been running a few 4U Supermicro servers using ZeusRAM for zil and SSDs for L2. The main disks are regular 1TB SAS. I'm considering moving to all SSD since the pricing has dropped so much. What things should I know or do when moving to all SSD pools? I'm assuming I don't need L2 and that I should keep the ZeusRAM. Should I only use certain types of SSDs? Thanks, Chris -- Chris Nagele Co-founder, Wildbit Beanstalk, Postmark, dploy.io ___ 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 ___ 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] All SSD pool advice
On Mon, Apr 6, 2015 at 8:41 AM, Chris Nagele nag...@wildbit.com wrote:
Thanks everyone. Regarding the expanders, our 4U servers are on the
following chassis:
http://www.supermicro.com/products/chassis/4U/846/SC846E16-R1200.cfm
We are using all SAS disks, except for the SSDs. How big is the risk
here when it comes to SAS - SATA conversion? Our newer servers have
direct connections on each lane to the disk.
There are A LOT of opinions on this. What I have done that has worked
extremely well was use 70 Samsung 840 Pro SSD with LSI interposers in
Supermicro chassis. There were a couple early failures of the interposers
but it has been rock solid ever since. mpt_sas blue chunks and panic'd
the system on one. On another one I caught it in action and doing a 'zpool
offline {device}' kept everything running without a hitch.
I run with ZIL off because this is used entirely for scratch data and
virtual machines that can be redeployed in minutes. It would be sync safe
with the addition of some good log devices.
I'm not sure if the interposers increased stability or it has simply been
the quality of the Samsung SSD.
-Chip
Chris
Chris Nagele
Co-founder, Wildbit
Beanstalk, Postmark, dploy.io
On Sat, Apr 4, 2015 at 7:18 PM, Doug Hughes d...@will.to wrote:
We have a couple of machines with all SSD pool (~6-10 Samsung 850 pro is
the
current favorite). They work great for IOPS. Here's my take.
1) you don't need a dedicated zil. Just let the zpool intersperse it
amongst
the existing zpool devices. They are plenty fast enough.
2) you don't need an L2arc for the same reason. a smaller number of
dedicated devices would likely cause more of a bottleneck than serving
off
the existing pool devices (unless you were to put it on one of those
giant
RDRAM things or similar, but that adds a lot of expense)
On 4/4/2015 3:07 PM, Chris Nagele wrote:
We've been running a few 4U Supermicro servers using ZeusRAM for zil and
SSDs for L2. The main disks are regular 1TB SAS.
I'm considering moving to all SSD since the pricing has dropped so much.
What things should I know or do when moving to all SSD pools? I'm
assuming I
don't need L2 and that I should keep the ZeusRAM. Should I only use
certain
types of SSDs?
Thanks,
Chris
--
Chris Nagele
Co-founder, Wildbit
Beanstalk, Postmark, dploy.io
___
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
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Realtek ethernet driver
On Sat, Apr 4, 2015 at 12:31 AM, Frank Pittel f...@deepthought.com wrote: I have an addon ethernet board in my machine that uses a RTL8169 chip. The driver loads and I am able to configure it and assign the nic an IP address. However when I connect a cable to it the nic doesn't respond to ping, ssh, etc. The intel onboard nic works without issue. The relevent entry from lspci is: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10) Is there a known issue with the driver? Frank, This chip is ostensibly supported by rge(7D), but there are many revisions of that chip, used in a wide variety of adapters. These are usually found more on desktop/enthusiast systems than server hardware, so the driver, rge, doesn't get a whole lot of attention. The last substantive update to it was back in the OpenSolaris days, when Sun thought that developer laptops were a good distro target. :/ It's possible there are newer revisions of the chip that have different enough PHYs that the driver doesn't know how to initialize the link. If you could share the PCI ID of that part (`prtconf -d | grep RTL8169`), that would be helpful, but my guess would be that someone will have to take up the task of updating rge(7D) to support more parts. And.. if it were me, I'd just forget about it and use the Intel port. If you need a second NIC, go Intel. Eric ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] r151014 KVM crash
If you can find those extra messages, that'd be very helpful. Your /var/adm/messages.* files should contain everything that gets spit out. When you say it crashes you mean the KVM machine, not the OmniOS kernel, right? Thanks, Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Ang: Re: r151014 KVM crash
Hej!I mean the KVM process crashes or get killed or whatever. The KVM virtual machine is suddenly stopped, and can't get started again, until reboot of the OmniOS machine. The Linux OS on the virtual machine doesn't crash.I guess I need to get back to the r151014 again to find out more, but I wanted to roll back to r151012 to see the difference. And as I told you, there were no crashes on the r151012.When I done some update jobs here on r151012, I'll get back to r151014 and try to find out more...Best regards from/Med vänliga hälsningar frånJohan KragstermanCapvert-Dan McDonald dan...@omniti.com skrev: -Till: Johan Kragsterman johan.kragster...@capvert.seFrån: Dan McDonald dan...@omniti.comDatum: 2015-04-06 16:26Kopia: "omnios-discuss@lists.omniti.com" omnios-discuss@lists.omniti.com, Dan McDonald dan...@omniti.comÄrende: Re: [OmniOS-discuss] r151014 KVM crashIf you can find those extra messages, that'd be very helpful. Your /var/adm/messages.* files should contain everything that gets spit out.When you say "it crashes" you mean the KVM machine, not the OmniOS kernel, right?Thanks,Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
[OmniOS-discuss] Bacula and LTO-3
Hi all, For my home storage server I am in the position of getting my hand on a decommissioned tape drive either Quantum TE7100 LTO-3 SAS or HP StorageWorks Ultrium 920 SAS LTO 3. I have 2 HBA's in this box: LSI 1068 and LSI 1078. I guess both would be sufficient? Anybody have experience with either one of these on Omnios (151014) and in particular with the Bacula 5.2.6 version from the repo? Which one to choose? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael at rasmussen dot cc http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD3C9A00E mir at datanom dot net http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE501F51C mir at miras dot org http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE3E80917 -- /usr/games/fortune -es says: The jig's up, Elman. Which jig? -- Jeff Elman pgpKyzmV3NAws.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] pkgrecv r151014
Thanks Eric, AV on the gateway was the problem. Al On 06/04/15 15:14, Eric Sproul wrote: On Mon, Apr 6, 2015 at 6:24 AM, Al Slater al.sla...@scluk.com wrote: On 06/04/15 11:03, Al Slater wrote: Hi, I am trying to pkgrecv r151014 into my own repository and keep bumping into this: pkgrecv: Invalid contentpath opt/sunstudio12.1/prod/lib/sys/libsunir.so: chash failure: expected: b251c238070b6fdbf392194e85319e2c954a5384 computed: 17d9899f959ac5835569e8870f7e02eb14607242. (happened 4 times) Is there a problem with this package in the repository? It seems fine from my location: $ pkg contents -mr developer/sunstudio12.1 | grep libsunir.so file 19d832f8b112a9545e9d9b5aaf1384a7a37248f3 chash=b251c238070b6fdbf392194e85319e2c954a5384 elfarch=i386 elfbits=32 elfhash=710138bfbc99dd3aefd4a41dd49b9779cae35f15 group=bin mode=0755 $ curl -s http://pkg.omniti.com/omnios/r151014/file/1/19d832f8b112a9545e9d9b5aaf1384a7a37248f3 | sha1sum b251c238070b6fdbf392194e85319e2c954a5384 - Eric -- Al Slater Technical Director SCL Phone : +44 (0)1273 07 Fax : +44 (0)1273 01 email : al.sla...@scluk.com Stanton Consultancy Ltd Park Gate, 161 Preston Road, Brighton, East Sussex, BN1 6AU Registered in England Company number: 1957652 VAT number: GB 760 2433 55 ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] esxi 5.5 to omnios r151014 nfs server issue
On Apr 6, 2015, at 5:50 AM, Hafiz Rafiyev rafibe...@gmail.com wrote: only log I see from omnios side is: nfs4cbd[468]: [ID 867284 daemon.notice] nfsv4 cannot determine local hostname binding for transport tcp6 - delegations will not be available on this transport Are you having DNS problems? This error is in an unchanged subsystem, the NFSv4 callback daemon. The error looks like something caused by a naming-services failure. I'll forward your note along to an illumos-community NFS expert, I may find out more. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Realtek ethernet driver
On Mon, 6 Apr 2015 10:08:12 -0400 Eric Sproul eric.spr...@circonus.com wrote: revisions of that chip, used in a wide variety of adapters. These are usually found more on desktop/enthusiast systems than server hardware, with one exception: Realtek are often used as interface for IPMI+KVM. At least this is true for all my Supermicro boards. But then again this has nothing to do with the OS;-) -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael at rasmussen dot cc http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD3C9A00E mir at datanom dot net http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE501F51C mir at miras dot org http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE3E80917 -- /usr/games/fortune -es says: Not exactly as shown. pgpiKsdoNViiE.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash
On Apr 6, 2015, at 10:36 AM, Johan Kragsterman johan.kragster...@capvert.se wrote: Hej! I mean the KVM process crashes or get killed or whatever. The KVM virtual machine is suddenly stopped, and can't get started again, until reboot of the OmniOS machine. The Linux OS on the virtual machine doesn't crash. I guess I need to get back to the r151014 again to find out more, but I wanted to roll back to r151012 to see the difference. And as I told you, there were no crashes on the r151012. When I done some update jobs here on r151012, I'll get back to r151014 and try to find out more... I'm talking with the illumos KVM folks. They mentioned that Ivy Bridge Xeons (i.e. Xeon E5-26xx v2, where v2 means Ivy Bridge) have erratum that can cause problems. That you do not seem to see these in r151012, however, is very odd. There was only ONE change in the illumos-kvm kernel bits between releases, and it should have nothing to do with the errors you're seeing. commit 8bdb134ab2cbdd179cd0af6b4c4acf21af34fb87 Author: Robert Mustacchi r...@joyent.com Date: Wed Dec 10 21:22:50 2014 + HVM-812 QEMU build fails after eventfd That change was very tiny. They also asked for kernel panics on your guests, but you say they aren't panicking, just stopped? Do you have coredump from the kvm processes by any chance? That would ALSO be useful. Dan ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash
On Mon, 6 Apr 2015 11:55:27 -0400 Dan McDonald dan...@omniti.com wrote: I'm talking with the illumos KVM folks. They mentioned that Ivy Bridge Xeons (i.e. Xeon E5-26xx v2, where v2 means Ivy Bridge) have erratum that can cause problems. That you do not seem to see these in r151012, however, is very odd. There is also E3-12xx v2 which is Ivy Bridge based. Are these affected by this erratum as well? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael at rasmussen dot cc http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD3C9A00E mir at datanom dot net http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE501F51C mir at miras dot org http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE3E80917 -- /usr/games/fortune -es says: It's amazing how much mature wisdom resembles being too tired. pgpGTgOIWhsD6.pgp Description: OpenPGP digital signature ___ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss
Re: [OmniOS-discuss] Ang: Re: r151014 KVM crash
Out of curiosity, are you passing --cpu=host? I had issues with that on my ivy bridge. I currently use: qemu64,+aes,+sse4.2,+sse4.1,+ssse3 which seems to make a lot of things smoother. I stil get these but qemu does not crash for me: Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ff21ff94c000, id=0, base_msr= fee00100 PRIx64 base_address=fee0 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ff21ff944000, id=1, base_msr= fee0 PRIx64 base_address=fee0 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ff21ff93c000, id=2, base_msr= fee0 PRIx64 base_address=fee0 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ff2201f14000, id=3, base_msr= fee0 PRIx64 base_address=fee0 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ff2201f0c000, id=4, base_msr= fee0 PRIx64 base_address=fee0 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ff2201f04000, id=5, base_msr= fee0 PRIx64 base_address=fee0 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ff2201efc000, id=6, base_msr= fee0 PRIx64 base_address=fee0 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Apr 1 19:47:28 core.acheron.be kvm: [ID 420667 kern.info] kvm_lapic_reset: vcpu=ff2201f54000, id=7, base_msr= fee0 PRIx64 base_address=fee0 Apr 1 19:47:28 core.acheron.be kvm: [ID 710719 kern.info] vmcs revision_id = 10 Regards Jorge On 2015-04-06 18:03, Michael Rasmussen wrote: On Mon, 6 Apr 2015 11:55:27 -0400 Dan McDonald dan...@omniti.com wrote: I'm talking with the illumos KVM folks. They mentioned that Ivy Bridge Xeons (i.e. Xeon E5-26xx v2, where v2 means Ivy Bridge) have erratum that can cause problems. That you do not seem to see these in r151012, however, is very odd. There is also E3-12xx v2 which is Ivy Bridge based. Are these affected by this erratum as well? ___ 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
