Custom Query (16363 matches)
Results (1597 - 1599 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #8292 | obsolete | iSCSI timeout causes bad VBoxHeadless behaviour | ||
| Description |
I have an iSCSI server which some times takes a little too long to respond to iSCSI requests. Most of the time, VB pauses the affected VMs. However, sometimes instead of pause VB will power-off the VM but not complete the power-off. I wonder why it decides to power-off rather than pause - is this a bug or intended? In case it is intended, there still is a bug: What happens is that I have a VBoxHeadless process running, but the VM state is set to "powered off". Since I cannot power it off using VBoxManage (cannot power-off a powered-off VM), there is no VB interface to properly power off the VM. I shouldn't need one either - if the state is powered-off, the VBoxHeadless process should not be there at all. The only "solution" I have is to kill the VBoxHeadless process. This can't be right. Host details; IBM HS22 blade with 8 (HT) cores and 32G memory running Solaris 10 update 9 and VirtualBox 4.0.2. The VB log from the time this happens says: 306:50:47.638 iSCSI: login to target iqn.1986-03.com.sun:02:33f117f0-be5b-6a82-ab92-fa9aa4bd65ea failed 306:50:47.638 I/O cache: Error while writing entry at offset 38037016064 (4096 bytes) to medium "ahci-0-0" (rc=VERR_BROKEN_PIPE) 306:50:47.638 VM: Raising runtime error 'BLKCACHE_IOERR' (fFlags=0x6) 306:50:47.638 I/O cache: Error while writing entry at offset 37954772480 (12288 bytes) to medium "ahci-0-0" (rc=VERR_BROKEN_PIPE) 306:50:47.638 Changing the VM state from 'RUNNING' to 'SUSPENDING'. 306:50:47.639 I/O cache: Error while writing entry at offset 18555645440 (4096 bytes) to medium "ahci-0-0" (rc=VERR_BROKEN_PIPE) 306:50:47.639 I/O cache: Error while writing entry at offset 18555633152 (4096 bytes) to medium "ahci-0-0" (rc=VERR_BROKEN_PIPE) 306:50:47.639 I/O cache: Error while writing entry at offset 38037044736 (49152 bytes) to medium "ahci-0-0" (rc=VERR_BROKEN_PIPE) 306:50:47.639 I/O cache: Error while writing entry at offset 38077488640 (8192 bytes) to medium "ahci-0-0" (rc=VERR_BROKEN_PIPE) 306:50:47.639 I/O cache: Error while writing entry at offset 38037020160 (24576 bytes) to medium "ahci-0-0" (rc=VERR_BROKEN_PIPE) 306:50:47.639 I/O cache: Error while writing entry at offset 18555698688 (20480 bytes) to medium "ahci-0-0" (rc=VERR_NET_CONNECTION_REFUSED) 328:19:30.594 VirtualBoxClient: detected unresponsive VBoxSVC (rc=NS_ERROR_CALL_FAILED) 328:19:30.594 VBoxHeadless: VBoxSVC became unavailable, exiting. 328:19:30.594 Console::powerDown(): A request to power off the VM has been issued (mMachineState=Running, InUninit=1) 328:19:30.594 VRDP: TCP server closed. 328:20:00.604 VirtualBoxClient: detected working VBoxSVC (rc=NS_OK) The VM no longer appears under "VBoxManage list runningvms". However, a "ps" will still show a VBoxHeadless process for this VM. A VBoxManage to inquire for state says: $ VBoxManage showvminfo ...|grep tate State: powered off (since 2011-01-24T14:03:54.000000000) It seems to me that the poweroff stops half way through. If only it could go all the way, the Solaris SMF would discover this and restart my VM. |
|||
| #5485 | obsolete | iSCSI initiator name not accepted on NetApp web interface | ||
| Description |
The VirtualBox default initiator name is not accepted by the NetApp webinterface, in the log I find: Tue Nov 17 13:35:45 CET [iscsi.notice:notice]: ISCSI: New session from initiator iqn.2008-04.com.sun.virtualbox.initiator at IP addr 192.168.96.15 Tue Nov 17 13:35:45 CET [iscsi.protocol.violation:warning]: ISCSI: iSCSI protocol violation, 'cmd_sn mismatch: exp 1, got 4, cmd: SCSI_CMD' Tue Nov 17 13:35:47 CET [iscsi.protocol.violation:warning]: ISCSI: iSCSI protocol violation, 'cmd_sn mismatch: exp 1, got 4, cmd: SCSI_CMD' Tue Nov 17 13:35:50 CET [iscsi.notice:notice]: ISCSI: New session from initiator iqn.2008-04.com.sun.virtualbox.initiator at IP addr 192.168.96.15 Tue Nov 17 13:35:50 CET [iscsi.protocol.violation:warning]: ISCSI: iSCSI protocol violation, 'cmd_sn mismatch: exp 1, got 4, cmd: SCSI_CMD' Tue Nov 17 13:35:53 CET [iscsi.notice:notice]: ISCSI: New session from initiator iqn.2008-04.com.sun.virtualbox.initiator at IP addr 192.168.96.15 Tue Nov 17 13:35:53 CET [iscsi.protocol.violation:warning]: ISCSI: iSCSI protocol violation, 'cmd_sn mismatch: exp 1, got 4, cmd: SCSI_CMD' It is possible to attach it on the NetApp command line though, but the log still complains. |
|||
| #11711 | invalid | iSCSI error "VD: error VERR_IO_GEN_FAILURE opening image file..." | ||
| Description |
My system is a Win7 x64 and iSCSI targets on synology DS410. I can use this iSCSI targets on my Win7 fine. I create a VM with GUI and add the iSCSI lun with cli with no errors on this step VBoxManage.exe storageattach "WinXPold" --storagectl "IDE" --port 0 --device 0 --type hdd --medium iscsi --server "192.168.123.251" --target "iqn.2000-01:Nordpol:XPboot" when i show hdd info, i get "inaccessible", why??? C:\Program Files\Oracle\VirtualBox>VBoxManage.exe list hdds UUID: 7b7f2203-3f4b-4589-a946-630db13824ab Parent UUID: base Format: iSCSI Location: 192.168.123.251|iqn.2000-01:Nordpol:XPboot State: inaccessible Type: normal Usage: WinXPold (UUID: 3cc2f25b-80be-4ef1-afda-701949d97d4f) C:\Program Files\Oracle\VirtualBox>VBoxManage.exe showhdinfo 7b7f2203-3f4b-4589- a946-630db13824ab UUID: 7b7f2203-3f4b-4589-a946-630db13824ab Accessible: no Access Error: Could not open the medium '192.168.123.251|iqn.2000-01:Nordpol:XPboot'. VD: error VERR_IO_GEN_FAILURE opening image file '192.168.123.251|iqn.2000-01:Nordpol:XPboot' (VERR_IO_GEN_FAILURE) Logical size: 0 MBytes Current size on disk: 0 MBytes Type: normal (base) Storage format: iSCSI Format variant: dynamic default In use by VMs: WinXPold (UUID: 3cc2f25b-80be-4ef1-afda-701949d97d4f) Location: 192.168.123.251|iqn.2000-01:Nordpol:XPboot |
|||

