So this server has been running for more then a year now, and I’m finding the throughput still slow.
We have SLES Dom0, with OES11 running as domu
Dom0 has a separate RAID, which is presented to the OES11 as Xen Block device.
On this block device the OES11 domu has created NSS volumes
When doing a server reboot the OES11, is taking forever to load the block device ( 5 minutes )
So I am thinking : what about Iscsi ?
So my question to you all is :
Can I turn the block device into a Isci share ?
Will the OES11 keep it’s NSS volumes ?
How is this best done ?
So this server has been running for more then a year now, and I’m
finding the throughput still slow.
We have SLES Dom0, with OES11 running as domu
Dom0 has a separate RAID, which is presented to the OES11 as Xen Block
device.
On this block device the OES11 domu has created NSS volumes[/color]
All of this seems quite normal
[color=blue]
When doing a server reboot the OES11, is taking forever to load the
block device ( 5 minutes )[/color]
This is the issue that needs to be investigated.[color=blue]
So I am thinking : what about Iscsi ?
So my question to you all is :
Can I turn the block device into a Isci share ?
Will the OES11 keep it’s NSS volumes ?
How is this best done ?[/color]
You should not make random changes to the system with the hope the
problem will be corrected.
The first step is to diagnose the cause:
We need to know what software versions you are running. On both Dom0
and DomU please run “cat /etc/*release”. Copy the output and paste it
into your reply using .
: When replying, click the “Go Advanced” button then click
on the “#” at the top of the reply window.
Look for any clues in /var/log/messages on both Dom0 and DomU.
Report any interesting messages the same way.
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
In /var/log/message, I could not find anything on this.
In startup log :
<6>[ 1.644885] xvdg: detected capacity change from 0 to 476999319552
<4>[ 6.565997] XENBUS: Waiting for devices to initialise: 295s…290s…285s…280s…275s…270s…265s…260s…255s…250s…245s…240s…235s…230s…225s…220s…215s…210s…205s…200s…195s…190s…185s…180s…175s…170s…165s…160s…155s…150s…145s…140s…135s…130s…125s…120s…115s…110s…105s…100s…95s…90s…85s…80s…75s…70s…65s…60s…55s…50s…45s…40s…35s…30s…25s…20s…15s…10s…5s…0s…
<4>[ 301.567897] XENBUS: Timeout connecting to device: device/vbd/51840 (local state 3, remote state 2)
<4>[ 301.570968] XENBUS: Device not ready: device/vbd/51840
Version virtual OES :
OES server
LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64"
Novell Open Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 0
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 1
Version Xen Host :
LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64"
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
Have you tried a Google search on “XENBUS: Waiting for devices to
initialise”? There are quite a few hits but I have no way to know if
one of them is your issue.
Current software releases are:
SLES11-SP3
OES11-SP1 on SLES11-SP2
They contain many bug fixes which may resolve your issue. Have you
considered upgrading to the current releases?
You said:[color=blue]
So this server has been running for more then a year now, and I’m
finding the throughput still slow.[/color]
Are you saying that this issue existed from the time your DomU was
initially configured?
If you running other DomUs, do any of them have similar issues?
Please run these commands on Dom0 and paste the output into your reply
using “code” tags.
fdisk -l
xm list
xm list -l <name of your OES11 DomU>
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Only updating the OES server did give a bad side effect.
So now the OES11 is booting without any issues,
but now the Gnome desktop looks screwed.
I cannot login. the login screen is shown, I login, it starts loading the desktop.
Somehow crashes and returns to the login screen.
Christmas time ; so finally some off time to check out what happened.
./xsession-errors shows :
/etc/X11/xim: Checking whether an input method should be started.
/etc/X11/xim: use GDM_LANG=nl_NL.UTF-8
sourcing /etc/sysconfig/language to get the value of INPUT_METHOD
INPUT_METHOD is not set or empty (no user selected input method).
Trying to start a default input method for the locale nl_NL.UTF-8 ...
There is no default input method for the current locale.
Dummy input method "none" (do not use any fancy input method by default)
/usr/bin/gpg-agent: symbol lookup error: /lib64/libgcrypt.so.11: undefined symbol: gpg_err_set_errno
Have no idea how to fix an input method …
Any help would be appreciated.
Stephan
[QUOTE=stelgenkamp;18261]Have found a TID on the subject http://www.novell.com/support/kb/doc.php?id=7013143
Will try that tomorrow.[/QUOTE]
not that I could have pointed you at that TID, but that error message caught my eye and made me more suspicious than the input device stuff. Looks to me like an upgrade problem, the TID is likely right on the spot.
However the : “XENBUS: Waiting for devices to initialise” ‘challenge’ has returned.
I assume this message appears inside DomU during boot and you have no access to /dev/xvdg from the DomU afterwards.
Any ideas ?
Is there anything helpful in the DomU log (on Dom0: /var/log/xen/qemu-dm-oes2l.log) or xend’s log (on Dom0: /var/log/xen/xend.log - search for the debug statements for your DomU’s creation: “XendDomainInfo.create([‘vm’, [‘name’, ‘oes2l’],…”)?
Yes the XENBUS: Waiting for devices to initialize, message appears on the Domu.
I do have access to the device afterwards, it just takes the server 5 extra minutes to boot
On the device are my nss volumes, and this is my ‘main’ server.
So all other servers, and virtual WS are logging into this server. However when this server takes 5 minutes to boot, the automatic logons I have created fail.
I have sifted through the logs, nothing in /var/log/xen/qemu-dm-oes2l.log
In /var/log/xen/xend.log :
[2013-12-26 21:40:30 11914] DEBUG (DevController:95) DevController: writing {'virtual-device': '51792', 'device-type': 'disk', 'protocol': 'x86_64-abi', 'backend-id': '0', 'state': '1', 'backend': '/local/domain/0/backend/vbd/27/51792'} to /local/domain/27/device/vbd/51792.
[2013-12-26 21:40:30 11914] DEBUG (DevController:97) DevController: writing {'domain': 'oes2l', 'frontend': '/local/domain/27/device/vbd/51792', 'uuid': '37784803-f92b-4880-3669-7e42ca00dfe8', 'bootable': '0', 'dev': 'xvdf', 'state': '1', 'params': '/dev/Linux/var', 'mode': 'w', 'online': '1', 'frontend-id': '27', 'type': 'phy'} to /local/domain/0/backend/vbd/27/51792.
[2013-12-26 21:40:30 11914] INFO (XendDomainInfo:2469) createDevice: vbd : {'uuid': 'ff66c73f-8c4f-1c37-8b66-cddce5f5cb51', 'bootable': 0, 'devid': 51808, 'driver': 'paravirtualised', 'dev': 'xvdg', 'uname': 'phy:/dev/sdb', 'mode': 'w'}
So no mention whatsoever concerning the XENBUS wait.
Anywhere else I can look ?
Stephan
while going through this thread I noticed that you initially quoted devid 51840 to fail; somewhere along you said it’s /dev/sdb - but your latest quote says that /dev/sdb (Dom0) is 51808.
Did the device instance, named in the DomU error message (" XENBUS: Device not ready: device/vbd/51840") change after upgrade?
Would you mind quoting the complete message sequence from xend.log when creating the DomU, plus the current DomU messages concerning the delay (and anything that appears in DomU’s “dmesg” around that delay)?
<6>[ 1.854068] xvdg: detected capacity change from 0 to 476999319552
<4>[ 6.728256] XENBUS: Waiting for devices to initialise: 295s...290s...285s.
..280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...2
25s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s
...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...
110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s..
.45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...
<4>[ 301.735243] XENBUS: Timeout connecting to device: device/vbd/51824 (local
state 3, remote state 2)
<4>[ 301.745724] XENBUS: Device not ready: device/vbd/51824
So it looks like 51824, i will check the xend.log for more info.
To Rick, Thanks for joining in :
No this is a raid disc, just presented to domu, but has difficulty loading.
Therefore the titel of the thread, if it would be possible to change this block device into an ISCSI.
Situation
When a VM is started it hits a 5 minute delay at:
XENBUS: Waiting for device to initialize: 295s…
If the VM has Open Enterprise Server (OES) installed and running NSS,
a corresponding entry in the message file may be:
jstcpd: Jet Stream starting with Connections NoActivity Timeout to be
300 seconds Resolution
Check the VM configuration to see if there is a virtual CDROM
attached with no actual media available at the location specified.
(path to iso image is wrong/unavailable or there is no DVD in the
device on the HOST).
Remove the virtual CDROM device from the VM.[/color]
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
