XenServer: INTERNAL_ERROR: Failure is already attached in RO mode it can’t be attached in RW mode

XenServer: INTERNAL_ERROR: Failure is already attached in RO mode it can’t be attached in RW mode



If you are receiving the following error in XenServer/XenCenter, there is a quick fix!

4/05/2011 4:05:40 PM Error: Migrating VM ’36’ from ‘blXXX’ to ‘blXXX’ – Internal error: INTERNAL_ERROR: [ Failure(“The VDI 996b046b-1960-4315-bad7-48830254d4c3 is already attached in RO mode; it can’t be attached in RW mode!”) ]

Or

5/05/2011 7:09:08 AM Error: Migrating VM ‘n3 – NTP’ from ‘blXXX’ to ‘blXXX’ – Internal error: INTERNAL_ERROR: [ Xb.Invalid ]

This can be fixed by running:

xe-toolstart-restart


 


Categories

  • Hi,

    Hopefully this failure mode should be completely gone in future versions. I’m currently working on this in the following development branch:

    https://github.com/djs55/xen-api/tree/CA-46505

    Your workaround is sensible in the meantime!

    Cheers,
    Dave Scott

  • Hi Dave,

    That’s great news! When will the official fix come out?

    Also I’ve been getting another error that I haven’t been able to find out much info regarding yet – is this related?

    5/05/2011 7:09:08 AM Error: Migrating VM ‘n3 – NTP’ from ‘blXXX’ to ‘blXXX’ – Internal error: INTERNAL_ERROR: [ Xb.Invalid ]

    I just came across this one a few minutes ago, and it seems my above temporary fix, fixes the solution.

    Regards,
    Aaron

  • Hi Aaron,

    I’m hoping to get the fix for the VDI issue into the next major product release. I think what’s happening is that there’s a transient glitch causing a “vdi_detach” (request to the “storage manager” to stop using a particular guest disk”) to fail. Unfortunately this leaves xapi in a state where it believes it can’t call “vdi_attach” again (because it’s still “attached”) but that it’s also attached in the wrong “mode” (RO vs RW). The storage layer is supposed not to let “vdi_detach” fail… but evidently it can still go wrong sometimes. So the fix is to help xapi keep track of the state of the disk and cause it to retry the “vdi_detach” rather than just giving up. This is part of a plan to make the whole system more robust and able to cope with errors, even those which aren’t supposed to happen 🙂

    I have to admit, I’ve no idea what’s causing the “Xb.Invalid” failure. It’s just possible that it’s related to the VDI issue but it seems a bit unlikely — “xb” in this context stands for “xenbus” as in the communication protocol used to talk to “xenstore”. Have you noticed any pattern, anything which makes the failure more likely?

    Cheers,
    Dave

  • Hi Dave,

    Good to hear about the upcoming improvements!

    I’ve also found another way around the “is already attached in RO mode; it can’t be attached in RW mode!” problem – in some instances it is possible to just start it on another blade/server and it seems to work without an issue.

    Regarding the “Xb.Invalid” – I do not have a solid way when it appears, however I have noticed it happen while waiting for HA to start VMs, and then manually starting VMs to speed up the process. It may have occurred other times, however I cannot recall. I’ve since been told from Citrix support, it is a very bad idea to manually start VMs while HA is doing its thing.

    Regards,
    Aaron

  • Hi Scott,

    Do you know if this was fixed in the FP2 release? I can see it just came out recently…

    This bug is starting seems to be causing us a fair amount of grief, it slows down a whole range of things including live migrations, HA VM start ups, etc.

    Is there any other fix our patch we can apply to fix this bug in the meantime?

    Regards,
    Aaron

  • Edgard Mota

    It’s xe-toolstack-restart, not xe-toolstart-restart. And, at least for me, it doesn’t work.