I need to host a ssh server on a x86-64 Debian squeeze machine with no VT-extensions :(

I am using virtlib with qemu (set up and working).

I have tried a number of things and non have been perfect, so I was hoping to draw on your experience.

I am used to using Debian-based Linux distros, so sticking with them is desirable but by no means critical.

So far I have tried x86_64 squeeze with no desktop, X, ect. but it is painfully slow. If I ps aux at any one time, there are loads of processes running, most of which are idling, but still.

I have also tried i386 damnsmalllinux in i686 qemu mode, once fluxbox and X had been terminated it was more than fast enough for my needs, but removing the desktop was a bad hack at best. I got it down to only handful of necessary processes which was good.

So my question is what makes DSL faster, is that it is kernel 2.4 and would installing Woody (Debian 3.0) yield similar results? Or was it that it was running x86-32 (on a 64bit host) or something else altogether.

If this were your system what would you do? Do you have any recommendations for a light distros that by default has no UI.

  • I don't understand your constraints or your requirements. What are you using a VM for? How much memory is allocated to it? What are you doing in it? What actions are slow? – Gilles May 22 '11 at 16:02
  • Hi, the VM is going to be a SSH server, a point of entry to a greater network, it needn't do much else than that, just all the other server do important task I do no want them to have an exposed ssh server. The vm has 512MiB of memory, I can give it more is you think it would help but it currently isn't touching more than a 3rd Also – 651bobby May 22 '11 at 16:13

Qemu is not the right tool for the job. Qemu emulates a whole computer, including the CPU. This is useful to run a virtual machine on where the virtual hardware is different from the host hardware, but this is not required here.

Furthermore, emulating an amd64 CPU is likely to be slower than emulating an i386 CPU. This alone might explain the difference between Debian/amd64 and DSL/i386. The extra processes would increase the boot time, but they have no impact on performance after that (idle processes consume memory, but by definition no CPU time).

To run Linux on Linux, the right tool is a specialized Linux-on-Linux virtualisation technology, such as LXC, Linux-VServer, OpenVZ or User mode Linux. Wikipedia and Linux Kernel Newbies have comparison pages to help you make a choice.


Painfully slow might be in relation to your I/O. I came to find out the hard way that this might be remedied by telling libvirt to use the virtio. To verify mine:

# virsh list
 Id Name                 State
 11 ca                   running
 13 new_box           running

# virsh dumpxml ca|awk '/disk/,/<\/disk>/'
    <disk type='block' device='disk'>
      <driver name='qemu'/>
      <source dev='/dev/xen02/ca.root'/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    <disk type='block' device='cdrom'>
      <target dev='hdc' bus='ide'/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' unit='0'/>

You can do this at install time or a bit more painfully, by editing the existing VM definition. Have a look at this

  • Thanks for the answer, I am sure that it is disk acesses slowing the machine down, and I do not seem to have virtio on; just normal bus='ide', does virtio work with no virtualisation extensions? thanks. – 651bobby May 25 '11 at 23:39
  • You could try instantiate a simple vm with virtio on. Or maybe edit the config for your existing vm and see. – Lmwangi May 26 '11 at 12:20

I just built a ssh VM at work a few days ago, for the same reason you want to build yours. actually, it's for outbound ssh forwarding for local workstations on private addresses as well as for inbound ssh proxying.

I just used debian squeeze (minimal base install, no X. about the only unusual thing was libpam-ldap for authentication via the university's Active Directory server...and proper configuration of /etc/security/access.conf of course so that only users in my faculty can login, and not every test/test account that some idiot in some other faculty has created in their OU. have also set up sshd_config so that password logins are only allowed from the local network, while connections from anywhere else require a public key. and iptables recent match rules to filter out the non-stop ssh script-kiddie probes)

the VM is 512M (probably more than is really needed), and virtio disk and network drivers. performance is more than acceptable. it only has 1 CPU allocated to it, i might have to add more if usage is higher than currently predicted (a few dozen academics and postgrads).

by "painfully slow", do you mean when you view the VNC console in virt-manager?

if so, that's a known bug - virt-manager's VNC performance is abysmal. the VM itself is fine, ssh into it runs at normal speed, a VNC connection from any other VNC client is great but using the VNC console built in to virt-manager is excruciating...you can see the individual characters appear on the screen one at a time as text is output.

  • Thanks for answering, by painfully slow i mean thing that I have come to except to be instantaneous on a normal install on take time to happen. I think it is disk access that is the biggest offender. – 651bobby May 25 '11 at 23:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.