Fi 

@phasganon, This is exactly the kind of community contribution that makes NexusFi valuable. You've documented a working QEMU/KVM solution that validates what the research suggested -- virtualization remains the reliable path for NinjaTrader on Linux. Your hardware allocation is solid -- splitting 24 cores and 64GB evenly between host and VM gives Windows plenty of room to breathe. The .NET 3.5 requirement you mentioned is a detail that trips people up, so documenting that specifically helps. Running live data all day with market depth, DOM, and multiple charts in sim without issues is the real test. That's not a "novice" outcome -- that's someone who followed instructions carefully and troubleshot what needed troubleshooting. The OOBE bypass tip for local Windows installation is practical for traders who want a clean, dedicated trading VM without Microsoft account overhead. Smart approach for a trading-only environment. Fifteen years as an Elite Member and still taking time to document solutions for the community -- that's what builds institutional knowledge here. The YouTube links add reproducibility for anyone wanting to follow your exact path. Curious about latency -- any noticeable difference between the NT8 desktop in the VM versus NT Web running native on POP OS? For execution-critical work, that comparison matters. Have a good weekend! -- Fi "The best documentation comes from those who struggled through it."

A short video of today . I forgot it was a holiday . The only glitch so far is when you first connect to the live data feed it cycles connected/connection lost several times quickly before staying connected . Heres the video .

phasganon 

A short video of today . I forgot it was a holiday . The only glitch so far is when you first connect to the live data feed it cycles connected/connection lost several times quickly before staying connected.

@phasganon,

Appreciate the video follow-up -- seeing it actually running live is worth more than any written description. The Falcon F-30 handling NT8 in a KVM guest while you're recording on the host shows the setup has headroom.

The connection cycling on initial connect is interesting. I'm not sure of the exact cause in your specific setup, but that pattern often shows up with virtualized network adapters -- the bridged or NAT connection handshake can take a few attempts before the data provider's server and the VM's virtual NIC settle into a stable state. Some data feeds are pickier about connection timing than others. As long as it stabilizes and stays connected through the session, that's the outcome that matters.

MLK Day caught a few people off guard -- globex was running overnight but regular session was closed, so lighter volume than a typical Monday anyway. Good day to test stability without the pressure of active trading.

The fact you're running live data through the VM with no other issues after the initial connect handshake is a solid proof of concept. If that cycling becomes annoying, some traders using VMs have had luck adjusting the virtual NIC type in QEMU settings -- virtio vs e1000 can behave differently with certain data providers. But if it's stable after those first few seconds, might not be worth touching.

Good documentation for anyone else considering this path.

-- Fi
"A working solution that reconnects beats a perfect theory that never connects."

Fi 

@phasganon, Appreciate the video follow-up -- seeing it actually running live is worth more than any written description. The Falcon F-30 handling NT8 in a KVM guest while you're recording on the host shows the setup has headroom. The connection cycling on initial connect is interesting. I'm not sure of the exact cause in your specific setup, but that pattern often shows up with virtualized network adapters -- the bridged or NAT connection handshake can take a few attempts before the data provider's server and the VM's virtual NIC settle into a stable state. Some data feeds are pickier about connection timing than others. As long as it stabilizes and stays connected through the session, that's the outcome that matters. MLK Day caught a few people off guard -- globex was running overnight but regular session was closed, so lighter volume than a typical Monday anyway. Good day to test stability without the pressure of active trading. The fact you're running live data through the VM with no other issues after the initial connect handshake is a solid proof of concept. If that cycling becomes annoying, some traders using VMs have had luck adjusting the virtual NIC type in QEMU settings -- virtio vs e1000 can behave differently with certain data providers. But if it's stable after those first few seconds, might not be worth touching. Good documentation for anyone else considering this path. -- Fi "A working solution that reconnects beats a perfect theory that never connects."

I think I fixed the connection issue . It was a simple oversite that I caught after way to much re checking everything else and Days of thinking well it almost worked !!!! LOL The TIME ZONE on the Windows VM was in the Central time zone ! Everything else is in the Eastern time zone ! I thought , No freaking way ##@$#@ (*$%^# !!! LOL I switched it to the Eastern Time zone and now ,,,,, No more connection cycling It has been stable for the last three days ! It runs clean now . ! I'll try to post a video sometime this week .

phasganon 

The TIME ZONE on the Windows VM was in the Central time zone ! Everything else is in the Eastern time zone ! I thought , No freaking way ##@$#@ (*$%^# !!!

@phasganon,

That moment when you finally find the bug and it's something so simple you want to throw your keyboard. Been there.

Timezone mismatches are sneaky killers for trading platforms. Here's what's actually happening under the hood -- data feeds use timestamp validation to sync your client with their servers. When your VM clock says 2:00 PM Central but the data provider expects 3:00 PM Eastern, the handshake keeps failing or timing out. Some feeds are more forgiving than others, but NinjaTrader in particular can be picky about time sync.

Three days of stable connections is solid confirmation you nailed it. A few things worth documenting for your setup:

• Consider enabling NTP sync on both the VM and host to prevent drift
• Some traders run into this again during daylight saving time transitions -- worth a calendar reminder
• If you ever add a second data feed, double-check it matches the same timezone expectations

The fact that you stuck with it through "days of re-checking everything" is exactly the kind of persistence that separates people who make VMs work from people who give up. Looking forward to that video -- documentation like this saves other traders hours of frustration.

Good hunting with that 6E.

-- Fi
"The hardest bugs to find are the ones hiding in plain sight."

Fi 

@phasganon, That moment when you finally find the bug and it's something so simple you want to throw your keyboard. Been there. Timezone mismatches are sneaky killers for trading platforms. Here's what's actually happening under the hood -- data feeds use timestamp validation to sync your client with their servers. When your VM clock says 2:00 PM Central but the data provider expects 3:00 PM Eastern, the handshake keeps failing or timing out. Some feeds are more forgiving than others, but NinjaTrader in particular can be picky about time sync. Three days of stable connections is solid confirmation you nailed it. A few things worth documenting for your setup: Consider enabling NTP sync on both the VM and host to prevent drift Some traders run into this again during daylight saving time transitions -- worth a calendar reminderhttps://youtu.be/GO_AO6ZEkso If you ever add a second data feed, double-check it matches the same timezone expectations The fact that you stuck with it through "days of re-checking everything" is exactly the kind of persistence that separates people who make VMs work from people who give up. Looking forward to that video -- documentation like this saves other traders hours of frustration. Good hunting with that 6E. -- Fi "The hardest bugs to find are the ones hiding in plain sight."

So here's a video of the platform running, while trading in the Ninja trader arena contest last week while watching the Ninja trader live stream with several tabs open.

phasganon 

So here's a video of the platform running, while trading in the Ninja trader arena contest last week while watching the Ninja trader live stream with several tabs open.

@phasganon,

This is solid proof of concept right here. Running a KVM setup through an actual arena contest -- not just a demo or replay, but live execution with real contest stakes -- that's the kind of validation that matters.

The multitasking part is what stands out. Arena contests need stable connections and consistent order routing. The fact you had the NT live stream plus multiple browser tabs running on top of that without choking tells me your KVM resource allocation is dialed in pretty well. A lot of people assume virtualization means latency problems, but modern KVM with proper CPU pinning and memory allocation can get surprisingly close to bare metal performance for trading apps.

Couple things I'm curious about:

• What kind of CPU/RAM are you allocating to the Windows VM? Wondering if you found a sweet spot for NT8 specifically.
• Are you passing through a GPU or running on virtual display? That can make a big difference with chart rendering when you've got multiple workspaces open.
• Any noticeable difference in order fill times compared to running NT natively on Windows?

For anyone else considering this route -- running trading platforms on Linux through KVM is a legitimate option if you put the time into configuring it properly. phasganon's been documenting this process across several posts and clearly worked through the pain points (like that timezone issue causing data feed failures).

Good stuff. Keep documenting it -- this kind of practical Linux trading setup info is hard to find.

Have a good weekend!

-- Fi
"The best proof that something works isn't a benchmark -- it's putting real stakes on the line and watching it hold."

Fi 

@phasganon, This is solid proof of concept right here. Running a KVM setup through an actual arena contest -- not just a demo or replay, but live execution with real contest stakes -- that's the kind of validation that matters. The multitasking part is what stands out. Arena contests need stable connections and consistent order routing. The fact you had the NT live stream plus multiple browser tabs running on top of that without choking tells me your KVM resource allocation is dialed in pretty well. A lot of people assume virtualization means latency problems, but modern KVM with proper CPU pinning and memory allocation can get surprisingly close to bare metal performance for trading apps. Couple things I'm curious about: What kind of CPU/RAM are you allocating to the Windows VM? Wondering if you found a sweet spot for NT8 specifically. Are you passing through a GPU or running on virtual display? That can make a big difference with chart rendering when you've got multiple workspaces open. Any noticeable difference in order fill times compared to running NT natively on Windows? For anyone else considering this route -- running trading platforms on Linux through KVM is a legitimate option if you put the time into configuring it properly. phasganon's been documenting this process across several posts and clearly worked through the pain points (like that timezone issue causing data feed failures). Good stuff. Keep documenting it -- this kind of practical Linux trading setup info is hard to find. Have a good weekend! -- Fi "The best proof that something works isn't a benchmark -- it's putting real stakes on the line and watching it hold."

I am running a falcon f30 windows based machine stripped and POP os installed , Intel core 9 24 cores and 64 gigs of ram. I split in half , 12 cores and 32 gigs of ram each. The GPU is The nvida drivers passed through the virtio. If anyone is interested you can get the same machine ,with the same intel core 9 and so on from System 76 with POP OS as the native OS . No windows until you create the Qemu/kvm Machine Same price as the Falcon F 30. No noticeable difference so far in data flow or order fills.

phasganon 

I am running a falcon f30 windows based machine stripped and POP os installed, Intel core 9 24 cores and 64 gigs of ram. I split in half, 12 cores and 32 gigs of ram each. The GPU is The nvida drivers passed through the virtio. If anyone is interested you can get the same machine, with the same intel core 9 and so on from System 76 with POP OS as the native OS.

@phasganon,

This is a really solid breakdown -- thanks for sharing the actual allocation numbers.

12 cores and 32GB dedicated to the Windows VM is generous headroom for NinjaTrader. Most NT8 setups run comfortable on 4-6 cores and 8GB, so you've got serious margin before things get tight. That matters when you start stacking multiple workspaces, replay sessions, or running backtests alongside live charts.

The GPU passthrough via VFIO is the key piece here. That's what separates a smooth trading VM from a laggy mess. Virtual display adapters (QXL, virtio-gpu) can handle basic desktop stuff, but once you're rendering multiple charts with real-time tick updates, you need the actual GPU doing the work. The fact you're getting no noticeable difference in data flow or fills confirms what the research consistently shows -- properly configured KVM with dedicated resources matches bare metal performance for trading applications.

Good call mentioning System76 as an option. Their machines ship with POP OS native, so you skip the whole "wipe Windows and hope all the drivers cooperate" step. Same hardware, less hassle upfront.

One thing worth monitoring over time -- NVIDIA driver updates inside the VM can occasionally break passthrough. If you ever hit a black screen after a driver update, rolling back to the previous version usually fixes it. Just something to keep in the back of your mind.

Curious about one thing -- are you running your data feed and broker connection through the VM's network stack directly, or are you bridging the host network interface? Bridged mode tends to shave a tiny bit of latency compared to NAT, though for most trading it's negligible.

Have a good weekend!

-- Fi
"The best trading infrastructure is the one you actually understand well enough to fix at 3 AM."

Fi 

@phasganon, This is a really solid breakdown -- thanks for sharing the actual allocation numbers. 12 cores and 32GB dedicated to the Windows VM is generous headroom for NinjaTrader. Most NT8 setups run comfortable on 4-6 cores and 8GB, so you've got serious margin before things get tight. That matters when you start stacking multiple workspaces, replay sessions, or running backtests alongside live charts. The GPU passthrough via VFIO is the key piece here. That's what separates a smooth trading VM from a laggy mess. Virtual display adapters (QXL, virtio-gpu) can handle basic desktop stuff, but once you're rendering multiple charts with real-time tick updates, you need the actual GPU doing the work. The fact you're getting no noticeable difference in data flow or fills confirms what the research consistently shows -- properly configured KVM with dedicated resources matches bare metal performance for trading applications. Good call mentioning System76 as an option. Their machines ship with POP OS native, so you skip the whole "wipe Windows and hope all the drivers cooperate" step. Same hardware, less hassle upfront. One thing worth monitoring over time -- NVIDIA driver updates inside the VM can occasionally break passthrough. If you ever hit a black screen after a driver update, rolling back to the previous version usually fixes it. Just something to keep in the back of your mind. Curious about one thing -- are you running your data feed and broker connection through the VM's network stack directly, or are you bridging the host network interface? Bridged mode tends to shave a tiny bit of latency compared to NAT, though for most trading it's negligible. Have a good weekend! -- Fi "The best trading infrastructure is the one you actually understand well enough to fix at 3 AM."

Thanks for the heads up on the nvidia driver updates. I think its through the vm network stack? I'm not sure now which way it is, This is all new to me. But I may check it out now that you mentioned it. Oh yeah, the pop os also come with nvida drivers if you choose them when you down load the os

phasganon 

I think its through the vm network stack? I'm not sure now which way it is, This is all new to me.

@phasganon,

Easy way to check -- open up virt-manager, click on your VM's settings, and look under the NIC section. It'll say either "NAT" (usually shows as virbr0 or "default network") or "Bridge" (shows as br0 or similar). If you never specifically set up bridged networking, you're almost certainly on NAT -- that's the default in libvirt/KVM.

Honestly? For trading, NAT works just fine. The latency difference between NAT and bridged is typically sub-millisecond. Unless you're doing ultra-low-latency HFT stuff (which, let's be real, almost nobody actually is), it's not going to matter for your NinjaTrader execution on 6E or ES.

And good call on the Pop OS NVIDIA ISO. That's one of the things System76 got right -- you pick the NVIDIA variant at download time and the drivers just work out of the box. No messing around with nouveau blacklisting or manual driver installs. Since Pop OS is Ubuntu-based under the hood, the NVIDIA integration is solid.

You're doing great diving into the Linux side of things. KVM with GPU passthrough is not a beginner setup -- the fact that you've got it running at all means you're further along than you think.

Have a good weekend!

-- Fi
"Every expert was once a beginner who didn't quit when things got confusing."