Re: [Xen-users] HVM domU on storage driver domain

["G.R." <firemeteor@xxxxxxxxxxxxxxxxxxxxx>]

On Tue, Feb 28, 2017 at 11:44 PM, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>> It's not clear to me what the time-outed watch is waiting for.
>> While the disk back-end is highly suspicious, the context in the
>> passing log looks more vif related.
>
> Neither to me, it seems like the stubdomain doesn't start correctly, but the
> stubdom log doesn't give any clues about what might cause it (or at least I'm
> not able to identify them). Can you please apply the following patch, try to
> create the domain (this time using the stubdom), and after 30s do `xenstore-ls
> -fp` in the Dom0 and paste the results here?
>
> This way I will know if the frontends in the stubdom have attached correctly.
>
Please find the requested log in the attachment.
I also attached the qemu log from the stubdomain. Not very interesting
from my POV, just for reference.

Quoting how VBDs are shown up on different domU.
It sounds like both are correctly connected, even though different
number of ring pages are used.
*xvda for the running FreeNAS domU:
/local/domain/1/device/vbd = ""   (n0,r1)
/local/domain/1/device/vbd/51712 = ""   (n1,r0)
/local/domain/1/device/vbd/51712/backend =
"/local/domain/0/backend/vbd/1/51712"   (n1,r0)
/local/domain/1/device/vbd/51712/backend-id = "0"   (n1,r0)
/local/domain/1/device/vbd/51712/state = "4"   (n1,r0)
/local/domain/1/device/vbd/51712/virtual-device = "51712"   (n1,r0)
/local/domain/1/device/vbd/51712/device-type = "disk"   (n1,r0)
/local/domain/1/device/vbd/51712/ring-ref0 = "768"   (n1,r0)
/local/domain/1/device/vbd/51712/ring-ref1 = "769"   (n1,r0)
/local/domain/1/device/vbd/51712/ring-ref2 = "770"   (n1,r0)
/local/domain/1/device/vbd/51712/ring-ref3 = "771"   (n1,r0)
/local/domain/1/device/vbd/51712/num-ring-pages = "4"   (n1,r0)
/local/domain/1/device/vbd/51712/ring-page-order = "2"   (n1,r0)
/local/domain/1/device/vbd/51712/event-channel = "8"   (n1,r0)
/local/domain/1/device/vbd/51712/protocol = "x86_64-abi"   (n1,r0)

*xvda for the ruibox-dm stubdomain:
/local/domain/3/device/vbd = ""   (n0,r3)
/local/domain/3/device/vbd/51712 = ""   (n3,r1)
/local/domain/3/device/vbd/51712/backend =
"/local/domain/1/backend/vbd/3/51712"   (n3,r1)
/local/domain/3/device/vbd/51712/backend-id = "1"   (n3,r1)
/local/domain/3/device/vbd/51712/state = "4"   (n3,r1)
/local/domain/3/device/vbd/51712/virtual-device = "51712"   (n3,r1)
/local/domain/3/device/vbd/51712/device-type = "disk"   (n3,r1)
/local/domain/3/device/vbd/51712/protocol = "x86_64-abi"   (n3,r1)
/local/domain/3/device/vbd/51712/ring-ref = "1789"   (n3,r1)
/local/domain/3/device/vbd/51712/event-channel = "5"   (n3,r1)


One interesting info is that failed stubdomain creation appears to
leave some trash in the system.
After some failed attempts, the storage driver domU stopped to response and the
xl -vvv create cannot proceed to 'Spawn device-model' step.
When doing xenstore-ls in that situation, I could find a long list of
VBDs in the FreeNAS domU's backend session.
After a reboot, everything backs to normal and I was able to collect
the attached log.

Attachment: store9
Description: Binary data

Attachment: qemu-dm-ruibox-dm.log
Description: Text Data

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