scorcho99

There are indeed VM xml definitions here, but when I modify them the changes don't see to apply to the running VMs. Is there a way to force the changes to be updated? Edit: I ended up just using virsh define on the modified xml file. I think I'm just going to virsh dumpxml, modify that xml and then use virsh define to commit back the changes.

Where are the VM xml files located? I'd like to dynamically change the settings in the XML definition with a script.

I have since tried 6.10.0 and 6.10.2 (based on the reading the release notes there was a change in the default passthrough method for 6.10.3). Unfortunately, there was no difference. I guess I'm going to remain on 6.9.2.

Doesn't rsync do delta copies as an option? Are you concerned about downtime of the VM (it's shutdown while the giant file is copying) or the bandwidth needed? vdisks can be mounted directly, I've done it with nbd and qcow2 disks anyway. I'm not sure about concurrent with a single read only. I want to say I've heard of that as something you can do with vware vdisks but it's only a vague memory. For my backups I shutdown all my VMs and create a read only btrfs snapshot and then immediately start them backup. Then I backup from the snapshot. The VMs are only down for a few minutes and can change and run while the backup is slowly performed on a snapshot of them in an off state. Maybe something like that?

Switching a VM between these is always a mess since i440fx uses a legacy PCI topology with PCIe stuff just stuck on top of it (which works fine in my experience despite being a nonsensical layout) and Q35 simulates an actual PCIe layout. I find it a lot easier to just make a whole new VM and add in the missing pieces than to change the VM machine type. As you know I have some similar problems that prevent me from running 6.10.3. I never tried this, but when I was doing a vbios dump with space invader one's guide today some one used this option to get the dump script to work. Adding this to syslinux.cfg: vfio-pci.disable_idle_d3=1 Probably won't work but the option title is prescient sounding at least.

Well, I'm stumped on this. I tried blacklisting the amdgpu and radeon drivers, binding to vfio and neither helped. Then I rolled back to 6.9.2 and used space invader one's guide to dump the vbios, confirmed it worked in 6.9.2 and updated. No difference. So it seems like I'm stuck with only OVMF VMs if I want to pass through this card in 6.10.3. But that breaks some other things with the VM so I think I'm stuck on 6.9.2.

I'm not sure the best way to go about this unraid. I'm trying to troubleshoot a GPU passthrough issue.

Unfortunately, my bios doesn't seem to have that setting. And my issue presents a little differently. I don't get the "could not power on, device stuck in D3" error in the log. I vaguely recall that when you enable ASPM is basically has the motherboard handle it. When it's disabled, it isn't necessarily disabled, it is just handed off to the booted OS to handle instead. I could be wrong on that, I haven't thought much about those settings in awhile. It looks like a OVMF/UEFI VM does actually get video out. From experience, this means the R7 360 was 'touched' by the OS during boot which always screws up the vbios and breaks passthrough. Since I'm booting in CSM mode, it screws up seabios VMs but not UEFI ones. I'm not sure why the card is getting touched at all still though, since it is bound to vfio. But I think I have a couple ideas.

I've used ghost82s method before and it does work. You can also set most newer versions of Windows 10 to mirror between the basic display adapter and the real video card. The nice part of this setup is you can get video out from the VM even if it doesn't boot successfully, unlike with vnc or RDP running in the guest. However, some 3D software does play nice in this configuration because it gets confused by the primary adapter not supporting features it needs.

I have on my server a nvidia card as primary and in the secondary slot an old R7 250. Both cards pass through and work for VMs fine for me in 6.9.2. When I updated to 6.10.3 I noticed that the unraid console unexpectedly switched to the R7 250 secondary card (this was confusing since boot appeared frozen), which didn't happen on 6.9.2. I bound the AMD card to vfio on boot and that kept the unraid host console on the primary nvidia card, but in either case pass through of the AMD card no longer works. The VM starts, but there is no video output and the CPU used by the VM remains pegged. I have to force power it off. Rolling back fixes it. I don't use rom files on either card. I boot in CSM mode. All I have done to get passthrough working was add video=efifb:off,video=vesafb:off to syslinux, but that was actually for the nvidia GPU in primary slot passthrough. This particular AMD card has never had reset problems even on older versions of unraid for me. I'm not sure what changed or how to fix this. I know GPU drivers were integrated at some point, probably with 6.10. Are there drivers I can blacklist to get things behaving as they used too?

Oh you aren't missing anything. I just used an old flash drive with the trial to build up a separate install that I could do a dry run. Unfortunately some "mission critical" tasks (kids watching netflix) are handled by my unraid server so I try to avoid downtime with testing.

So I used a test USB to try this out. It seems like just rebuilding everything as usual and then replacing the config and syslinux.cfg with the originals was all I needed to do.

The auto updater now only lists 6.10 versions. But I'd like to move to 6.9.2 since I'm not ready to go to 6.10 yet. Is there a simple way to update to 6.9? I have the downloaded zip of the installer for this version. I've heard I'll just need to install 6.9 over the top of my 6.8.3 flash drive (probably clearing the drive first?) and then copy in the /config folder. It seems like I'll also need to update sys_linux.cfg for my vfio binds. Is there anything else?

There's a really stupid solution to this problem that was kind of obvious once I spent some time messing around with things and reading a bit about samba. All I had to do was run 'samba' in the script right after the snapshot. This forces samba to reload and re-evaluate the permissions fixing the issue until some one (me) screws around with access control again. But since it runs the fix every time there isn't a problem any longer.

For backups, once a week I shutdown all of my VMs which are on my cache drive. Then I create a read only BTRFS snapshot, immediately start the VMS back up and then backup up from a samba share of this read only snapshot. This keeps the VMs in a clean state but minimizes the amount of downtime. The snapshot is removed after the backup is complete. Anyway, this works alright except the samba share for the snapshot will not exist if unraid has been rebooted causing the backup to fail. It seems like the shares are recreated on startup or something and since the snapshot doesn't exist when this happens the share doesn't work. To fix I create the snapshot and then just toggle a user account from read to read/write and back in the SMB share settings. But I don't know how to do this in the command line to assure the backup works every time it reboots. So my question is can I change a user setting somehow through the command line or otherwise restore this state?

I'm not really an active user there, and it seems I've forgotten my login! (It also seems the forum was going to shutdown but might now migrate instead) Anyway, there wasn't really a thread but I recall there being a request mods forum and there were at least 4-5 guys (probably more) that just did custom bios mods in return for donations.

While I haven't used this plugin (my gvt-g experiments were with a custom kernel before this became a plugin) I have something to add regarding aperture size issues. When I was testing things out, I paid a guy in win-raid forums to build me a custom motherboard bios that exposed the aperture size. Most boards bioses have a lot of common code so it's usually just a lazy UI choice what they do and do not show. That allowed me to get access to the higher resolution/vram modes. In theory I could have probably done the bios mod myself, but I had none of the tools or familiarity with them so it definitely would have taken me awhile even with the guides on win-raid. So I just donated to one of the modders on there. I believe it might also be possible to manually tweak these hidden options through the efi shell as well but I didn't investigate that much. It's definitely true that most bioses lack the aperture adjustment setting by default though and motherboard manuals available online often don't even have enough detail to determine this without buying the board. My board was a ASUS z370 prime a ii, but again...it does not have aperture adjustment by default, only with a modded bios. I lost interest in GVT-g when Intel abandoned it personally.

I have a VM that is using outdated software. I'd just disconnect it form the network entirely but I'd like to be able to install some things from my unraid shares occasionally, as well as back up to them. Is there a way to limit the VMs network connection to only certain IP addresses on the network to limit it's attack surface. I'd rather not do any of these things from within the guest, but at the host level.

I have a share to a read only shapshot on the btrfs disk that I use for backups. It's created by first creating the snapshot, then just going to shares in the web admin and setting permissions on the snapshot as normal. If the shapshot is deleted and recreated the permissions persist and everything is fine. However, if I reboot the server or change the permissions of any share then it's broken. I need to go in an manually update the snapshot share (and create it again first) to fix it. Typically I just toggle a user in the list from read only to read/write and back and things work again. Which I often forget to do. I know this is a non-standard config setup but I'd like a way to perform that toggle automatically in my backup user script to alleviate this problem. But I don't know if the unraid share permissions are exposed in anyway like this. I know the underlying linux permissions are, but that is not what I'm trying to change here. It's the SMB share.

Some of my disks had some sensitive documents with personal info on them. The disks were not and are not encrypted. I deleted the files some time back. I'd like to assure they aren't recoverable in the case of theft, drive sales, etc. All the disks in my array are hard drives. From reading around, what I should have done was used shred to overwrite them instead of just deleting them, but I wasn't thinking that far ahead. So I was thinking that filling the empty space on the disk with zeros would accomplish the same task, albeit not very efficiently. Would something like this work? Or will unraid interfere with this in some way I'm missing? dd if=/dev/zero of="/mnt/disk1/filler" bs=10485760 dd if=/dev/zero of="/mnt/disk1/filler1" bs=1 rm /mnt/disk1/filler rm /mnt/disk1/filler1

I reworked the script to instead copy and delete the original since that was a workable solution for this case. I think I figured out why shred was so effective at triggering it all of a sudden. I was using the "-u" option. If you look at the help for shred, by default that renames the file before deleting it! (rather it says it "obsfucates the filename before unlinking". I bet if I drop that option it will be OK. Good ideas on the disk shares, not sure I'll go that route but I think it could be made to work.

I'd rather not disable NFS since it's solving a problem I had with samba shares. I already disabled hardlinks awhile back. Does it make sense that NFS is involved if nothing is interacting with any NFS shares at the time of failure? The share is mounted in a single VM that was not running. And actually...looking back its not even clear if I'd enabled NFS when I first had this problem. I don't use Tdarr.

Well, this happened to me again today. I thought it was running the shred command that did it but that isn't involved into today's case. I believe the trigger is again a script that using "mv" to rename a file and then deletes it. I'll try removing that part of the action and seeing it happens again. The shred command actually probably performs a similar action when unlinking a file name so they might be the same type of cause. Attached are diagnostics in the degraded state. VMs seem to stay running if they were up and I actually still have access to an unassigned device share. Not 100% sure this is the only case, but the files are being changed on a share on my cache drive, with is a SSD and uses btrfs. I only have one docker, a minecraft server, and I haven't actually run it in months. I have an NFS share, not sure that is relevant but I only enabled that in the past couple months and it sort of matches the timeline of when this started occurring. But the files are being edited through samba shares, not NFS. tower-diagnostics-20220112-0934.zip

This issue seems to pop up for me and I haven't seen it before. What I changed recently was I added a script that renames a file, actually a couple of times and then runs shred on it. Not sure if its the shred or the rename. The file remains in the same directory, I'm just changing it's extension. I mention this because I read another post where some one mentioned renames in the same dir related to this issue. I am using 6.8.3. I'm going to experiment with removing the mv (rename really) command.

My parity drive seems like it is kind of slow, so I'm planning to upgrade it to a faster drive. But I have a number of data disks that are of a similar size. But I'm concerned I'll buy a drive that is 3.99TB and have a data disk that is 4.01TB so that it won't work. Is that something I have to worry about? I should note that my data disks are similar to the parity drive that I find is to slow so just swapping them isn't an option.