During our testing we have had this error pop up a few times while trying to start VMs after we have unplugged a blade without correctly shutting it down (simulating a failure scenario).
NOTE: This is the error that is shown in XenCenter while trying to start the VM.
4/05/2011 3:33:15 PM Error: Starting VM ’36′ – Internal error: another frontend device is already connected to this domain (frontend (domid=0 | kind=vbd | devid=51712); backend (domid=0 | kind=vbd | devid=51712))
It usually fixes itself if you wait a few hours or days, and attempt to start the VM again later. This however is not an ideal situation, as it means your VM is down until the error disappears.
I fixed this in one instance (have not tested again, as I’m waiting for the error to pop up again) by doing the following. This is for a VM with the name “36″:
[root@blXXX lib]# xe vbd-list vm-name-label=36
uuid ( RO) : f84cfbef-1054-f8e8-5d95-43587b63060a
vm-uuid ( RO): b7fa54cf-4cc7-ec1e-0310-27b629a83d30
vm-name-label ( RO): 36
vdi-uuid ( RO): <not in database>
empty ( RO): true
device ( RO): xvdd
uuid ( RO) : b4ff5293-46f6-6944-2b51-f5a0ea0aa92c
vm-uuid ( RO): b7fa54cf-4cc7-ec1e-0310-27b629a83d30
vm-name-label ( RO): 36
vdi-uuid ( RO): 996b046b-1960-4315-bad7-48830254d4c3
empty ( RO): false
device ( RO): xvda
[root@blXXX lib]#
As you can see the first VBD entry for this VM has:
vdi-uuid ( RO): <not in database>
By removing the VDB entry it seems to fix the problem:
[root@blXXX lib]# xe vbd-destroy uuid=f84cfbef-1054-f8e8-5d95-43587b63060a
I’ve seen some places have recommended using xenstore-ls and xenstore-rm the above method seems to work better – as the xenstore-rm command did not seem to address the issue.
UPDATE:
Upon further testing we found that if there are multiple entries with “vdi-uuid ( RO): <not in database>” in the vdb list for the VM – remove all of these.
--转自