moondev
moondev on Hacker News
Could there theoretically be a swappable hypervisor for oxide some day? I'm imagining a oxide Linux distro of sorts running on the hosts, and using kvm for vms, but still oxide control plane bits downstream. Then you get nested virt and gpu support, and could maybe even virtualize a traditional oxide host. Like running multi-host vcenter clusters inside a single esxi, amazingly powerful lab scenarios, teardown is even fun
Love to see the CAPOx provider and buy in to Cluster API
Unfortunately as of today DGX Spark doesn't support GPU PCI passrhru for KVM
A good alternative is incus and running LXC and or OCI containers, GPU works in those and can be shared with multiple instances
What if this project offered binaries from GitHub releases instead? How do you read those?
It's more realistic to decide if you trust the source, GitHub user yamafaktory in this case. Then you can ensure that your method of download uses TLS.
If you run an ubuntu image with a kata kernel, do you have difficulty installing some packages? For example if you need linux-headers-$(uname -r) or linux-modules-extra-$(uname -r), it won't exist in canonical apt repos?
The HP z2 mini g1a supports a BMC module that is a full redfish implementation, so it can do virtualmedia and UEFI configuration read/write.
https://www.hp.com/us-en/shop/pdp/hp-anyware-remote-system-c...
I was pretty disappointed to discover DGX spark has no BMC. I was able to hook it up to pikvm by connecting leads to the power switch wires. It honestly works really well and I can provision it with MAAS
Shout-out to pikvm for their redfish support with the pikvm switch
Great writeup there are quite a few here that are new to me
Spark:
OS: Windows/Ubuntu
Mbw: 300GB/s
Cuda cores: 6000
GPU accelerated containers: yes
M5 max:
OS: macOS
Mbw: 600GB/s
Cuda cores: 0
GPU accelerated containers: no
How is changing the architecture of a platform that only you make hardware for doing the impossible?
They could change the architecture again tonight, and start releasing new machines with it. The users will adopt because there is literally no other choice.
Every machine they release will be fastest and most capable on the platform, because there is no other option
You are confusing macos guests on KVM (Linux) and macos guests on ESXi which is a real enterprise product, and officially enables you to run as many macos vms as your hardware supports.
An artificial limit on the number vms you are allowed to launch doesn't make it solid
Being unexpectedly unemployed also starts a virtual timer of sorts not on your terms. Regardless of how you feel about the event, the longer it persists is universally seen as a negative signal to those that would hire you for your next role. It gets exponentially worse as time goes on making it even harder to find a job, because of the increased time you don't have a job.
Imagine buying a mac studio with 500+ GB of memory and being limited to 2 vms.
The VM limit only applies to the number of macOS VMs launched from macOS itself.
My 2018 mac mini officially supports VMware ESXi to be installed directly on the hardware and virtualize any number of macOS machines
Funny enough I can even launch more than 2 macOS vms on my framework chromebook with qemu + KVM from the integrated Linux terminal.
Things like this remind me how much I love open source software. Choice is amazing shout out to all the contributors!
Yes that is the package. It's just like the canonical ui for lxd, but it also supports the incus enhancements like OCI containers.
Very handy to generate yaml config for machines and viewing their console / terminal.
> I'm feeling like it is hard to find a simple GUI to just review a system and manage a bunch of containers and VMs.
Incus does all three through the same web ui
* OCI compatible "app" containers - with support for registries like docker.io and ghcr.io
* LXC "system" containers
* virtual machines with qemu + kvm
That's why I love Incus. It offers all three so you don't have to choose. OCI app containers, LXC containers and KVM.
Just like KIND runs containerd inside docker, you can also run dockerd inside containerd backed pods.
Start a privileged pod with the dind image, copy or mount your compose.yaml inside and you should be able to docker compose up and down, all without mounting a socket (that won't exist anyway on containerd CRI nodes)
To go even further, kubevirt runs on kind, launch a VM with your compose file passed in via cloud-init.
This looks like OVA, firmware can be bundled inside along with additional disks, networking config, machine type and so on.
So essentially a virtual appliance package
The bigger the company the less impressive "senior" is. There are probably three levels of staff above it and then distinguished super fellow territory.
In Shared NVSwitch Multitenancy Mode - are there any considerations for leveraging infiniband devices inside each vm at full performance?
Wouldn't this be more like
Proxmox Datacenter Manager = VMware vcenter
Proxmox VE = VMware ESXi
Apple intelligence: trained by Nvidia GPUs on Linux.
Do the examples in the repo run inference on Mac?
