I don't give up that easily ? ...
Here's a step-by-step guide that allows streaming Netflix media on NetBSD using a intel-haxm accelarated QEMU vm.

Heads-up! Sound doesn't work, but everything else is fine. Please read the rest of this thread for a solution to this!!

Start by obtaining the sources according to chapter 30 on the NetBSD guide. Actually, you only need to fetch and unpack syssrc.tgz

Set-up pkgsrc if you don't already have it.

cd /usr/pkgsrc/emulators/haxm
sudo make
sudo make install
sudo make clean
sudo make clean-depends

Once done, do update/upgrade your system and install qemu

sudo pkgin update
sudo pkgin full-upgrade
sudo pkgin install qemu

Now create the haxm device nodes

sudo haxm-mknod

and load the modules

sudo haxm-modload

Create a virtual machine with enough space

qemu-img create vm.img 8G

Pick an Ubuntu based distro and boot the live image. I've took Peppermint 7, since I know this image worked for me earlier using qemu-kvm on Linux. Give the machine a rather low RAM, so it doesn't create an unnecessary large swap partition.

sudo qemu-system-x86_64 -boot d -cdrom /path/to/image.iso --accel hax -m 1G -hda vm.img

You will need to pass the noapic option to the Linux kernel at boot time.
Once running, install the system on the virtual machine and shutdown the vm.

Re-launch the vm, this time give it more RAM to work with

sudo qemu-system-x86_64 -boot d --accel hax -m 4G -soundhw hda vm.img

Unfortunately, and as mentioned sound doesn't work yet. The system boots fine but warns that "could not init 'oss' audio driver" - See below the observations of @JuvenalUrbino
Update the packages in the vm, launch Firefox and enable DRM content. Login to Netflix and voilá, streaming Netflix on NetBSD ?

netflix running

If you want to remove it, start by deleting the vm.img
Then...

sudo haxm-modunload
sudo rm /dev/HAX
sudo rm -r /dev/hax_vm*
sudo pkg_delete haxm

Optionaly, you may remove QEMU and its dependencies using pkgin and remove /usr/src and /usr/pkgsrc to free space on your hard drive.
Enjoy!

    pin nice ?

    “Only the paranoid survive.”

    ― Harold Finch
    NetBSD VPS , NetBSD , OS108

    • pin replied to this.

        Jaythanks, overall, that's very well written and all the more useful as everybody needed that proof of concept in the end.

        That said,

        pin Unfortunately, and as mentioned sound doesn't work yet. The system boots fine but warns that "could not init 'oss' audio driver"

        Up to 7.x the NetBSD's implementation of OSSv3 sound subsystem couldn't listen to more than one process at a time (as opposed to Linux' ALSA). In order to manage multiple programs playing sound at a time one had to rely on userspace-level sound servers like Esound first and Pluseaudio later on. This changed in 8.x since the introduction of the in-kernel mixer, so at least we can safely assume that this is not where the problem lays.

        Yet, QEMU is still failing in speaking to /dev/audio (see audio(4)). If we exclude a privilege/permission, my suspicion falls onto QEMU's default settings for OSS: given both Linux under udevd and FreeBSD with devfs use /dev/dsp* as generic OSS i/o pseudo-interface , QEMU may be pointing to it by default in place of /dev/audio.

        Indeed once installed QEMU and issued $ qemu-system-x86_64 -audio-help | egrep "DAC_DEV|ADC_DEV", I get:

          QEMU_OSS_DAC_DEV: string, default = /dev/dsp
  QEMU_OSS_ADC_DEV: string, default = /dev/dsp

        While I don't have the time to test it myself, a possible solution could be pointing QEMU to the right interface. Fortunately, QEMU provides a ton of tunable environmental variables:

        $ export QEMU_OSS_{ADC,DAC}_DEV=/dev/audio 
$ sudo -E qemu-system-x86_64 -boot d --accel hax -m 4G -soundhw hda vm.img

        Another possible workaround would be changing the audio backend. QEMU's current default configuration for NetBSD....

        NetBSD)
  bsd="yes"
  hax="yes"
  make="${MAKE-gmake}"
  audio_drv_list="oss try-sdl"
  audio_possible_drivers="oss sdl"
  oss_lib="-lossaudio"
  HOST_VARIANT_DIR="netbsd"
 supported_os="yes"

        Reveals support for devel/SDL2 API (which provides an audio abstraction layer for programs to use, via OpenGL) (still no PulseAudio support on NetBSD apparently).

        To use SDL2 in place of baremetal OSS:

        $ export QEMU_AUDIO_DRV=sdl QEMU_SDL_SAMPLES=2048
$  sudo -E qemu-system-x86_64 -boot d --accel hax -m 4G -soundhw hda vm.img

        Let us know if either of those works ?

              Cheers mate!
              Whenever I find the time ?

              • Jay likes this.

              pin Tried both, but both options still fail to initiate the oss audio driver.

              Did you perhaps omit passing the '-E' switch (meant to keep users' environment) to sudo, as shown above? otherwise your custom variables would be lost once acquired root privileges. You can also append additional variables to the sudo env in one line by exporting them after having typed sudo, or even better, for a shell-agnostic procedure, use env(1):

              $ sudo env QEMU_OSS_{ADC,DAC}_DEV=/dev/audio  qemu-system-x86_64 -boot d --accel hax -m 4G -soundhw hda vm.img

              The reason I hadn't tried HAXM so far yet, is that my poor Pentium Dual-Core doesn't support Intel VT-x and can't thereby make use of any hardware-accelerated type2 hypervisors, nor use more than 1 core, nor run 64bit guests.

              Anyway, after you last comment I decided to take the plunge a try it myself: it works!
              If the *ADC|DAV_DEV variables are correctly exported as I've shown above, qemu -audio-help shall reveal they point to /dev/audio. At this point you can safely launch you VM.

              What I did:
              - set the aforementioned variables to /dev/audio and double checked QEMU's env
              - downloaded a 32bit Tiny Core Linux image, launched it in QEMU (full emulation, no acceleration), with `qemu-system-i386 -soundhw hda.... pleasantly noticed it was not complaining about OSS
              - prayed while I started a FLVM Xorg session (lol =P). Obviously it was dead slow
              - I still managed to install dbus, pulseaudio, libmp3lame, XMMS and the xmms-pulse plugin; then started the dbus and pulseaudio services (after learning TCL uses SysV scripts)
              - fetched a .mp3 song (Yellow, Coldplay) from the host laptop and launched XMMS with pulseaudio backend: the music was played correctly, loud and clear, even though it would stop from time to time due to resource restraints

                  JuvenalUrbino that's Great ? Thx!
                  But, no... I didn't forget the -E flag. And yes, I double checked that ADC|DAV_DEV were both pointing to /dev/audio
                  I'll build everything up again in the coming days and give it one more try.

                    Although... this actually means problem SOLVED ?

                    Let me salute your cussedness and persistence in getting this to work - awesome stuff ?

                      3 months later

                      Since I got my hands on a machine with a VT-x capable Intel CPU and 8GB RAM, I've been thinking about trying this all over with HAXM enabled; today I took the plunge and set up a Slackware VM.

                      Sounds works, with OSS backend, have to try SDL yet, here's a qemu script adapting to my hardware setting better:

                      env QEMU_OSS_DC_DEV=/dev/audio QEMU_OSS_DAC_DEV=/dev/audio qemu-system-x86_64 \
        -boot c --accel hax -m 6G -soundhw hda -display gtk -k it \
        -M pc -cpu Broadwell -smp cores=2,threads=2 -vga std \
        -device virtio-net,netdev=vmnic -netdev user,id=vmnic \
        -drive file=$HOME/VMs/linux.img,if=virtio,cache=none

                      Note on using HAXM with kern.securelevel > 0

                      You won't be able to load it afterboot with haxm-modload, so copy (or symlink if /usr is not on a separate partition) /usr/pkg/stand/amd64/9.0_BETA/modules/haxm directory to /stand/amd64/9.0/modules and do:

                      $ echo haxm >> /etc/modules.conf
$ echo modules=YES >> /etc/rc.conf

                      Don't know about Slackware, but Void on qemu-haxm could not stream Netflix, I had to use an Ubuntu base.
                      Actually, a Void-glibc qemu-kvm on Void-musl didn't work either!
                      Thanks for reporting back on this, really appreciated!! Above all, the tech details; they are the reason why I've even bother about it in the first place 😉
                      Thx!

                      5 years later
                      pin locked the discussion .