Jump to content

-Daedalus

Members
  • Content Count

    232
  • Joined

  • Last visited

Community Reputation

21 Good

About -Daedalus

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

  1. I'm assuming this is a "No" as you would have looked at the time, but there's not a GPL version anywhere that does similar things? If this is something on the roadmap, it seems like it would be a necessity anyway.
  2. This is something I'd love to see as well. +1 I'm thinking, as you say, similar to ESXi. Graphed history for storage/network/disk/ram usage, per container/VM. Not a small ask, I know, but something unRAID is missing at the moment. Even the System Stats plug-in, being relatively basic, isn't bundled with unRAID stock.
  3. Holy thread necro, Batman! It's been in for a while:
  4. I get the feeling you might be ditching 6.7.2, and moving straight to 6.8, given all the changes you've talked about are for the latter and not the former. Probably not something you like answering, but are we days/weeks/months away from RCs starting for 6.8?
  5. unRAID's best feature (big or small)? The area where unRAID could improve the most? And it goes without saying, thank you for your truly wonderful contributions to the community.
  6. Correct. Basically, never mix user shares and disks. /mnt/cache -> /mnt/disk[x] is fine. /mnt/user/dir1 -> /mnt/user/dir2 is fine. "user" is an abstraction layer used by unRAID between the disks. It includes cache and disks.
  7. When you create a VM, you specify the size and location for its primary vDisk. You can allocate as many other VDs as you like to a VM during setup, or after the fact. VDs can be in any location. Array, cache, unassigned devices. It makes no difference. You can resize VDs as well (this must be done through CLI), though you must also resize the VDs on the OS-level as well, obviously. Disks are thin-provisioned. (they use as much space as required to hold the data they have, and balloon up to the specified size) You can, if you prefer, pass through an entire disk to be used exclusively by a VM as well.
  8. I'm assuming this database corruption presents as a borked container? Because if that's the case, I'm on 6.7.2, with a cache pool, and zero issues. I've never experienced this (at least, so far as I can tell). server-diagnostics-20190903-0955.zip
  9. At present, when the '+' is clicked, a second NIC can be added, but there is no option to add a 3rd/4th. The current VM config must be saved, then edited again, and so-on until the desired number is reached. This is in contrast to vDisks, where any number can be assigned to a VM in one go. (the '+' icon is present on each new VD, as well as the '-') While we're at it, it would be lovely if we could select 'model type' from the UI as well. Manually changing ESX VMs to vmxnet3 can get tedious...
  10. It's not exactly a common use-case, but I'm pretty sure it can be done. To answer your questions: 1: Nothing cheap. 2: Yes. It's trivial to change CPU/memory, etc. GPU is a little trickier, but still simple. 3: They might, yes. NVIDIA's drivers are unified (mostly), so assuming you're using two relatively recent GPUs, in theory you should just be able to reboot it, and everything will come up as you'd expect. 4: It's not natively done like that, but you can. 5: It's remote desktop. You won't be playing games with it, but it's fine for programming. Notes: 1: As C-Fu mentioned, ESXi is an option, but the free version has limitations, and it's hardware passthrough can be pretty damn picky. More generally, have you considered just using WSL? If you're gaming on Windows anyway, why not use the Linux subsystem for programming in terminal? 4: By default, you'd pick a location for the vDisk to be installed, and that would be that. If the only reason you want the VM's disks on the HDD is for redundancy, then I'd suggest buying a second SSD and making a cache pool. That's what people usually do when running VMs/Docker on cache. If there's some other reason you want them on HDD when inactive, then you could create the VM on SSD, and have a script manually move the VD to HDD on shutdown, and move it back to SSD before startup. This means you wouldn't be able to use the GUI to start the VM, but it would accomplish what you want.
  11. No reason. Just a minimalist thing I suppose. Well, actually, it's also to try and prevent Windows from filling up images with junk. Seems to be like cats in that regard: It expands to fill all available space of a container.
  12. I do this semi-regularly. I have a base VM images that I use when deploying different OSs. Usually these are minimum size, and get expanded as required depending on use-case. +1
  13. Moved away from Server 2012 R2 (and FlexRAID) to unRAID a few years ago. Overall, really happy with the move. Keep up the fantastic work guys!
  14. If you click and hold on any of the headers within a panel, you can re-order them. (So you can have 'Docker Containers' below 'Virtual Machines', or 'Server' below 'Processor' for example) So far as I know, you can't move panels as a whole around however.