# Changing Block device to Iscsi ?

**URL:** <https://forums.suse.com/t/changing-block-device-to-iscsi/24855>\
**Category:** SLES Virtualization\
**Created:** [December 7, 2013, 9:56pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855 "2013-12-07T21:56:14Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![stelgenkamp](https://avatars.discourse-cdn.com/v4/letter/s/76d3ee/32.png) [@stelgenkamp](https://forums.suse.com/u/stelgenkamp)\
**Post date:** [December 7, 2013, 9:56pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/1 "2013-12-07T21:56:14Z")

</div>

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 ?

Thanks, Stephan

---

<div class="post-metadata">

**Author:** ![KEVIN1](https://avatars.discourse-cdn.com/v4/letter/k/a9adbd/32.png) [@KEVIN1](https://forums.suse.com/u/KEVIN1)\
**Post date:** [December 7, 2013, 10:40pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/2 "2013-12-07T22:40:03Z")

</div>

stelgenkamp wrote:  
[color=blue]

> 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:

1. 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…`

---

<div class="post-metadata">

**Author:** ![stelgenkamp](https://avatars.discourse-cdn.com/v4/letter/s/76d3ee/32.png) [@stelgenkamp](https://forums.suse.com/u/stelgenkamp)\
**Post date:** [December 12, 2013, 11:50am UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/3 "2013-12-12T11:50:20Z")

</div>

Dear Kevin,

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`

---

<div class="post-metadata">

**Author:** ![KEVIN1](https://avatars.discourse-cdn.com/v4/letter/k/a9adbd/32.png) [@KEVIN1](https://forums.suse.com/u/KEVIN1)\
**Post date:** [December 12, 2013, 9:07pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/4 "2013-12-12T21:07:21Z")

</div>

Hi Stephan,

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.

```auto
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…

---

<div class="post-metadata">

**Author:** ![stelgenkamp](https://avatars.discourse-cdn.com/v4/letter/s/76d3ee/32.png) [@stelgenkamp](https://forums.suse.com/u/stelgenkamp)\
**Post date:** [December 15, 2013, 9:03pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/5 "2013-12-15T21:03:43Z")

</div>

Right, have updated the Xen Server to SP3

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.

---

<div class="post-metadata">

**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\
**Post date:** [December 16, 2013, 3:45pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/6 "2013-12-16T15:45:18Z")

</div>

Hi Stephan,

> I cannot login. the login screen is shown, I login, it starts loading the desktop.  
> Somehow crashes and returns to the login screen.

Have you had a look at the ~/.xsession-errors-\* file(s), there might be some information on what program failed during desktop initialization.

Regards,  
Jens

---

<div class="post-metadata">

**Author:** ![stelgenkamp](https://avatars.discourse-cdn.com/v4/letter/s/76d3ee/32.png) [@stelgenkamp](https://forums.suse.com/u/stelgenkamp)\
**Post date:** [December 25, 2013, 1:55pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/7 "2013-12-25T13:55:40Z")

</div>

Christmas time ; so finally some off time to check out what happened.  
./xsession-errors shows :

```auto
/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

---

<div class="post-metadata">

**Author:** ![stelgenkamp](https://avatars.discourse-cdn.com/v4/letter/s/76d3ee/32.png) [@stelgenkamp](https://forums.suse.com/u/stelgenkamp)\
**Post date:** [December 25, 2013, 3:15pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/8 "2013-12-25T15:15:49Z")

</div>

Have found a TID on the subject  
[http://www.novell.com/support/kb/doc.php?id=7013143](http://www.novell.com/support/kb/doc.php?id=7013143)  
Will try that tomorrow.

---

<div class="post-metadata">

**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\
**Post date:** [December 25, 2013, 5:06pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/9 "2013-12-25T17:06:43Z")

</div>

Hi Stephan,

[QUOTE=stelgenkamp;18261]Have found a TID on the subject  
[http://www.novell.com/support/kb/doc.php?id=7013143](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.

Happy holidays,  
Jens

---

<div class="post-metadata">

**Author:** ![stelgenkamp](https://avatars.discourse-cdn.com/v4/letter/s/76d3ee/32.png) [@stelgenkamp](https://forums.suse.com/u/stelgenkamp)\
**Post date:** [December 27, 2013, 8:20pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/10 "2013-12-27T20:20:26Z")

</div>

OK, we’re back.  
Have solved the libcrypt ‘challenge’ and now are back in business.

However the : “XENBUS: Waiting for devices to initialise” ‘challenge’ has returned.

`(domain
    (domid 28)
    (cpu_weight 256)
    (cpu_cap 0)
    (pool_name Pool-0)
    (bootloader /usr/lib/xen/boot/domUloader.py)
    (vcpus 4)
    (cpus (() () () ()))
    (on_poweroff destroy)
    (description None)
    (on_crash destroy)
    (uuid ecf1c574-5b7b-d898-8415-9122fc4f513e)
    (bootloader_args '--entry=xvda1:/boot/vmlinuz-xen,/boot/initrd-xen')
    (name oes2l)
    (on_reboot restart)
    (maxmem 3072)
    (memory 3072)
    (shadow_memory 0)
    (features '')
    (on_xend_start ignore)
    (on_xend_stop ignore)
    (start_time 1388090521.29)
    (cpu_time 24261.1702008)
    (online_vcpus 4)
    (image
        (linux
            (kernel '')
            (args ' ')
            (superpages 0)
            (pci ())
            (localtime 0)
            (nomigrate 0)
            (tsc_mode 0)
            (device_model /usr/lib/xen/bin/qemu-dm)
            (notes
                (FEATURES
                    'writable_page_tables|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel'
                )
                (VIRT_BASE 18446744071562067968)
                (GUEST_VERSION 2.6)
                (PADDR_OFFSET 0)
                (GUEST_OS linux)
                (HYPERCALL_PAGE 18446744071562080256)
                (LOADER generic)
                (INIT_P2M 18446719884453740544)
                (SUSPEND_CANCEL 1)
                (ENTRY 18446744071562076160)
                (XEN_VERSION xen-3.0)
                (MOD_START_PFN 1)
                (SUPPORTED_FEATURES 2063)
            )
        )
    )
    (status 2)
    (state -b----)
    (store_mfn 8388923)
    (console_mfn 8388922)
    (device
        (vif
            (mac 00:16:3e:10:09:17)
            (script /etc/xen/scripts/vif-bridge)
            (uuid 340c40d7-ca68-9ce8-89be-34b6695c1dab)
            (backend 0)
        )
    )
    (device (vkbd (backend 0)))
    (device
        (tap
            (protocol x86_64-abi)
            (uuid 4f394d94-23af-09ff-5ca7-7437cb09b193)
            (bootable 0)
            (dev xvdh:cdrom)
            (uname
                tap:aio:/root/Installatie/OES11-SP1-addon_with_SLES11-SP2-x86_64-DVD.iso
            )
            (mode r)
            (backend 0)
            (VDI '')
        )
    )
    (device
        (console
            (protocol vt100)
            (location 2)
            (uuid d3773870-144f-a7ff-c443-b77012a5b695)
        )
    )
    (device
        (vbd
            (protocol x86_64-abi)
            (uuid 934b82e4-848b-067b-05f6-1997c848c332)
            (bootable 1)
            (dev xvda:disk)
            (uname phy:/dev/Linux/boot)
            (mode w)
            (backend 0)
            (VDI '')
        )
    )
    (device
        (vbd
            (protocol x86_64-abi)
            (uuid aa14a6f0-9a1f-f172-fead-976ad410742f)
            (bootable 0)
            (dev xvdb:disk)
            (uname phy:/dev/Linux/root)
            (mode w)
            (backend 0)
            (VDI '')
        )
    )
    (device
        (vbd
            (protocol x86_64-abi)
            (uuid 001faa38-93c5-c952-ce20-f821c190823f)
            (bootable 0)
            (dev xvdc:disk)
            (uname phy:/dev/Linux/swap)
            (mode w)
            (backend 0)
            (VDI '')
        )
    )
    (device
        (vbd
            (protocol x86_64-abi)
            (uuid 9d5c94c5-8538-f6a3-f3b9-1db33c79a9e8)
            (bootable 0)
            (dev xvdd:disk)
            (uname phy:/dev/Linux/opt)
            (mode w)
            (backend 0)
            (VDI '')
        )
    )
    (device
        (vbd
            (protocol x86_64-abi)
            (uuid af5a5d8c-a878-49f8-ee36-63a74c781f07)
            (bootable 0)
            (dev xvde:disk)
            (uname phy:/dev/Linux/home)
            (mode w)
            (backend 0)
            (VDI '')
        )
    )
    (device
        (vbd
            (protocol x86_64-abi)
            (uuid 37784803-f92b-4880-3669-7e42ca00dfe8)
            (bootable 0)
            (dev xvdf:disk)
            (uname phy:/dev/Linux/var)
            (mode w)
            (backend 0)
            (VDI '')
        )
    )
    (device
        (vbd
            (protocol x86_64-abi)
            (uuid ff66c73f-8c4f-1c37-8b66-cddce5f5cb51)
            (bootable 0)
            (dev xvdg:disk)
            (uname phy:/dev/sdb)
            (mode w)
            (backend 0)
            (VDI '')
        )
    )
    (device
        (vbd
            (protocol x86_64-abi)
            (uuid eacb8f4b-ad49-b844-1d38-6a03efb98443)
            (bootable 0)
            (dev xvdi:cdrom)
            (uname phy:/dev/sr0)
            (mode r)
            (backend 0)
            (VDI '')
        )
    )
    (device
        (vfb
            (vncunused 1)
            (keymap en-us)
            (vnc 1)
            (uuid 73f26216-6efa-2bad-741c-ce83b198fb43)
            (location 127.0.0.1:5902)
        )
    )
)
`

The device which is showing the XENBUS wait is : phy:/dev/sdb  
This is a separate raid-5 on my xen host.  
Any ideas ?

---

<div class="post-metadata">

**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\
**Post date:** [December 28, 2013, 1:39am UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/11 "2013-12-28T01:39:16Z")

</div>

Hi Stephan,

> 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’],…”)?

Regards,  
Jens

---

<div class="post-metadata">

**Author:** ![stelgenkamp](https://avatars.discourse-cdn.com/v4/letter/s/76d3ee/32.png) [@stelgenkamp](https://forums.suse.com/u/stelgenkamp)\
**Post date:** [December 28, 2013, 2:01pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/12 "2013-12-28T14:01:47Z")

</div>

Hello Jens,

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

---

<div class="post-metadata">

**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\
**Post date:** [December 28, 2013, 3:40pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/13 "2013-12-28T15:40:44Z")

</div>

Hi 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)?

Regards,  
Jens

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex022/uploads/suse/original/2X/5/5012ba89e3ffb5220dac47d5ea0ba032e2fe1cb6.png) [@system](https://forums.suse.com/u/system)\
**Post date:** [December 28, 2013, 3:45pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/14 "2013-12-28T15:45:42Z")

</div>

stelgenkamp wrote:  
[color=blue]

> OK, we’re back.  
> Have solved the libcrypt ‘challenge’ and now are back in business.
> 
> However the : “XENBUS: Waiting for devices to initialise” ‘challenge’  
> has returned.
> 
> ## Code:
> 
> ```
> (domain
> 
> ```
> 
> (domid 28)  
> (cpu\_weight 256)  
> (cpu\_cap 0)  
> (pool\_name Pool-0)  
> (bootloader /usr/lib/xen/boot/domUloader.py)  
> (vcpus 4)  
> (cpus (() () () ()))  
> (on\_poweroff destroy)  
> (description None)  
> (on\_crash destroy)  
> (uuid ecf1c574-5b7b-d898-8415-9122fc4f513e)  
> (bootloader\_args ‘–entry=xvda1:/boot/vmlinuz-xen,/boot/initrd-xen’)  
> (name oes2l)  
> (on\_reboot restart)  
> (maxmem 3072)  
> (memory 3072)  
> (shadow\_memory 0)  
> (features ‘’)  
> (on\_xend\_start ignore)  
> (on\_xend\_stop ignore)  
> (start\_time 1388090521.29)  
> (cpu\_time 24261.1702008)  
> (online\_vcpus 4)  
> (image  
> (linux  
> (kernel ‘’)  
> (args ’ ')  
> (superpages 0)  
> (pci ())  
> (localtime 0)  
> (nomigrate 0)  
> (tsc\_mode 0)  
> (device\_model /usr/lib/xen/bin/qemu-dm)  
> (notes  
> (FEATURES  
> ‘writable\_page\_tables|writable\_descriptor\_tables|[/color]  
> auto\_translated\_physmap|supervisor\_mode\_kernel’[color=blue]  
> )  
> (VIRT\_BASE 18446744071562067968)  
> (GUEST\_VERSION 2.6)  
> (PADDR\_OFFSET 0)  
> (GUEST\_OS linux)  
> (HYPERCALL\_PAGE 18446744071562080256)  
> (LOADER generic)  
> (INIT\_P2M 18446719884453740544)  
> (SUSPEND\_CANCEL 1)  
> (ENTRY 18446744071562076160)  
> (XEN\_VERSION xen-3.0)  
> (MOD\_START\_PFN 1)  
> (SUPPORTED\_FEATURES 2063)  
> )  
> )  
> )  
> (status 2)  
> (state -b----)  
> (store\_mfn 8388923)  
> (console\_mfn 8388922)  
> (device  
> (vif  
> (mac 00:16:3e:10:09:17)  
> (script /etc/xen/scripts/vif-bridge)  
> (uuid 340c40d7-ca68-9ce8-89be-34b6695c1dab)  
> (backend 0)  
> )  
> )  
> (device (vkbd (backend 0)))  
> (device  
> (tap  
> (protocol x86\_64-abi)  
> (uuid 4f394d94-23af-09ff-5ca7-7437cb09b193)  
> (bootable 0)  
> (dev xvdh:cdrom)  
> (uname  
> tap:aio:/root/Installatie/OES11-SP1-addon\_with\_SLES11-SP2-x86\_64-DVD.iso  
> )  
> (mode r)  
> (backend 0)  
> (VDI ‘’)  
> )  
> )  
> (device  
> (console  
> (protocol vt100)  
> (location 2)  
> (uuid d3773870-144f-a7ff-c443-b77012a5b695)  
> )  
> )  
> (device  
> (vbd  
> (protocol x86\_64-abi)  
> (uuid 934b82e4-848b-067b-05f6-1997c848c332)  
> (bootable 1)  
> (dev xvda:disk)  
> (uname phy:/dev/Linux/boot)  
> (mode w)  
> (backend 0)  
> (VDI ‘’)  
> )  
> )  
> (device  
> (vbd  
> (protocol x86\_64-abi)  
> (uuid aa14a6f0-9a1f-f172-fead-976ad410742f)  
> (bootable 0)  
> (dev xvdb:disk)  
> (uname phy:/dev/Linux/root)  
> (mode w)  
> (backend 0)  
> (VDI ‘’)  
> )  
> )  
> (device  
> (vbd  
> (protocol x86\_64-abi)  
> (uuid 001faa38-93c5-c952-ce20-f821c190823f)  
> (bootable 0)  
> (dev xvdc:disk)  
> (uname phy:/dev/Linux/swap)  
> (mode w)  
> (backend 0)  
> (VDI ‘’)  
> )  
> )  
> (device  
> (vbd  
> (protocol x86\_64-abi)  
> (uuid 9d5c94c5-8538-f6a3-f3b9-1db33c79a9e8)  
> (bootable 0)  
> (dev xvdd:disk)  
> (uname phy:/dev/Linux/opt)  
> (mode w)  
> (backend 0)  
> (VDI ‘’)  
> )  
> )  
> (device  
> (vbd  
> (protocol x86\_64-abi)  
> (uuid af5a5d8c-a878-49f8-ee36-63a74c781f07)  
> (bootable 0)  
> (dev xvde:disk)  
> (uname phy:/dev/Linux/home)  
> (mode w)  
> (backend 0)  
> (VDI ‘’)  
> )  
> )  
> (device  
> (vbd  
> (protocol x86\_64-abi)  
> (uuid 37784803-f92b-4880-3669-7e42ca00dfe8)  
> (bootable 0)  
> (dev xvdf:disk)  
> (uname phy:/dev/Linux/var)  
> (mode w)  
> (backend 0)  
> (VDI ‘’)  
> )  
> )  
> (device  
> (vbd  
> (protocol x86\_64-abi)  
> (uuid ff66c73f-8c4f-1c37-8b66-cddce5f5cb51)  
> (bootable 0)  
> (dev xvdg:disk)  
> (uname phy:/dev/sdb)  
> (mode w)  
> (backend 0)  
> (VDI ‘’)  
> )  
> )  
> (device  
> (vbd  
> (protocol x86\_64-abi)  
> (uuid eacb8f4b-ad49-b844-1d38-6a03efb98443)  
> (bootable 0)  
> (dev xvdi:cdrom)  
> (uname phy:/dev/sr0)  
> (mode r)  
> (backend 0)  
> (VDI ‘’)  
> )  
> )  
> (device  
> (vfb  
> (vncunused 1)  
> (keymap en-us)  
> (vnc 1)  
> (uuid 73f26216-6efa-2bad-741c-ce83b198fb43)  
> (location 127.0.0.1:5902)  
> )  
> )  
> )
> 
> * * *
> 
> The device which is showing the XENBUS wait is : phy:/dev/sdb  
> This is a separate raid-5 on my xen host.  
> Any ideas ?
> 
> [/color]

I know I am popping in her late? May I ask is if phy:/dev/sdb is in fact an  
iscsi device? Is this an ncs setup?

---

<div class="post-metadata">

**Author:** ![stelgenkamp](https://avatars.discourse-cdn.com/v4/letter/s/76d3ee/32.png) [@stelgenkamp](https://forums.suse.com/u/stelgenkamp)\
**Post date:** [December 29, 2013, 7:26pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/15 "2013-12-29T19:26:15Z")

</div>

Hello Jens,  
To check :

`<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.

Stephan

---

<div class="post-metadata">

**Author:** ![stelgenkamp](https://avatars.discourse-cdn.com/v4/letter/s/76d3ee/32.png) [@stelgenkamp](https://forums.suse.com/u/stelgenkamp)\
**Post date:** [December 29, 2013, 10:26pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/16 "2013-12-29T22:26:05Z")

</div>

Xend log shows :

`[2013-12-28 16:48:40 6126] INFO (XendDomainInfo:2479) createDevice: vbd : {'uuid': '59077e20-41e7-8526-4859-25f56c6899d7', 'bootable': 0, 'driver': 'paravirtualised', 'dev': 'xvdg', 'uname': 'phy:/dev/sdb', 'mode': 'w'}
[2013-12-28 16:48:40 6126] DEBUG (DevController:95) DevController: writing {'virtual-device': '51808', 'device-type': 'disk', 'protocol': 'x86_64-abi', 'backend-id': '0', 'state': '1', 'backend': '/local/domain/0/backend/vbd/4/51808'} to /local/domain/4/device/vbd/51808.
[2013-12-28 16:48:40 6126] DEBUG (DevController:97) DevController: writing {'domain': 'oes2l', 'frontend': '/local/domain/4/device/vbd/51808', 'uuid': '59077e20-41e7-8526-4859-25f56c6899d7', 'bootable': '0', 'dev': 'xvdg', 'state': '1', 'params': '/dev/sdb', 'mode': 'w', 'online': '1', 'frontend-id': '4', 'type': 'phy'} to /local/domain/0/backend/vbd/4/51808.`

So could that be the problem ? That it links to a different backend ?  
Ok, so know how do I fix it ?

---

<div class="post-metadata">

**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\
**Post date:** [December 29, 2013, 11:12pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/17 "2013-12-29T23:12:48Z")

</div>

Hi Stephan,

it does look strange - is that ID available somewhere in Dom0’s config? Probably configured for this DomU? Or does that ID exist nowhere in Dom0?

It might be useful to post a collection of all log entries (xend, domu syslog/dmesg, actual DomU config) rather than excerpts.

Regards,  
Jens

---

<div class="post-metadata">

**Author:** ![KEVIN1](https://avatars.discourse-cdn.com/v4/letter/k/a9adbd/32.png) [@KEVIN1](https://forums.suse.com/u/KEVIN1)\
**Post date:** [December 29, 2013, 11:34pm UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/18 "2013-12-29T23:34:05Z")

</div>

stelgenkamp wrote:  
[color=blue]

> However the : “XENBUS: Waiting for devices to initialise” ‘challenge’  
> has returned.[/color]

I see you have a CDROM and the SLES11-SP2/OES11-SP1 DVD attached to  
your DomU. Have you seen this?

TID 7014030 - XENBUS: Waiting for device to initialize: 295s…  
[http://www.novell.com/support/kb/doc.php?id=7014030](http://www.novell.com/support/kb/doc.php?id=7014030)

[color=blue]

> 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…

---

<div class="post-metadata">

**Author:** ![stelgenkamp](https://avatars.discourse-cdn.com/v4/letter/s/76d3ee/32.png) [@stelgenkamp](https://forums.suse.com/u/stelgenkamp)\
**Post date:** [July 26, 2014, 11:32am UTC](https://forums.suse.com/t/changing-block-device-to-iscsi/24855/19 "2014-07-26T11:32:45Z")

</div>

Old post, but indeed Kevin, removing tge cd rom fixes the problem