I have created an vmdk image to give it a shot as opposed my broken qcow images. (I cannot convert them back to raw) The strange thing is that it is opened in the backend, but doesn''t show up in the frontend: Backend: Jul 26 14:14:24 xenapi BLKTAPCTRL[2993]: Generated cookie, 1 Jul 26 14:14:24 xenapi TAPDISK[3412]: Tapdisk: Received msg, len 43, type 1, UID 1 Jul 26 14:14:24 xenapi TAPDISK[3412]: Received CTLMSG_PARAMS: [/mnt/netapp/test/test.vmdk] Jul 26 14:14:25 xenapi TAPDISK[3412]: Loaded driver: name [tapdisk_vmdk], type [2] Jul 26 14:14:25 xenapi TAPDISK[3412]: open(/mnt/netapp/test/test.vmdk) with O_DIRECT Jul 26 14:14:25 xenapi TAPDISK[3412]: VMDK File opened successfully Jul 26 14:14:25 xenapi TAPDISK[3412]: Adding fd_list_entry Jul 26 14:14:25 xenapi TAPDISK[3412]: Entered cookie 1 Jul 26 14:14:25 xenapi BLKTAPCTRL[2993]: Received CTLMSG_IMG: 16777216, 0, 0 Jul 26 14:14:25 xenapi BLKTAPCTRL[2993]: Received a poll for a new devmap Jul 26 14:14:25 xenapi BLKTAPCTRL[2993]: Write_msg called: CTLMSG_NEWDEV Jul 26 14:14:25 xenapi TAPDISK[3412]: Tapdisk: Received msg, len 20, type 4, UID 1 Jul 26 14:14:25 xenapi TAPDISK[3412]: Retrieving state, cookie 1.....[OK] Jul 26 14:14:25 xenapi BLKTAPCTRL[2993]: Received CTLMSG_NEWDEV_RSP Jul 26 14:14:25 xenapi BLKTAPCTRL[2993]: Exiting map_new_blktapctrl Inside the VM: xvdb:<4>XENBUS: Timeout connecting to device: device/vif/0 (state 1) With this I can also conclude that my VIF is not working; that seems to be like cascade bugs... After these events the complete management is fubar, destroy keeps open (one/two) tapdisk instances. And makes the machine to reboot. Without the VMDK image everything seems to works ''normal''. Stefan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users