Re: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA

[Stephan Budach]

Hi Michael,

Am 18.02.16 um 08:17 schrieb Michael Talbott:

While I don't have a setup like you've described, I'm going to take a wild 
guess and say check your switches (and servers) ARP tables. Perhaps the switch 
isn't updating your VIP address with the other servers MAC address fast enough. 
Maybe as part of the failover script, throw a command to your switch to update 
the ARP entry or clear its ARP table. Another perhaps simpler solution / 
diagnostic you could do is record a ping output of the server to your router 
via the vip interface and address right after the failover process to try and 
tickle the switch to update its mac table. Also it's possible the clients might 
need an ARP flush too.

If this is the case, another possibility is you could have both servers spoof 
the same MAC address and only ever have one up at a time and have them 
controlled by the failover script (or bad things will happen).

Just a thought.

Michael
Sent from my iPhone


On Feb 17, 2016, at 10:13 PM, Stephan Budach  wrote:

Hi,

I have been test driving RSF-1 for the last week to accomplish the following:

- cluster a zpool, that is made up from 8 mirrored vdevs, which are based on 8 
x 2 SSD mirrors via iSCSI from another OmniOS box
- export a nfs share from above zpool via a vip
- have RSF-1 provide the fail-over and vip-moving
- use the nfs share as a repository for my Oracle VM guests and vdisks

The setup seems to work fine, but I do have one issue, I can't seem to get solved. 
Whenever I failover the zpool, any inflight nfs data, will be stalled for some 
unpredictable time. Sometimes it takes not much longer than the "move" time of 
the resources but sometimes it takes up to 5 mins. until the nfs client on my VM server 
becomes alive again.

So, when I issue a simple ls -l on the folder of the vdisks, while the 
switchover is happening, the command somtimes comcludes in 18 to 20 seconds, 
but sometime ls will just sit there for minutes.

I wonder, if there's anything, I could do about that. I have already played 
with several timeouts, nfs wise and tcp wise, but nothing seem to yield any 
effect on this issue. Anyone, who knows some tricks to speed up the inflight 
data?

Thanks,
Stephan


I don't think that the switches are the problem, since when I ping the 
vip from the VM host (OL6 based), then the ping only ceases for the time 
it takes RSF-1 to move the services and afterwards the pings continue 
just normally. The only thing I wonder is, if it's more of a NFS or a 
tcp-in-general thing. Maybe I should also test some other IP protocol to 
see, if that one stalls as well for that long of a time.


Cheers,
Stephan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Testing RSF-1 with zpool/nfs HA

[Michael Talbott]

While I don't have a setup like you've described, I'm going to take a wild 
guess and say check your switches (and servers) ARP tables. Perhaps the switch 
isn't updating your VIP address with the other servers MAC address fast enough. 
Maybe as part of the failover script, throw a command to your switch to update 
the ARP entry or clear its ARP table. Another perhaps simpler solution / 
diagnostic you could do is record a ping output of the server to your router 
via the vip interface and address right after the failover process to try and 
tickle the switch to update its mac table. Also it's possible the clients might 
need an ARP flush too.

If this is the case, another possibility is you could have both servers spoof 
the same MAC address and only ever have one up at a time and have them 
controlled by the failover script (or bad things will happen).

Just a thought.

Michael
Sent from my iPhone

> On Feb 17, 2016, at 10:13 PM, Stephan Budach  wrote:
> 
> Hi,
> 
> I have been test driving RSF-1 for the last week to accomplish the following:
> 
> - cluster a zpool, that is made up from 8 mirrored vdevs, which are based on 
> 8 x 2 SSD mirrors via iSCSI from another OmniOS box
> - export a nfs share from above zpool via a vip
> - have RSF-1 provide the fail-over and vip-moving
> - use the nfs share as a repository for my Oracle VM guests and vdisks
> 
> The setup seems to work fine, but I do have one issue, I can't seem to get 
> solved. Whenever I failover the zpool, any inflight nfs data, will be stalled 
> for some unpredictable time. Sometimes it takes not much longer than the 
> "move" time of the resources but sometimes it takes up to 5 mins. until the 
> nfs client on my VM server becomes alive again.
> 
> So, when I issue a simple ls -l on the folder of the vdisks, while the 
> switchover is happening, the command somtimes comcludes in 18 to 20 seconds, 
> but sometime ls will just sit there for minutes.
> 
> I wonder, if there's anything, I could do about that. I have already played 
> with several timeouts, nfs wise and tcp wise, but nothing seem to yield any 
> effect on this issue. Anyone, who knows some tricks to speed up the inflight 
> data?
> 
> Thanks,
> Stephan
> 
> 
> 
> ___
> 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] Testing RSF-1 with zpool/nfs HA

[Stephan Budach]

Hi,

I have been test driving RSF-1 for the last week to accomplish the 
following:


- cluster a zpool, that is made up from 8 mirrored vdevs, which are 
based on 8 x 2 SSD mirrors via iSCSI from another OmniOS box

- export a nfs share from above zpool via a vip
- have RSF-1 provide the fail-over and vip-moving
- use the nfs share as a repository for my Oracle VM guests and vdisks

The setup seems to work fine, but I do have one issue, I can't seem to 
get solved. Whenever I failover the zpool, any inflight nfs data, will 
be stalled for some unpredictable time. Sometimes it takes not much 
longer than the "move" time of the resources but sometimes it takes up 
to 5 mins. until the nfs client on my VM server becomes alive again.


So, when I issue a simple ls -l on the folder of the vdisks, while the 
switchover is happening, the command somtimes comcludes in 18 to 20 
seconds, but sometime ls will just sit there for minutes.


I wonder, if there's anything, I could do about that. I have already 
played with several timeouts, nfs wise and tcp wise, but nothing seem to 
yield any effect on this issue. Anyone, who knows some tricks to speed 
up the inflight data?


Thanks,
Stephan



___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Question on puppet agent for OmniOS

[Trey Palmer]

I should add, I'd use the niksula package over CSW if you can.   I really
appreciate their repo (and OmniOS).

We only use the CSW package because at the time the available version
happened to line up with what we were running everywhere else.   As a
general rule, the agents shouldn't be an earlier version than your masters.


Now niksula has 3.8.5 which I might actually be able to change to.   Using
CSW packages intended for a diverging closed source Solaris is obviously
gonna bite me sooner or later.

As far as the manifest/method, if you run the daemon you can have puppet
install them on the first run, and puppet's standard service resource has a
"manifest" parameter that will "svccfg import" for you.

But Lauri is right that there's no real reason to run the daemon vice from
cron except to standardize with the rest of your org.

   -- Trey



On Wed, Feb 17, 2016 at 4:59 PM, Lauri Tirkkonen  wrote:

> On Wed, Feb 17 2016 15:52:00 -0600, Paul Jochum wrote:
> > Thanks for responding.  I am new to puppet, and curious, why do you
> run
> > it from cron, instead of in daemon mode?  Is it more secure, or is there
> > something else I am missing?
>
> It used to be that the agent was leaking memory in version 2.something
> when we first started using it. 'puppet kick' also existed then, to
> trigger an agent run from the master, but it doesn't anymore; we don't
> think there's any reason to run the agent as a daemon.
>
> --
> Lauri Tirkkonen | lotheac @ IRCnet
> ___
> 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] Question on puppet agent for OmniOS

[Lauri Tirkkonen]

On Wed, Feb 17 2016 15:52:00 -0600, Paul Jochum wrote:
> Thanks for responding.  I am new to puppet, and curious, why do you run
> it from cron, instead of in daemon mode?  Is it more secure, or is there
> something else I am missing?

It used to be that the agent was leaking memory in version 2.something
when we first started using it. 'puppet kick' also existed then, to
trigger an agent run from the master, but it doesn't anymore; we don't
think there's any reason to run the agent as a daemon.

-- 
Lauri Tirkkonen | lotheac @ IRCnet
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Question on puppet agent for OmniOS

[Paul Jochum]

Hi Lauri:

Thanks for responding.  I am new to puppet, and curious, why do you 
run it from cron, instead of in daemon mode?  Is it more secure, or is 
there something else I am missing?


thanks,
Paul

On 02/17/2016 03:30 PM, Lauri Tirkkonen wrote:

On Wed, Feb 17 2016 15:24:14 -0600, Paul Jochum wrote:

 For those that run puppet as an agent on OmniOS, which version do you
recommend using?  I see that OpenCSW has a version, and Niksula also has one
(and are there any others available?).  Is one version better than others?
I have tried installing the Niksula version, but I can't find any svcadm
scripts to start it up (or am I missing them?).

We don't ship any, because we run our agents from cron with --onetime.



___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Question on puppet agent for OmniOS

[Lauri Tirkkonen]

On Wed, Feb 17 2016 15:24:14 -0600, Paul Jochum wrote:
> For those that run puppet as an agent on OmniOS, which version do you
> recommend using?  I see that OpenCSW has a version, and Niksula also has one
> (and are there any others available?).  Is one version better than others?
> I have tried installing the Niksula version, but I can't find any svcadm
> scripts to start it up (or am I missing them?).

We don't ship any, because we run our agents from cron with --onetime.

-- 
Lauri Tirkkonen | lotheac @ IRCnet
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Question on puppet agent for OmniOS

[Trey Palmer]

Paul,

We run the OpenCSW packages, puppet3 and facter2, and they work fine.
They happen to line up with the versions we run on our primary platform.
You need to install facter2 first, or puppet3 will install facter 1.7.6 to
fulfill its dependency.

I have set up an IPS repo and built puppet packages in the past, but I
haven't taken the time to do so here given that the CSW packages work and
OmniOS is a limited-use platform.

-- Trey

On Wed, Feb 17, 2016 at 4:24 PM, Paul Jochum  wrote:

> Hi All:
>
> For those that run puppet as an agent on OmniOS, which version do you
> recommend using?  I see that OpenCSW has a version, and Niksula also has
> one (and are there any others available?).  Is one version better than
> others?  I have tried installing the Niksula version, but I can't find any
> svcadm scripts to start it up (or am I missing them?).
>
> thanks,
> Paul
> ___
> 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] Question on puppet agent for OmniOS

[Paul Jochum]

Hi All:

For those that run puppet as an agent on OmniOS, which version do 
you recommend using?  I see that OpenCSW has a version, and Niksula also 
has one (and are there any others available?).  Is one version better 
than others?  I have tried installing the Niksula version, but I can't 
find any svcadm scripts to start it up (or am I missing them?).


thanks,
Paul
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Modify or Delete a busy VNIC?

[Gordon Selisek]

Dan,



Thanks, how do i go about and find the offending process?



The vnic is not assigned anything, and the qemu is running in the GZ.





 On Wed, 17 Feb 2016 17:12:21 +0100 Dan McDonald 
dan...@omniti.comwrote  






 On Feb 17, 2016, at 9:08 AM, Gordon Selisek gor...@hafnia.dk 
wrote: 

 

 delete: the link is busy and can not be deleted, even if i kill the qemu 
process that is using it. 

 

 

Then some other process is using it. Is this vnic assigned to a non-global 
zone? If so, you'll have to halt the non-global zone as well. 

 

Dan 

 





___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Modify or Delete a busy VNIC?

[Dan McDonald]

> On Feb 17, 2016, at 9:08 AM, Gordon Selisek  wrote:
> 
> delete: the link is busy and can not be deleted, even if i kill the qemu 
> process that is using it.
> 

Then some other process is using it.  Is this vnic assigned to a non-global 
zone?  If so, you'll have to halt the non-global zone as well.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Ang: Re: Ang: zvol snapshot rollback issue, dataset busy

[Dan McDonald]

> On Feb 17, 2016, at 2:52 AM, Stephan Budach  wrote:
> 
> 
> Actually, the -k option is not mentioned anywhere but it is supported up to 
> any version I checked. I came across this option when I searched the net for 
> any means of deleting a LUN, but keeping the view and on some random website, 
> there it was...

FYI, the man pages are open-source too!

I checked the stmfadm source quickly, and the -k isn't commented with "TOP 
SECRET DO NOT DOCUMENT!" or anything like that.


http://src.illumos.org/source/xref/illumos-gate/usr/src/man/man1m/stmfadm.1m

Addressing -k would be a good way for someone to contribute.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Proliant gen9

[Goktug Yildirim]

Hello,

I am trying to boot a Gen9 (DL380) server but have no success so far. The link 
you share doesn’t seem to be working. 

Could you please share your grub changes?

Thanks in advance,
-Goktug Yildirim

> On 23 May 2015, at 02:09, Josh Barton  wrote:
> 
> An update to  my previous message:
> I am using only  Legacy BIOS boot mode now and skipping UEFI entirely. Using 
> the changes to the grub menu found in the link below I was able to  get to 
> the install screen using the r151014 image however I still get a no disk 
> found error. The controller is : HP Smart Array P440ar Controller
>  
> I have been trying to install OmniOS on a HP Proliant Gen9 server (r151014) 
> but it will only boot in Legacy boot mode. R151012 will boot but no disks are 
> found when I try to install. Has anyone experienced these issues? R151012 
> worked with our Proliant Gen8, is this a driver issue or something else?
>  
>  
>  
> See:
> http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c04633840 
> 
>  
> Thanks,
>  
> Josh Barton
> Utah Stage University Research Foundation
> ___
> 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] Modify or Delete a busy VNIC?

[Gordon Selisek]

dear all,



i need to either delete a busy vnic, or modify the vnic "OVER" property from a 
script. 



the vnic is used by a KVM running on same box.



dladm show-vnic

LINK OVER SPEED  MACADDRESSMACADDRTYPE VID

vnic0e1000g0  1000   2:8:20:1b:41:3c   random  0



delete: the link is busy and can not be deleted, even if i kill the qemu 
process that is using it.



modify: the dladm modify-vnic is not implemented in OmniOs, alas in Solaris11 
it's readily availabe 
(http://docs.oracle.com/cd/E26502_01/html/E28992/gmcdo.html)



Any suggestions please?


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Ang: Re: Ang: zvol snapshot rollback issue, dataset busy

[Stephan Budach]

Am 16.02.16 um 18:58 schrieb Johan Kragsterman:

Hi!



-"OmniOS-discuss"  skrev: -
Till: 
Från: Stephan Budach
Sänt av: "OmniOS-discuss"
Datum: 2016-02-16 17:44
Ärende: Re: [OmniOS-discuss] Ang: zvol snapshot rollback issue, dataset busy

Am 16.02.16 um 17:11 schrieb Johan Kragsterman:

Hi!


-"OmniOS-discuss"  skrev: -
Till: omnios-discuss 
Från: Hafiz Rafiyev
Sänt av: "OmniOS-discuss"
Datum: 2016-02-16 16:47
Ärende: [OmniOS-discuss] zvol snapshot rollback issue,dataset busy

I now its OmniOs forum,question about Nexenta v4.0.4FP02.
Maybe issue is common to illumos,

Getting below error when trying to rollback zvol snapshot,zvol unshared before 
rollback operation,system rebooted but result was same.
   
any sugesttions?


zfs rollback -r OPOOL/DATA@snap-hourly-1-2016-02-16-130002

cannot rollback 'OPOOL/DATA': dataset is busy
   


Nexenta log:

Feb 16 15:35:47 xxx nms[966]: [ID 702911 local0.error] (:1.12) EXCEPTION: 
SystemCallError: 
SnapshotContainer::rollback(OPOOL/DATA@snap-hourly-1-2016-02-16-130002,-r):

[zfs rollback -r OPOOL/DATA@snap-hourly-1-2016-02-16-130002] cannot rollback 
'OPOOL/DATA': dataset is busy




My guess is that the volume you want to roll it back to is registred as an LU with 
stmf...is it? If so, you need to delete it first. But be aware, before you delete the LU 
you need to delete any view for that LU. Otherwise you get views "hanging in the 
air" which is difficult to get rid of.


Johan


I'd say, it's the other way round if you delete a LUN via stmfadm
delete-lu, that will also delete it's views, which can be annoying, if
you then want to re-import the LUN from the rolled back snapshot, no?

If you want to keep the view, which is what I usually want to do, just
run stmfadm delete-lu -k  to keep the view. That way, you can then
re-import the LUN on the rolled back dataset and won't have to re-create
the view for it.

Cheers,
Stephan



Is that so? I have been annoyed by this for a long time, that I needed to delete the view 
as well. But actually this was not the case some years ago when I discovered how I needed 
to do this. At this time I had views "hanging in the air" without connection to 
a LU, and difficulties to remove them.
Happy to see that this is working the way it should...

But I am not familiar with this -k option, where is that one documented? Can't 
find it on Illumos man page for stmf, nor can I find it on Oracle.


/Johan

I concurr, as much as I had found it also very cumbersome having to 
delete all views manually in the old days… I think to remember, that 
this was on OpenSolaris in 2011, when I started playing with COMSTAR and 
I was creating/removing LUNs and targets quite frequently.
However, on a production system, where everything has settled, I prefer 
it the other way round and I like to keep the vews in case I have to 
remove a LUN for the sake of a snapshot rollback.


Actually, the -k option is not mentioned anywhere but it is supported up 
to any version I checked. I came across this option when I searched the 
net for any means of deleting a LUN, but keeping the view and on some 
random website, there it was...


Cheers,
Stephan
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss