Re: Windows domu DRBD backend problem

["Tu Dinh" <ngoc-tu.dinh@xxxxxxxxxx>]

Hi Attila,

On 09/05/2025 11:55, Kotán Attila wrote:
> Hello Tu Dinh,
>
> I created an debug environment for Qemu, but the Qemu debug not provide
> any info after the XEn drivers loaded in windows.
>
> Then i make an windbg connection to Domu and try to DEbug with windbg.
>
> When the DRBD backend status is change the following DEBUG info coming
> to windbg:
>
> -----
> xenvbd|TargetReset:[0] =====>
> xenvbd|__FrontendSetState:Target[0] : ENABLED ----> CONNECTED
> xenvbd|__BlkifRingCompleteResponse:Target[0][0] : WRITE BLKIF_RSP_ERROR
> xenvbd|__FrontendSetState:Target[0] : in state CONNECTED
> xenvbd|__FrontendSetState:Target[0] : CONNECTED ----> ENABLED
> xenvbd|__FrontendSetState:Target[0] : in state ENABLED
> xenvbd|TargetReset:[0] <=====
> xenvbd|__BlkifRingCompleteResponse:Target[0][0] : WRITE BLKIF_RSP_ERROR
> Terminating critical process 0xFFFFD18EFF72A140 (services.exe)
> -----
>
> It was a very difficult to make the Debug environment for me.
>
> I really don't understand why detecting the xenvbd driver the DRBD
> status change.
>
> If you need more debug info, then please instruct me about how can i got
> it from windbg.
>
> Thank you and best regards.
>
> Attila
>

The Windows guest kernel log is what I was looking for. The
xen_platform_log feature of QEMU should give you the same log as Windbg
while being easier to set up.

 From the log you posted, it looks like Windows tried to reset the
virtual block device when an I/O failed during a failover, and this got
stuck somewhere.

Do you have the Windows kernel thread stack trace at the time of hang,
as well as the VM and backend's Xenstore states? You can use
`xenstore-ls` on the host, or force a BSOD with Windbg which will cause
Xen drivers to spew this information onto xen_platform_log.

Best regards,


 | Vates

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech