Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

4 Neutral

About bland328

  • Rank
    Advanced Member


  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for the response, @jonathanm. I've revised my original post just a bit to clarify that I'm not shooting for the host discerning the trajectory of the guest--I'm looking to get a chance to do some work before (or even as) the host makes an effort to shut down the guest. That is, I'm only trying to catch the case that Unraid/libvirt is making an attempt to shut my VM down from outside the guest. It's easy to learn that my VM was shut down, but I'm hoping to be called before it happens.
  2. I'm not quite sure where to ask this question! It could end up being appropriate here, or perhaps it's a plugin question, or perhaps it's something else. What I'm trying to do: I'm looking for a way to run a custom script on my Unraid server (on the host, not the guest) before one of my VMs is shut down by the host. Also, while I do want to catch the case that my VM is shut down from the Unraid GUI, I could live with only catching the case that the array is being stopped. What won't work: Building a manually-executed script that does my additional work and then shuts the VM down won't do the trick, since I need to do this additional work automatically even in the cases that the VM is being shut down from the GUI or is being shut down automatically as a result of the array being stopped. What doesn't work: To catch the case that the array is being stopped, I've tried the User Scripts plugin, with a script that runs "At stopping of array," but that's too late--my VM has already been shut down by the time my script is called. To catch that same case, I've also tried a bare-bones custom plugin (/usr/local/emhttp/plugins/my_custom_plugin/event/stopping_svcs), but that's also called too late. I've even looked into modifying the libvirt /etc/libvirt/hooks/qemu script, but it too is called after a VM has been stopped. Any thoughts on how to catch an attempt at shutting a VM down, or at least being called early in the array-stopping procedure? Thanks for any ideas!
  3. This thread initially seemed bizarre to me, but now I think I get it; I'd appreciate any feedback on my understanding: On a real SSD, as I understand things, TRIM speeds up some writes and reduces wear on the flash chips by telling the SSD which blocks are no longer in use by the file system, so that the SSD controller can more efficiently deal with them. So...for a virtual qcow2 disk image, enabling TRIM helps keep the dynamically-allocated disk image from growing more quickly than necessary? And, assuming I'm right about that...are there any other advantages?
  4. For anyone else chasing this broken-Ethernet-at-boot issue, I seem to have fixed it on my system by changing the bridge PCI bus to '0x00' and slot to '0x05' thusly: ... <interface type='bridge'> ... <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> ... Since making the change, over a couple dozen boots, I haven't again seen macOS report the (virtual) Ethernet cable as being unplugged.
  5. That's painful, but makes perfect sense. NFS implementations that only consider 32 bits of a 64-bit value are why we can't have nice things Thanks for the explanation!
  6. Ah! I think this explains the hard link struggles I'm experiencing when attempting to de-dupe files using rmlint. So, @limetech, do I understand correctly that: If I make a hard link in a User Share (e.g. in /mnt/user/test), it will indeed make a hard link on the Device (e.g. in /mnt/disk3/test), but... The shfs FUSE file system generates "pseudo" inode values, and therefore... There's no way to detect hard links in User Shares--I can only detect them by examining the inodes of files on Device(s)?
  7. I'm also using 6.6.6, for the benefit of anyone else reading this.
  8. Oh, I get your point. However, I did that long ago, since I just hate for things like that to mismatch—so, my VM name (the <name><name/> in the XML) and directory name do match, and I still run into this problem. Odd.
  9. In this 2017 post: @llonca13 says: That sounds promising! Though I haven't been able to find the original @SpaceInvaderOne (formerly @gridrunner) post referenced, I have attempted to change the slot number in the XML as follows: ... <address type='pci' domain='0x0000' bus='0x01' slot='0x05' function='0x0'/> ... However, when I make just the single-digit change and then click Update in the XML View, I immediately get this error pop-up from Unraid: VM creation error XML error: Invalid PCI address 0000:01:05.0. slot must be <= 0 Any thoughts on what I'm doing wrong? Do I need to somehow update the definition of PCI bus 1, or otherwise "create" slot 5? Or am I just all confused because @llonca13's original post above is only about passing through a physical NIC, and wouldn't apply to a virtual bridge?
  10. Aside from an Ethernet issue I haven't solved, I've got what seems to be a rock-solid Mojave VM running under Unraid 6.6.6. My Ethernet issue is simply that often (but not always) after I boot the VM, I don't have Ethernet access. In this case, System Preferences > Network says that my Ethernet cable is unplugged. If I then issue $ sudo ifconfig en0 down && sudo ifconfig en0 up from the Terminal, Ethernet starts working, and I've never seen it then fail again until I reboot the VM. My network configuration looks like this (MAC address censored): ... <type arch='x86_64' machine='pc-q35-3.0'>hvm</type> ... <interface type='bridge'> <mac address='99:88:77:66:55:44'/> <source bridge='br0'/> <model type='e1000-82545em'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> ... Any thoughts on how I might fix this? Or, at least, gather more data?
  11. I see where you are coming from there, and I have indeed changed the name of my VM at some point, but the current situation is that I have manually selected the correct img file, and have to re-manually select it every time I attempt to submit any changes made in Form View. So, feels like a straightforward GUI bug, but I'm not sure exactly what is triggering it. Or, do I misunderstand your point, @user2352?
  12. Thanks very much, @SpaceInvaderOne! I will. Also, I'm a little embarrassed that I figured out the source of the problem--I hadn't disabled sleep under Mojave. So, though I'd like to think that mouse support would survive sleep, I'm not shocked that it doesn't, and setting sleep to Never fixed my mouse woes. I hope this post helps some other macOS KVM noob
  13. tl;dr: macOS VM virtual mouse eventually stops responding. I have macOS Mojave 10.14.1 (I haven't quite figured out how to successfully update to 10.14.2 yet) working very smoothly, thanks to the excellent @SpaceInvaderOne guide at: I'm accessing this VM purely through VNC, and I'm passing through no USB ports, nor even any audio or graphics. My <input>, <graphics> and <video> XML looks like this: ... <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' websocket='-1' listen='' keymap='en-us'> <listen type='address' address=''/> </graphics> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> ... and my usb-mouse and use-kbd XML looks like this: ... <qemu:commandline> <qemu:arg value='-usb'/> <qemu:arg value='-device'/> <qemu:arg value='usb-mouse,bus=usb-bus.0'/> <qemu:arg value='-device'/> <qemu:arg value='usb-kbd,bus=usb-bus.0'/> <qemu:arg value='-device'/> ... After some time, some number of VNC connections/disconnections (I sometimes use RealVNC viewer and sometimes the built-in "noVNC" VNC Remote), or some other factor I haven't considered, the mouse stops responding, but the keyboard continues to work. At this point, I can't figure out any way to get it going again, except to reboot the VM. The mouse always works after a fresh boot. Any thoughts on what I might try, or other information that might be valuable to help others help me? Thanks, all!
  14. Ah-ha! I may have found the problem: If I change the Primary vDisk Location from Auto to Manual, I can then Update the VM. But when I Edit it again, the Primary vDisk Location reverts to Auto.
  15. I'm also seeing this problem. I created a new Windows 10 VM today, and made no XML edits at any point. I now cannot successfully submit any further changes from the Form View—when I try, I get the "Updating..." text in the button, seemingly forever.