I feel that in my bones :lol:
your config (and system) is as optimized as it could be. other than different storage choices there are not likely many knobs left to turn. Since the guest type and performance appear to be hard requirements, you...
Scope is the relevent point.
Best practices always stipulates that the OPERATING SYSTEM should have no other claimants on its space, since it serves as the underpinning of the rest of the system. In a general purpose Linux server, It has long...
The fact that YOU do something doesnt make it a good idea or rationalize it as best practices.
Its not a "better" point. its a different point. Yes, you should monitor your environment.
A hypervisor's function should not have its operating...
You're out of space. delete things.
This is also a prime example why you dont comingle OS and data on the same partition. various services besides just not being able to update will not work now as they dont have room to operate.
That is a useful and potentially important bit of information. These CPUs are actually cpu clusters and are internally individual NUMA nodes. With 8 cores this is probably fine with NUMA disabled, BUT the memory situation could be impacted as off...
hmm. could this approach be used to facilitate other CoW filesystems (zfs/btrfs?)
--edit on reflection, no. answered my own question ;) but it does seem to be a great option for nvof.
Manuel already noted this is outside what PVE supports. I'd go a step further: I can't recommend doing either of these in production.
It's worth being clear about what WSFC actually needs from that disk. It isn't so much the block device as...
there's your problem.
Host exposes the full set of cpu flags to the guest, which means all mitigations applicable to your cpu will apply. in a virtualized environment, mitigations will destroy guest performance- Windows most of all...
Yes, but also no.
Expecting and depending on your software to be faultproof is a fools errand. Yes, you should close doors you are aware that are open but that doesnt absolve you from all the doors you are NOT aware of. The "crime" here wasnt...
Why? lxcs are not dependent on any logical handoffs. if the device is accessible to the host, its accessible to the container.
You wouldnt be passing the device, you'd give permission for the container to access its driver. the bus location is...
Thats an unreasonable metric. "maximum" means nothing here. All you can do is use best practices for your guest OS. whether that yields acceptable results is up to the operator to determine- slow storage will impact your experience way more then...
Microsoft is still catching up with NVMe/TCP, and we've encountered PSODs on ESXi in the past related to NVMe/TCP connections.
iSCSI is extremely mature and broadly supported. As mentioned, it may make sense in more scenarios than initially...
iSCSI isnt deprecated or dead, which is to say the driver stack is included with every modern operating system. having said that, iscsi makes little sense in a world where nvof exists.
The point- you dont NEED pve to achieve your desired functionality, and USING pve for it involves uncomfortable compromises with user experience. But you do you :)
If it were me, and you havent yet purchased anything- I'd buy two machines- one...
the BRAND doesnt exist. The product line successors certainly do, and they were ALWAYS expensive in relations to the cost of "raw disk." If your RTO policies allow for a spof in your storage, I'm sure the ubiquiti nas will work. Having said that...
crazy idea- given your use case, why not start with a normal Windows/Linux desktop and run the rest of the vms in qemu? PVE isnt even desirable in your use case...