Re: [Xen-users] PV DomU can't access disk from storage driver domain

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

El 18/09/15 a les 20.34, Alex Velazquez ha escrit:
> On Fri, Sep 18, 2015 at 1:28 PM, Roger Pau Monnà <roger.pau@xxxxxxxxxx> wrote:
>> El 18/09/15 a les 16.54, Alex Velazquez ha escrit:
>>> Hi Roger,
>>>
>>> Thanks for your reply. I got a bit further now, but still hit some errors.
>>>
>>> First, as you suggested, I started the xendriverdomain service via the
>>> init script (and have it start automatically on boot). "xl devd"
>>> starts as expected and creates a log file at /var/log/xen/xldevd.log.
>>>
>>> When I start the client DomU, it receives the disk and is able to boot
>>> from it. I can even log in, if I do it quickly. However, after a few
>>> seconds, the client locks up and I see this printed to the console:
>>>
>>>  [    9.938197] vbd vbd-51712: 16 Device in use; refusing to close
>>>  [    9.938524] vbd vbd-51712: failed to write error node for
>>> device/vbd/51712 (16 Device in use; refusing to close)
>>
>> Can you print the xenstore related entries at this point (for both the
>> frontend and the backend)?
>>
>> It's quite strange that a disk successfully connects and then
>> disconnects without any apparent reason. Does the kernel log (dmesg) in
>> the driver domain contain any hint about why it was disconnected?
>>
>> Roger.
>>
> 
> 
> The last few lines in storagedd's kernel log are:
> 
>  admin@storagedd:~$ sudo dmesg
>  [....]
>  [    4.012464] init: plymouth-upstart-bridge main process (163)
> killed by TERM signal
>  [    5.561811] init: plymouth-splash main process (1078) terminated
> with status 1
>  [   48.847611] xen-blkback:ring-ref 2047, event-channel 4, protocol 1
> (x86_64-abi)
>  [   52.758780] xen-blkback:backend/vbd/9/51712: prepare for reconnect
>  [   52.927883] xen-blkback:ring-ref 8, event-channel 10, protocol 1
> (x86_64-abi) persistent grants
> 
> While the client is booting, the backend entry appears in xenstore, as such:
> 
>  xenuser@xenhost:~$ sudo xenstore-ls /local/domain/2/backend
>  vbd = ""
>   3 = ""
>    51712 = ""
>     frontend = "/local/domain/3/device/vbd/51712"
>     params = "/dev/loop0"
>     script = "/etc/xen/scripts/block"
>     frontend-id = "3"
>     online = "1"
>     removable = "0"
>     bootable = "1"
>     state = "4"
>     dev = "xvda"
>     type = "phy"
>     mode = "w"
>     device-type = "disk"
>     discard-enable = "1"
>     physical-device = "7:0"
>     hotplug-status = "connected"
>     feature-flush-cache = "1"
>     discard-granularity = "4096"
>     discard-alignment = "0"
>     discard-secure = "0"
>     feature-discard = "1"
>     feature-barrier = "1"
>     feature-persistent = "1"
>     feature-max-indirect-segments = "256"
>     sectors = "25165824"
>     info = "0"
>     sector-size = "512"
>     physical-sector-size = "512"
> 
> However, interestingly, it clears out after a few seconds:
> 
>  xenuser@xenhost:~$ sudo xenstore-ls /local/domain/2/backend
>  backend = ""
>   vbd = ""
>    3 = ""

That's not expected, can you enable xenstored trace in order to know who
is cleaning this directory?

On Debian systems you can enable xenstored tracing in the
/etc/default/xencommons file.

Roger.


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users