I have a couple of windows nodes that are virtual machines with virtualbox, but the virtual machine freezes in an hour or 2 when I update to 1.84, but my windows nodes in physical machine does not happen. Maybe lazyfilewalker doesn’t support shared folders?
1 Like
What does “freeze” mean?
What does the storagenode.log say at the time? It’s been common recently that the underlying storage times out so the node stops itself rather than fail audits.
the virtual machine is not responding, and there is no error in the log
I just noticed this…
Storj does not support shared folders for the blobs storage. The only type of network or shared storage which is allowed is iSCSI.
1 Like
My question is why your using virtual box this is so wasteful for performance and tons of overhead to run vms of windows inside windows… And not just running storj in the native windows.
2 Likes
because my operator has a cg-nat and I don’t have my own ip and I use a vpn, and I don’t put it on my physical machine because I use that computer as a multimedia center, plex server and transcode videos and I don’t want to pass it through a vpn, almost It doesn’t consume a lot of cpu and only 4 gb of ram.
Unlikely it’s related to the storage node version, it’s a typical hardware issue, especially when
and @Stob is right, the network filesystems (shared folders) are not supported. The only working storage network protocol is iSCSI.
You may also try to migrate to a Hyper-V, if you use a Windows host. If it’s Linux, it’s better to use docker instead, but if you would like to use VMs, you need to use something like KVM. You may also try to use virtual disks or direct connection of your disks to VMs.
ok, thanks, I’ll try going passthrough to the hdd, I’ve been doing this for almost 3 years, and it’s only happened to me in this version, it’s back to 1.83 and the vm no longer freezes.
This is interesting. Perhaps VirtualBox emulated hardware is not compatible with lazy access, I never meet such a problem neither with Hyper-V, nor WSL2, nor KVM.
However, as I said, the network filesystems are not supported, they may work, but eventually doesn’t.
I was also thinking about lazy I/O as the culprit. In theory lazy I/O is handled at the guest OS level, as just a different order of operations scheduled to hardware. But maybe, just maybe this means starvation or deadlocks within the guest OS with the specific order of I/O that storage node is inducing?
In any case, it should be considered a bug in virtualization software. IIRC VirtualBox did have some funny bugs in the I/O subsystem in the past.
1 Like
When I read your post, I was a bit scared since I also have a node in Windows 10 made with virtualbox from a few months ago that I wanted to see if I could do more with this configuration in the future. It will be about 32 hours since it has been updated to version 1.84.1 and it has not given me any crashes.
The virtualbox version I use is 5.2.18. It’s old but for what I use it for, it’s enough for day to day.
The virtual machine configuration is:
The node’s (VDI) disk is a dedicated network drive for it and works fine on a 10Gb/s port
The configuration of the “real” PC and operating system is:
If you can help us a bit how you have it configured, we can find out what is causing the virtual machine to hang.
All the best
2 Likes
Likely used OS. The typical problem with a network filesystem is not a full compatibility with behavior of the local file system. Especially regarding how they process locks and other important things.
On Windows the shared folder uses SMB/CIFS (except WSL2, it uses 9p protocol), and if you run Windows VM on the Windows host, there is no problem, the SMB/CIFS and 9P protocols are working adequately.
But if one of the OS is not Windows, they have a not fully compatible SMB/CIFS implementation, thus node likely will not work with such a network storage.
uso Windows 10 pro tanto de host como gest, la versión de VirtualBox es 7.0.6, pero uso la compartición de carpetas del propio VirtualBox en vez de un disco duro virtual.
Vale, ahora entiendo como lo tienes configurado. En realidad lo que estas haciendo es como tener una carpeta de red compartida y eso no es compatible. Es lo que te comentaban @Stob y @Alexey.
Te recomiendo que crees un disco virtual (VDI) y hagas un robocopy de la carpeta compartida al disco virtual que crearas para copiar los datos del nodo y después reconfigures el config.yaml con la nueva ubicación donde residen los datos copiados.
Translation:
Ok, now I understand how you have it configured. Actually what you are doing is like having a shared network folder and that is not supported. This is what @Stob and @Alexey told you.
I recommend that you create a virtual disk (VDI) and robocopy the shared folder to the virtual disk you created to copy the node data to and then reconfigure the config.yaml with the new location where the copied data resides.
1 Like
I can add though, even if you use a Hyper-V engine and Linux VM, there are also no problem with shared disks in the Linux VM, since this is how the docker desktop for Windows working when you use a Hyper-V engine.
However, in the latter case it’s better to use an older version of the Docker Desktop (2.1.0.5), since it has no issues unlike the all more fresh versions. However, I did not check the recent versions though, because I switched to use WSL2 engine instead, since it become a more resources usage care.
1 Like