QEMU on DS-508 (Getting it to work)

Questions that don't fit in any category below may go here
Forum rules
Please note the disclaimer before modifying your Synology Product.
User avatar
Posts: 62
Joined: Sun Apr 26, 2009 2:48 am

QEMU on DS-508 (Getting it to work)

Postby DevineMe » Wed Jan 27, 2010 9:55 pm

Not too many post touching on running QEmu on the Synology so I guess I will start it off.
My own personal motive is to get a small image of FreeDos up and running with network support.
The current QEmu on the DS-508 although compiled, seems to be disfunctional. I have spent
hours reading howtos on QEmu and learning what ports are going where on Linux and
still can't seem to get the QEmu working...

... So QEmu is running for the most part. Just not useful (at all) because the virtual system (CPU) is always halted.
Experts, any input?

Seems I was wrong see the follow up post.
User avatar
Posts: 62
Joined: Sun Apr 26, 2009 2:48 am

Re: QEMU on DS-508 (Getting it to work)

Postby DevineMe » Sun Apr 04, 2010 5:22 am

Pertinent info before you jump into this post..
1) I still have yet to get the networking working under this version of Qemu for Synology.
a) I tried many Qemu networking options but I still have not tried another Guest OS other then Freedos.
My Freedos Guest OS DOES DO what it is supposed to under Ubuntu.
b) Netstat reports packets for the Guest OS are stuck in the "Revc-Q", I don't know why.

2) A Linux noobie wrote this so you may get much father then me, if you do please follow up.
3) First draft post and is subject to correction. That said...

I feel I might opening "Pandora's box" with this post but what the heck. There have been other post about using
"Qemu-i386 user mode" to run Linux targets but not Qemu which is a bit different. I originally intended to use Qemu to run a
small Freedos image and play around bit in it on my Synology DS-508 in my spare time. My first attempts where
quite unsuccessful. I have a bit of computer knowledge and yet everything thing lead to "Qemu for Synology
just does not work". I had no reason what so every to believe that Qemu was working because so much
vital feedback parameters had been stripped from the executable in order to get it to compile (from what I
read). For instance, there is..

NO -SDL support = no graphics = no monitor window, this makes sense because Synology has no vid card and most
every thing is done via a telnet/ssh term anyways.

NO -VNC support = no graphics = no monitor window, this was done because the -SDL libs where mixed in with the SDL
code (from what I read) so it was shut off, again to get Qemu to compile.

NO -SDL or -VNC = NO visual feedback what-so-ever from the Qemu Guest OS itself. = completely blind.
The only way to see if anything is running given the current version of Qemu for Synology is to have the
emulated pc run some networking application such as ping and try to contact a computer outside the Qemu
emulation environment. Careful though, your net settings inside the Guest OS have to be correct from the get go and
you will not be able to see a dam thing. In addition to the possibility that the emulated PC may not be running at all
because again you can't see a dam thing. Ya ok no problem, I did find a cool shortcut I will explain a bit later.

NO updated parameters from v0.8.0 (Synology version) to v0.9.0 (current release)= no new ways of connecting to the
Guest OS = limited view of what is happening inside Qemu itself.

That's just for starters. Still I kept tinkering with Qemu on Windows and Ubuntu compared results with the version available
on Synology. I'm going to skip the head banging, swearing, frustration and confusion parts and get strait to the point.

I WAS WRONG!!! On 3-27-2010 at 4:15 am. I got my first Freedos image up and working on
Synology running Qemu (not Qemu-i386 user mode) from a disk image.

These are some of my notes.

Console, Monitor and Other = [Please control your language]? = confusion.

After starting QEMU with -nographic (headless or no vid card mode (btw contradiction, explain later)) you
are at the Qemu console, You have to hit ["Control-a"] then a command. Hit ["Control - a" "h"] for help.
Staying in console mode after starting Qemu on Synology is not advisable nor is hitting the wrong keys
while in the Qemu console mode. I have experienced multiple lockups just by hitting the wrong key in console mode.
I suggest using monitor mode right after starting Qemu, it much more responsive with much much less lockups and
I don't know why, please keep reading. Closing a terminal window after a lockup will terminate Qemu, fortunaly.

If you hit ["Control - a" "c"] then you switch over to monitor mode which looks exactly like the console mode you where
just in. It is not, you CAN now type commands with no Control key required. Type ["?" "Enter"], for help. In monitor
mode you do things such as reset the emulation pc, memory dumps, registers peeking and etc. If you do
a "info" you get vital information about the emulated system, however, much has been stripped in comparison
to Qemu on other platforms.

Note : Qemu running on x86 PCs without -nographic enter the, what I call, Console, Monitor and Other mode.
The console is in the launch window. The monitor is in the graphic visual window. You get to it by hitting
["Control"+"Alt"+1] then you can do a "info" command. The graphics window part is unlabeled as the documentation
mostly refers to console and monitor modes, not explicitly the graphic part which is important when your trying to
discern where graphical information is being stored and how to re-route this graphical display information to new

Qemu VLan = exactly VLan = Qemu Virtual Lan = NOT YOUR PHYSICAL LAN, if you confuse the VLan
parameter in your head to mean "Your Physical Network" (as I did at first) your going to be a while coming to
conclusion that VLan is a virtual network Qemu uses to set up and network "Virtually" with other copies
of Qemu running on the same or different host systems. Given that the "Tap", "HostFwd" and "-redir", the parameters
that actually do hook up to your Physical lan, are mixed in the -net parameters adds a bit to confusion.

Qemu on Synology Emulated the NE2000 Nic.
Switching PC emulation via -M switch changes Nic card emulated profile in Qemu and directly effects the guest system Nic.
In [-M pc] mode DOS Nic profile is : NE2000 0x60 11 0xc100 (thats Vector, IRQ, address respectively)
In [-M isapc] mode DOS nic profile is : NE2000 0x60 9 0x300 (thats Vector, IRQ, address respectively)
you can verify via Qemu monitor mode : Info pci
Profile is the same for all Qemu targeted guest OSs, in a linux guest, the Nic would still be 0x60 11 0xc100 with the
-M pc profile. Note : Qemu running on a x86 PC (Ie Unbuntu or Windows) have multiple options, for different emulated cards.
I stuck with Ne2_pci and Ne2_isa emulations, on all tests because these are the ONLY TWO available on the Synology
Qemu version.

Connecting into the guest system network.

Qemu emulates DCHP and DNS servers for the Guest OS. The changeable (see docs) system defaults are for the default Qemu IP for guest system Nic . for the default Qemu Gateway for the default Qemu DNS server.

Port Forwarding,
-redir Available on Qemu for Windows & Linux
As the Linux info command suggest, -redir ->can<- produce unreliable results. This is what I have experienced.
On Windows XP, telnet connects to -redir port but guest sits idle.
On Ubuntu, telnet connected locally and from windows machine.
On Synology. telnet connected to -redir port but guest sits idle.

-net user,HostFwd (replaces -redir in later Qemu versions) available of Linux (but not v8 Synology version)
On Ubuntu, works as it should telnet connect locally and from windows machine.
Not available on Windows or the older Qemu version that Synology has available for it.

-net Tap: Tap is available on all of the Qemu systems.Windows users can use a coLinux driver to create a NIC.
Linux users can use "tunctl" to create a NIC. This is the preferred way as it is a more direct approach and
one merely has to access the new NIC to connect into the guest system network. The tap can then access
other network resources when bridged to the physical NIC on Windows or Linux.

MacAddr parameter : Specify it (make up then number) and use it. Things seem to go alot better when you defined this

Note : When using -M pc vs -M isapc, if you don't specify the model ie "model=ne2_pci" in -M pc mode, Qemu WILL NOT
pass the Guest OS the mac address for some reason. If you use that mode, please specify the model, even on the Synology
Qemu version where this seems undocumented.

The most important part...
How to get a running System Guest under Qemu on Synology. What I did..

Putty - telnet client for windows, connects to Synology via SSH and launches Qemu.
NetSniff with PCap driver, watch all packets conversions.
MagicISO, for creating ISO files from plain old directories on Windows.
IrFanView, for view PPM pictures of the running Guest console.

-Guest OS-
FreeDos - Started with Freedos Base cd and a German pre configured "ready to run" version.

-Test Computers-
1 Windows XP pc
1 Ubuntu Laptop
1 Synology DS-508

-Install Qemu on Synology- (If lost on this part, see other posts about installing and using Ipkg)
Login Root
Ipkg update
Ipkg Install Qemu

Verify by typing "Qemu". If it runs exit terminal.

-Building the Guest-
General Idea : Create a target Guest OS using identical launching parameters available on Synology's Qemu, Windows Qemu
and Ubuntu Linux Qemu. Should work similarly for other Guest OSs.

Step 1) I examined the German Freedos version to see what he did to set up networking and looked over the configuration files.

Step 2) I installed guest OS from the Freedos base version on to a new empty image (created with Qemu-create.exe, no qcow)
because changing the language settings in the config files (autoexec.bat and config.sys) was not enough to change the language.
Then I ran the two images at the same time under windows Qemu, and copied over the config files.

Step 3) I created a "NetUtils" disk and filled it with some free networking utils designed to work with WatTCP Dos network
stack. I ran those two images side by side and loaded files onto my Guest OS. I used Magic ISO to create the cdrom ISO
image with the network utils and ran it as a -cdrom under Qemu.

Step 4) I configured my Guest OS via years of past DOS experience gone by (yeah right). Qemu provides defaults, fortunaly, for
the emulated NIC, DCHP, and DNS. So using this, we can set our OS networking using these defaults and it "Should" the
same, regardless of the Qemu version. (And it works). See "Qemu emulates DCHP and DNS servers" for the defaults.

Step 5)Setup a network server. FTP, TelnetD, any server and run it automatically via the autoexec.bat. We will know the
Guest OS is actually running when we connect into it. I used Telnetd by WatTCP author Eric ??? to telnet in to DOS.

Step 6)Copy the Guest images to Ubuntu Box for testing. Using the identical launching parameters in a sh script instead of
a windows .bat file, we run our image (Sudo sh Script.sh) and connect to the server. Sudo is required for port forwarding
rule creation.

Note: Ubuntu Qemu seems to do a better job at this then Qemu on windows. So if what your trying to do on windows does
not work, try it on Ubuntu. First via localhost then by IP number, then from a windows client. If it does not work on Ubuntu at first use
a free firewall to open the port for connections (I used FireStarter).

Last Step.) Run OS from Synology Qemu. Login root via Putty and SSH on windows and copy over the SH and Image files
to a new directory, I called mine "OS". Note: If you put the dir in the main Root directory ("FS root" i think it's called), your DS is
going nuke(delete) it on your next firmware update, you can just copy it back, or put it somewhere else. Don't forget to
back it up before updating firmware. Launch it - "sh Script.sh". If successful you will see a Qemu Prompt. That is the console
mode. Hit ["Control a" let go "c"] for the monitor mode. Then type "info", if you get feed back, your in monitor mode.

Now for my Secret (no good post is great without one). To actually see your Guest OS running on you Synology.
Do a ... "screendump ../volume1/YOUR SHARE/GuestOS_Name_ScreenShot.ppm" command.
Note : You HAVE to be in monitor mode to do this.
You can use the fabulously awesome and free IrFanView to view the file and have a look at your new OS running
your Synology Box. Had I inspected all the Qemu commands sooner, I would have seen the command and seen that
the Guest OS was actually indeed running and that my issues with Synology Qemu were really networking connection
problems. You cannot connect via the network with the Qemu Guest image. Can't for the life of you convince yourself
such a thing could possibly be running on your tiny Syno box. Still don't believe it? Put a executable
in your start up that just displays a simply Count. (IE 1.2.5...1111) Take a screen shot after boot. If the number changes
between screen shots, start jumping for joy because it's running.

Dos and Windows Notes : DosIdle.exe (v2.10) is a TSR utility that generates a "Idle event" by cally HLT instructions in assembler.
It also can use ACPI BIOS instructions and has a dramatic difference at runtime. You can observe this by enabling/disabling then
rebooting the VM and watching the Synology Resource Monitor in the DSM. Difference goes from 94-98% to 2-5% cpu plots,
disabled/enabled respectively. Amazing comparison, the running Qemu DOS Emulation, DosIdle enabled, used as much as
the Synology DSM Resource Monitor! A program exists for Win95 and Win98 clients called CPUIdle which does the
same thing.

Fundamental contradiction : You can run -nographic and -std-vga parameters at the same time. This has yet to be tested within
a Guest OS. I believe this contradiction MAY be good for running a graphic apps but a app analogous to a VNC server would
have to read the video memory and send it to a client. A simpler solution would be just to get the pre-existing VNC code
complied into Qemu instead creating such another analogous application separately.

-In conclusion-

I think there hasn't been a Qemu update because I don't actually think anyone verified the Optware Qemu (not the
Qemu386 version, apparently known to work) was working on Synology. It's been two years since it's release and
Qemu386 was the only thing updated to my knowledge. Now that I verified IT IS IN FACT RUNNING, this most
defiantly deserves a update to get the basic networking issues updated. Maybe add VNC if at all possible.

The -daemonize parameter is also missing from the Synology Qemu. While there are quite a few ways to
start Qemu automatically other then -daemonize, if a lockup occurs, which has happen to me in the past, a utility
or script is needed to restart and maybe monitor Qemu.

Finally, I said "Pandora's box" because, now, this makes many new things possible. Like...
*Running a small Linux distro with a headless vnc server (name) and mixing the two Linux systems seamlessly.
*Letting the new Linux Distro tap into the Synology Usb subsystem and get more devices working.
*Giving a new home to a old Dos based BBS via a dedicated low energy networking device built for that very reason. (Ideal environment)
*Dreaming up your own stuff.
Note: Most of you x10 owners have 800mhz more power then me. I'm still not complaining, my DS508 is still awesome.

And ALL this is provided from running within a self contained image, that does not interfere with the main Synology
system or system updates. Yes it does behoove us to get a updated Qemu package up. Unfortunately, yours truly is
not the person to do such a thing, I'm just a Linux Noobie with a whole bunch of computer knowledge pertaining to
stuff other then Linux, but I'm learning.

--------------------- Quick Summary ------------------

Create a Guest OS using the default Qemu networking parameters.

Test on a Linux box.
*Don't for get to open a port.
*Use a free firewall to do this if you must.

Copy over to Synology box and launch
sh YourScript.sh

(Note: Do not mistype "sh YourImage.img", that will create a weird 0 length file and crap out with a strange error.
Use different Script and Image names to avoid this. I start my image names with a underscore "_")

Do a screen capture to verify it is is running in Qemu monitor mode.
["Control - a" let go "c"]
type "screendump ../volume1/YOUR SHARE/GuestOS_Name_ScreenShot.ppm"
View with IrFanView

What not to do.. Run a graphical OS. Headless is another topic.
On Qemu lockup, monitor mode will not accept input. Close Putty and restart another session.
Heres my wining Qemu launch parameters, should work with ANY guest image if you use the Qemu
defaults to set up the Guest OS I explained above. Adjust the Ram (-m param) for your Synology and the
OS. Make up a MAC number "out of thin air".

Qemu defaults again...
Default Qemu Guest Nic IP :
Default Qemu Guest Gateway : (Ping'able and good for testing your Guest OS networking)
Default Qemu Guest DNS server :

YourLaunchScript.sh (all one line, I separated for clarity)

(PC mode)
-hda YOURIMAGE.img -boot c
-m 16
-net user
-redir tcp:23:
-net nic,model=ne2k_pci,macaddr=02:03:ab:02:1c:31
-M pc

Network card profile in this mode = 0x60(Vector), 11(IRQ), 0xc100(Address)

(PC ISA mode) Older hardware mode emulation for older software.
-hda YOURIMAGE.img -boot c
-m 16
-net user
-redir tcp:23:
-net nic,model=ne2k_isa,macaddr=02:03:ab:02:1c:31
-M isapc

Network card profile in this mode =0x60(Vector), 9(IRQ), 0x300(Address)

"From version 0.8.0, -isa option is changed to -M isapc option. When you use ISA NE2000 card with -M isapc option, a network in a guest OS isn't
configured automatically. It needs to set it by yourself." Hmm.. Really? That's Synology's version. I wish the documentation for v0.8.0 was not so
hard to track down.

To add a second hard drive image (add to the above)
-hdb C:\Your_Dir\YOUR_2nd_IMAGE.img

To add a CD Drive. (add to the above)
-cdrom C:\Your_Dir\Your_ISOImage.Iso

To create a new image, (qcow not required)
qemu-img create C:\Dir\YourImage.img 240M
qemu-img create C:\Dir\YourImage.img 1G

First OS might be the hardest to get up and running, Second one, will be a breeze because you will know
Qemu system parameters and defaults to use. ->None of them<- will be as challenging as it was to figure
all this out and type it up. But hey, that's over now and this post now finally exists. Free OSs can then be
packaged up and distributed with a Sh script ready to run.

Ideas for others. Create a Synology DSM package that creates a new DSM page that in turn loads the
free web embedded Flashterm. This would be neat because one would could quickly login into
the Syno shell or BBS via telnet right from the DSM. Flashterm does not support ssh currently. Also good for those of us that
will be running BBSs on our Synologies.

Linux FYIs
Bond0 device: Created and controlled vai DSM -> Network -> Link Aggregation.
iptables : Created and controlled vai DSM -> Firewall.
Tun/Tap : Persistent connection can be created with OpenVPN. Tuncrl helpful but not available.
Tun/Tap are both in same "tun.ko"module, directory is ../libs/modules/ included in new firmware.
Brctl (bridge control ): (Update, thx zyxmon) Kernel module in bridge-utils.ipk (will try new configuration as time permits)

Setup a DOS BBS using Qemu
Qemu v0.8.0 (using way back machine)
How to use Qemu networking for windows.
Networking Freedos
Last edited by DevineMe on Tue Jun 01, 2010 5:13 pm, edited 5 times in total.
User avatar
Posts: 208
Joined: Fri Apr 23, 2010 9:30 pm

Re: QEMU on DS-508 (Getting it to work)

Postby zyxmon » Sun May 02, 2010 7:47 pm

DevineMe wrote:...
Brctl (bridge control): Kernel module not currently available

brctl is in bridge-utils ipk. just wondering if it is working.
Entware & Qnapware for embedded Linux systems
User avatar
Posts: 62
Joined: Sun Apr 26, 2009 2:48 am

Re: QEMU on DS-508 (Getting it to work)

Postby DevineMe » Mon May 03, 2010 2:03 am

zyxmon wrote:
DevineMe wrote:...
Brctl (bridge control): Kernel module not currently available

brctl is in bridge-utils ipk. just wondering if it is working.

Cool, I didn't know that.. That will defiantly give me something to try the next go round. I haven't had the time to tinker with it lately, but that is definitely a good tip. I posted my results over on the NSLU2 general group, essentially letting them know that "Hey, that Qemu v0.8.1 compile for the Synology optware branch, essentially works and there could be some new possibilities for all the optware branches". It's been about 2-3 years since that package was made and I don't think it was really validated before now. (If it was nobody, posted.) I seen Josh P. (Qemu package creator) was amongst the users over there, but the post addressing the Qemu where kinda old. It's a shame to see the Guest OS sitting there running with no way to communicate with the HostOS (that I am aware). Although the above post is rather long (I included most of the information I thought might be used as quick reference), it's not the really hard to try for yourself. For testing you can use any old shell Linux OS with net utils installed, check operation on Qemu for Windows, then on Ubuntu, then transfer the image to the Syno box. Next simply create a .sh launch script in the same directory as the image.

.sh contents example
"qemu -hda YOURIMAGE.img -boot c -m 16 -localtime -net user -redir tcp:23: -net nic,model=ne2k_pci,macaddr=02:03:ab:02:1c:31 -M pc"

Run it
Hit ["Control a" let go "c"] at the Qemu Prompt

Then do a
"screendump ../volume1/YOUR SHARE/GuestOS_Name_ScreenShot.ppm"
to see your Guest OS running on your Synology.

Lastly figure out how to configure the Host to talk to the Guest (the part where I am stumped). Maybe FreeDos was not a good starting point as Linux has mature networking utils and usally does a great job of networking in general. I don't know as I have not tried any Linux distro image yet. Again I will post when I find out more info, might be a while though. Just remember to turn off any graphical "splash screens" during you Guest system boot because SDL is not supported.

Return to “General Mods”

Who is online

Users browsing this forum: No registered users and 2 guests