Error when creating new iSCSI media

[NMe]

VBox v 6.1.14 r 140239
Host : W10 Pro
Guest : W10 Pro
Hello,
I use iSCSI media in my guests for local backups in the VMs. Then LUNs are backuped by the server. Simple, effective and reliable.
My server crashed a few days, and I must rebuild the system with a new one.
But I did two mistakes successively :
- 1st : I defined the iSCSI target with CHAP authenfication, but forgot to specify --name and -- password in the vboxmanage storageattach command; did not see it, and launched the VM : after a long time, activation was 20%, and VirtualBox and VM preview did not answer mouse or keyboard. I had to shut down them with host Windows Tasks Manager. I suppressed the target in the VM configuration and (fortunately!) recover it. But, in VirtualBox Media Manager, the target was impossible to delete or modify, blocked in state "non connected, actualize". The command line vboxmanage list hdds did not work either properly, stay unfinished, and I had to close Windows command with Tasks Manager again. I thought it was a matter of file locked ;
- 2nd : I redefined a new target in the server, without CHAP, but I launched an intermediate vboxmanage storageattach command WITH --name and --password specified. Same results ...
So, now, I have 2 durty lines in VirtualBox Media Manager (the 2 last lines) than I can not delete or modify.
What can I do to restore a clean state, then redo properly operations ?
Thank you a lot.
NMe

[scottgus1]

Interesting choice of obfuscation... How are folks supposed to hack into your computer just by knowing the names of your guest disk files?

If you cannot select the offending lines and click Suprimmer or Liberer, then right-click the guest in the main Virtualbox window's guest list, choose Show in Explorer. Zip the guest's .vbox file, and post the zip file, using the forum's Upload Attachment tab.

Also provide C:\Users\{you}\.Virtualbox\Virtualbox.xml, zipped.

And please don't obfuscate anything. It may be possible for us to remove these problem 'disks' and provide a drop-in replacement for your existing xml files as a fix. If anything is changed or masked the drop-in replacement will fail. If there are obfuscations we won't know what to fix and might have to turn away from this topic.

[NMe]

Vbox.zip

Virtualbox.xml and NMPHOTO_W7x64Pro.vbox

(4.4 KiB) Downloaded 5 times

Thanks for answer.
Sorry for obfuscation ... Printscreen was only to show offending lines.
Please find attached the two files, zipped.
NMe

[scottgus1]

The two trouble-causing drives are in the guest's .vbox file:

<HardDisks>
<HardDisk uuid="{8ecc21d8-f45b-48ae-85e4-681663c7bc8c}" location="E:/PersonnalData/Noël_2/VirtualBox_VMs/NMPHOTO_W7x64Pro/NMPHOT5_W7S_HDWR.vdi" format="VDI" type="Normal"/>
<HardDisk uuid="{f7ee370e-1e43-4e0c-b00d-29d7f14db644}" location="192.168.33.92|iqn.2020-10.com.nmetsqa:SYNL920PFAV.Target-1.c85693974ee" format="iSCSI" type="Normal">
<Property name="TargetAddress" value="192.168.33.92:3260"/>
<Property name="TargetName" value="iqn.2020-10.com.nmetsqa:SYNL920PFAV.Target-1.c85693974ee"/>
</HardDisk>
<HardDisk uuid="{62f5f82b-9234-44d7-bdec-52bc79f7dbb2}" location="192.168.33.92|iqn.2020-10.com.nmetsqa:SYNL920PFAV.Target-1a.c85693974ee" format="iSCSI" type="Normal">
<Property name="TargetAddress" value="192.168.33.92:3260"/>
<Property name="TargetName" value="iqn.2020-10.com.nmetsqa:SYNL920PFAV.Target-1a.c85693974ee"/>
</HardDisk>
</HardDisks>

The attached zip removes the two drives leaving the normal guest drive:

<HardDisks>
<HardDisk uuid="{8ecc21d8-f45b-48ae-85e4-681663c7bc8c}" location="E:/PersonnalData/Noël_2/VirtualBox_VMs/NMPHOTO_W7x64Pro/NMPHOT5_W7S_HDWR.vdi" format="VDI" type="Normal"/>
</HardDisks>

Reboot your host PC so no Virtualbox processes are running.

In the guest folder, rename your existing 'NMPHOTO_W7x64Pro.vbox' to 'NMPHOTO_W7x64Pro.vbox-extradrives', then put the zipped 'NMPHOTO_W7x64Pro.vbox' into the guest folder.

Now start Virtualbox. The extra drives should be gone.

[NMe]

Hello,
Thank you for correction. No more extras drives.
Before I do a new mistake ..., please confirm procedure :
1/Define and create a target of the server without (or with CHAP authentification) ;
2/Execute vboxmanage storageattach "target to VM", no paramater --name and --password (ou --name and --password filled consistent with server specifications) ;
3/Control new VM storage parameters in VirtualBox GUI ;
4/Start VM : after actualization period VM opens (how long the actualization period for virtual size 450 Go, actual size 180 Go ?) ;
5/In the VM I must see backup datas in a new volume.
My last previous experience was with a new empty LUN, not with a filled backup one : I do not want to start an automatic format operation !
Thank you again,
NMe

[scottgus1]

I regret I have never tried iSCSI. I'd recommend you start a new topic calling out that you need the proper procedure to use it.

[NMe]

VM_iSCSI_Issue.zip

Screen captures and VBox files

(235.38 KiB) Downloaded 3 times

Hello,
As wrote in previous, issue seemed fixed.
But, and for this time without any known mistake from my own, I had again the same locked status.

Begin with status repaired.
VirtualBox GUI shows VM (NMPHOTO) parameters (2 disks, VDI and DVD) and VirtualBox Media Manager shows the correct list of disks (4 vdi and one iSCI, for all VMs) [Capture3];
vboxmanage lists hdds shows the correct list of disks, and Windows console closes normally ;

Create
vboxmanage storageattach ... creates a new disk, with complete UUID [Capture5] ;

Issue
Now, vboxmanage lists hdds does not close properly, I must close Windows console with Windows Tasks Manager [Capture6]. In Media Manager, Delete, Modify, ... buttons are greyed, for any of the disks ;
Windows Tasks Manager shows several VirtualBox instances still running after [capture7] ;

Please note that if I forgot to close each of all this instances, reboot of the host is blocked (black screen) and I must shut down physicaly the desktop to restart. Fortunately, Windows restarts normaly (so, the issue is replicable).

Independant test
I test connection to the target and the LUN directly from a laptop (not a VM), with MS initiator. I had to press the explore button before to connect, automatic process did not find.
After, connection was perfect.

That pushes an idea :
Previous iSCSI connections between VMs and server ran 2 years with any issues. The previous server was fix IP, but, at this time, the new one is still DHCP IP (because crash of the previous is "only" crash of one disk in the RAID, so I let the previous server connected to migrate step by step). On the laptop, automatic process was initiated with IP, manual with name. Should Vboxmanage storageattach be sensible to that ? Refusing to connect to a DHCP address (which could be logic) ?

I send you captures and several Virtualbox files, because of contains refering to errors, and also for sizes which seems (to me) too much large. See [capture8]. Certains came from previous tests (size limit prevents to send one for debug).
Thank you a lot. I did not open a new topic. Let me know if I must.
NMe

[scottgus1]

Personally, I'll have to leave the data you posted for a Virtualbox user who understands iSCSI better.

Just a bit of advice: backups that aren't reliably restorable are only increases in one's carbon footprint. Since you're having trouble (could be as easy as going static IP and skipping DHCP) you should consider another method to get backup data out of the guest, perhaps shared folders.

[NMe]

Hello,
For information, the issue came from an incorrect iqn address. I had replaced date and site by my own domain, and recent date. Searching about fix vs DHCP addresses, I found a short definition explaining that date and site are certification date and site. So, they can not be modified simply.
So I took the chance of a new test (with Synology informations in the iqn), and the iSCSI has be attached immediatly.

Thank you for your help, as it forces to understand more and more. From my own, the topic may be closed.

May I suggest VirtualBox team adds a few words about iqn structure in User's Manual, because it is not obvious for newbies ? And perhaps a way to stop properly attachment when target is not found or is not correctly certified ?

For backups, please note that Windows in the VM recognized immediatly the disk backuped on the new server, with volume name and letter. From my experience, it is a very simple way to recover all datas, in this case photos collections without any system, but I read it is possible to connect a bootable disk. System should be backuped, and recovered easily. Borderline, speed transfert seems faster with iSCSI than with share folders, at least for small files (an effect of server buffer perhaps ?).

Thanks again,

NMe