--On 21 September 2017 07:23 -0700 "Rodney W. Grimes" <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:

So they don't. I presumed they were cam, as they're presented as 'ada0'.

Ok, need to sort that out for certain to get much further.

What are you running for Dom0?

XenServer 7.1 - i.e. the official ISO distribution from www.xenserver.org

Did you do the sysctl's in Dom0 or in the guest?

In the guest. I don't have access to the equivalent (or, rather shouldn't have access to the equivalent in Dom0 as it's the official installation - i.e. black boxed).

To be effective I would think they would need to be run
in the guest, but if DOM0 is timing out and returning
an I/O error then they well have to be adjusted there first.

dom0 (i.e. XenServer grumbles about paths going down, shows some I/O errors - that get re-tried, but doesn't invalidate the storage).

As soon as the paths are available again - you can see it re-attach to them.

Are these timeouts coming from Dom0 or from a VM in a DomU?

domU - as above, dom0 grumbles, but generally seems OK about things. dom0 doesn't do anything silly like invalidate the VM's disks or anything.

Windows has horrible long timeouts and large retry counts, and worse
they dont warn the user that it is having issues other than event logs
and things usually go to the state of drive catastrophic failure before
the user ever sees an error.

I can believe that - I've seen the figure of 60 seconds bandied around (as opposed to 30 seconds for Linux / FreeBSD).

Sadly, making FreeBSD have a similar timeout (at least just to test) may fix the issue.

-Karl
_______________________________________________
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Reply via email to