not so simple, because that cannot be solved on windows host to have the reply packets go to the same interface the requests came from.
solvable on linux but not on a windows host.
this is that so far my only problem with windows host, all the rest doesnt matter much and is solvable.
and if the incoming comes from the old isp link with static ipv4, and the replies go to the new isp, it drops the reply packets because they dont seem to originate from its network and is considered spoof/abuse.
so i cannot just put storagenode directly on the host, unfortunately.
the only solution to put storagenode directly on host would probably be proxifying the tcp and udp from the vm that has that static ipv4.
i know how to do it for tcp but not for udp.
any insight on this and is it at all possible, given that udp does not have the notion of connection?
is this an issue to worth the hassle, given that even in this configuration it already performs much above average? 
and if to analyze it even more coldly, what would i cut?
just giving filesystem operations closer to storagenode.exe and eliminating the networked layer between vm and host?
that is microseconds, not even milliseconds!
oh do i have such a load with storagenode to worth it?
does it make even a dent given that hardware is hdd and not ssd?
but switching from piecestore to hashstore is considerable and i advocate for it.
the only question that remains for me is if this is what rpi/nas nodes could afford…