3x3q

Usage was low, relative to system maximum. I think the VM was allocated 64GB of RAM, out of a maximum of 128GB. Of the 64GB, perhaps only 45-55GB was in use inside VM.

I don't think it could have happened in my case. If I recall correctly, my server had been running on a UPS for a long time without interruptions. It's a Dell PowerEdge, and I can't imagine poor connection to HDDs. Certainly haven't had a HDD connection problem since this incident happened. At the time, my VM was running sensitive applications that required 100% uptime, so I wanted to pause/reboot/interrupt the VM as little as possible. Single 1.5TB files can't be very common. I think what's more likely is the file size of my 1.5TB vdisk resulted in unusual behavior, presumably from the Mover. This may not account for other users' similar incidents though. At the end of the day, I'm out of ideas.

Thanks so much for posting this dude! This command may be truly helpful when someone encounters an issue similar to mine. At least with this topic on these forums, I've noticed a real authoritative hesitancy to explore with an open mind potential bugs and edge cases in programs. Instead, users are regurgitated at with a debunking which assumes that "programmed behavior == intended behavior".

Everybody in this thread is describing an issue which "cannot happen" if you're under the assumption that the glorious UNRAID operating system is entirely without flaw. I guess it's just much easier to chalk it up to user error though. But even then, in my case, how was I supposed to have removed record of my vdisk image while it was running?

Are you suggesting UNRAID can allow a user to move or delete a vdisk image while it's in use?

My VM .img file did not re-appear and the 1.5T space reservation for the .img file on cache cleared immediately as I shut down the VM, just as I feared it would. I'm sure a file recovery application would have been able to help in my case, since only the path to the file was removed, but the 1.5T size was just too for me to deal with.

Thanks for your input! So what do you suspect is happening to people's vdisks, if we were to attempt to solve this?

Right, that's my point. The .img data still appears to be on the cache disk as it should be, but the path reference to that data is gone. Unless the Mover utility is a flawless piece of code, my suspicion is that Mover for some reason thought it had successfully moved the .img from cache to array and removed the original reference to it.

Is it possible that the Mover may have (for some reason) tried to move it from cache to disk and, because VM was running, it messed up the moving process? The vdisk data does not seem corrupted, since it's still booted and running perfectly. It's almost as if the path to the vdisk .img file has been forgotten by Unraid, and the phantom .img file isn't being overwritten/corrupted by new data because it's still in use.

EDIT: For reference, this is not the vdisk I'm talking about. I'm concerned about the Ubuntu vdisk that should be located at /domains/Ubuntu/.

Here are my shares computed, along with a fresh diagnostics file. What's interesting is that my cache is reporting that there's roughly 0.5 of 2TB free, which would be consistent with a 1.5TB .img file existing on the cache somewhere. Obviously the domains share only reporting anything on Disk1 is a problem. I've just gone through my drives again without detecting the vdisk, but the VM is still running and cranking away. Thanks for your reply Jorge. 3x3q-mainframe-diagnostics-20221117-0943.zip

Thought I'd follow up with some more info on my setup. Like I said, the VM is currently RUNNING, with no apparent vdisk on any of my drives. The last screenshot is of HTOP showing the VM processes, and also of its perceived location on my disk. Someone please just tell me that the .img file will appear after shutting the VM down and the data consolidates... or something like that. You may have noticed that Ubuntu is under heavy CPU/SSD load, and that's because it's processing things that are very special and important to me. EDIT: Following up with Ubuntu VM log file, in case it helps with anything. Ubuntu VM Logs.txt

I believe this is happening to me right now. My Ubuntu VM is currently running just fine, but by pure chance, I noticed that I could not find the vdisk.img for this VM. Google'd "disappearing vdisk" and found this thread full of people who've had this happen. Now I'm terrified to shut down the VM for fear that it'll be lost into the abyss. Ubuntu vdisk was installed to /mnt/user/domains/Ubuntu/ on cache pool. The domains share is set to prefer the cache. Is there any situation where the vdisk still exists, but it just isn't displayed in Unraid? Is it just not showing up because it's currently running? Thanks! EDIT: I should also mention that this VM .img file is around 1.6TB in size, so it's very large. I wonder if that has something to do with it? 3x3q-mainframe-diagnostics-20221116-1726.zip

I've been having the exact same issue as you and others on this forum, though I'm using a TrendNet TEG-30284 managed switch. Like you, no mirroring enabled on my switch. Read your follow-up post and was excited by your progress with IGMP snooping. My switch has IGMP Snooping turned OFF by default to my initial dismay. In a last ditch effort to stop this error, I turned it ON. That stopped the error. Dude, what the hell? This is the opposite of your solution, and it seems to have worked.