QEMU

[Andrew Wood]

Can someone please help me configure QEMU on Jessie as the instructions
on the Wiki seem to not apply. The qemu command does not exist in
/usr/bin there are dozens of platform specific ones like /usr/bin/qemu-i386
but these dont seem to accept the same args.

Also why has qemu-launcher been removed from Jessie but it was in Wheezy
and its in testing?

Thanks
Andrew

[Mario Castelán Castro]

El 24/10/15 a las 10:13, Andrew Wood escribió:

> Can someone please help me configure QEMU on Jessie as the instructions
> on the Wiki seem to not apply. The qemu command does not exist in
> /usr/bin there are dozens of platform specific ones like /usr/bin/qemu-i386
> but these dont seem to accept the same args.

To launch QEMU, I use "qemu-system-x86_64 --enable-kvm [...]" (But I use
QEMU compiled from the upstream source package, so it may be different
with Debian 8 version). If you use a modern x86 computer, it will very
likely have support for virtualization; you should enable it with the
flag "--enable-kvm" for much better speed and efficiency. If you run
QEMU and notice it's much slower, it's likely because you forgot to
enable KVM.

In Debian 7, there is a separate KVM version of QEMU. In Debian 8, the
functionality has been merged into a single QEMU version and there is a
"qemu-kvm" package which is a wrapper that runs QEMU with KVM enabled.

> Also why has qemu-launcher been removed from Jessie but it was in Wheezy
> and its in testing?

I have never used it. Apparently it is not a part of QEMU but an
external graphical front end,

[Reco]

On Sat, 24 Oct 2015 16:13:50 +0100
Andrew Wood <andrewj...@ymail.com> wrote:

> Can someone please help me configure QEMU on Jessie as the instructions
> on the Wiki seem to not apply. The qemu command does not exist in
> /usr/bin there are dozens of platform specific ones like /usr/bin/qemu-i386
> but these dont seem to accept the same args.

I assume you meant https://wiki.debian.org/QEMU. So, for example:

qemu -hda debian.img -cdrom debian-testing-i386-businesscard.iso -boot
d -m 256

translated to the language of current stable, means:

qemu-system-x86_64 -hda debian.img -cdrom \
debian-testing-i386-businesscard.iso -boot d -m 256

You may also need to add your user to "kvm" group.

> Also why has qemu-launcher been removed from Jessie but it was in Wheezy
> and its in testing?

https://packages.qa.debian.org/q/qemu-launcher/news/20140802T163917Z.html
says:

Hint: <http://release.debian.org/britney/hints/auto-removals>
Bug #753669: qemu-launcher: /usr/bin/qemu does not exist any more

Basically, qemu-launcher merely run "qemu" with certain arguments,
which ceased to work once Debian stopped providing "/usr/bin/qemu"
executable. Which rendered the whole "qemu-launcher" unusable, and
since the maintainer was not able to fix the package - it was
rightfully removed from Jessie before the release.
The bug is still open, and as far as I can tell, the problem of this
package won't fix itself.

Reco

[Thomas Schmitt]

Hi,

Andrew Wood wrote:
> there are dozens of platform specific ones like /usr/bin/qemu-i386
> but these dont seem to accept the same args.

I use for a virtual Debian this script "start_debian_amd64":

#!/bin/sh
qemu-system-x86_64 \
-enable-kvm \
-m 512 \
-net nic \
-net user,hostfwd=tcp::4321-:22 \
-hda /data/vm/debian_amd64.qemu \
"$@"

For installation i created the disk
qemu-img create /data/vm/debian_amd64.qemu 8G
and ran the script with -cdrom
start_debian_amd64 -cdrom debian-8.2.0-amd64-netinst.iso -boot d

Normally i run it headless (and log in via ssh -p 4321 my_user@localhost):
start_debian_amd64 -nographic

> why has qemu-launcher been removed from Jessie but it was in Wheezy and
> its in testing?

Obviously because of the same difficulties which you experience.
See
https://packages.qa.debian.org/q/qemu-launcher.html
https://packages.qa.debian.org/q/qemu-launcher/news/20140802T163917Z.html
It does not get promoted to "testing" any more because of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753669


Have a nice day :)

Thomas

[Andrew Wood]

On 24/10/15 17:19, Reco wrote:
>
> I assume you meant https://wiki.debian.org/QEMU. So, for example:
>
> qemu -hda debian.img -cdrom debian-testing-i386-businesscard.iso -boot
> d -m 256
>
> translated to the language of current stable, means:
>
> qemu-system-x86_64 -hda debian.img -cdrom \
> debian-testing-i386-businesscard.iso -boot d -m 256
>
>
>
>

> Basically, qemu-launcher merely run "qemu" with certain arguments,
> which ceased to work once Debian stopped providing "/usr/bin/qemu"
> executable. Which rendered the whole "qemu-launcher" unusable, and
> since the maintainer was not able to fix the package - it was
> rightfully removed from Jessie before the release.
> The bug is still open, and as far as I can tell, the problem of this
> package won't fix itself.
>
> Reco
>

Excellent thank you. I installed QEMU a couple of years back under
Wheezy but havent done much with it so I was confused as to why things
were no longer working since upgrading to Jessie.

One other question. Is it possible to run it on a non GUI host ie a
Debian system without X installed but run guest operating systems which
do require a GUI such as MS Windows or Haiku?

Andrew

[Reco]

Hi.

On Sat, 24 Oct 2015 22:30:55 +0100
Andrew Wood <andrewj...@ymail.com> wrote:

> One other question. Is it possible to run it on a non GUI host ie a
> Debian system without X installed but run guest operating systems which
> do require a GUI such as MS Windows or Haiku?

Sure, that's exactly what big kids are doing :)

Currently you have three ways of doing it (all do not require X):

1) Universal one, but slow.

Adding something like "-vnc 0.0.0.0:0" to qemu commandline will force
qemu to provide a VNC server on customary tcp:5900, and guest OS will
draw to VNC server only.
You can also try altering "-vga cirrus"/"-vga std"/"-vga vmware" to
switch the video card you provide to the guest OS (not everyone can be
happy with 16-bit color 1024x768 cirrus provides, and it's used by
default).


2) Hardcore one.

Adding my favorite "-nographic" to qemu commandline will force qemu not
to provide VGA adapter to the quest system and to force a serial
console to stdin/stdout.
It's a required parameter more-or-less once you start using *other*,
non-x86, qemu-system binaries.


3) RedHat one.

Adding "-vga qxl -spice port=5900,disable-ticketing" to qemu
commandline will force qemu to use built-in SPICE server (akin to VNC,
but requires own client) on tcp:5900.
As a bonus, you should get the sound transferred from the quest to you.
As a malus - unless you're planning to use Linux - you'll need QXL
drivers.

Reco

[Andrew Wood]

On 24/10/15 22:56, Reco wrote:
> Currently you have three ways of doing it (all do not require X): 1)
> Universal one, but slow. Adding something like "-vnc 0.0.0.0:0" to
> qemu commandline will force qemu to provide a VNC server on customary
> tcp:5900, and guest OS will draw to VNC server only.

That works great but is it possible to specify a port or an IP address?
I tried replacing -vnc 0.0.0.0:0 with the IP of the host but QEMU
refused to start. I tried using 0.0.0.0:5901 and it started but I cannot
connect remotely using Vinegre by specifying the port even though there
is no firewall issue.

[Reco]

Hi.

On Thu, Oct 29, 2015 at 08:47:51PM +0000, Andrew Wood wrote:
>
>
> On 24/10/15 22:56, Reco wrote:
> >Currently you have three ways of doing it (all do not require X): 1)
> >Universal one, but slow. Adding something like "-vnc 0.0.0.0:0" to qemu
> >commandline will force qemu to provide a VNC server on customary tcp:5900,
> >and guest OS will draw to VNC server only.
> That works great but is it possible to specify a port or an IP address? I
> tried replacing -vnc 0.0.0.0:0 with the IP of the host but QEMU refused to
> start.

Specifing $SOME_IP instead of 0.0.0.0 should be possible, although I
have to admit that I've never tried it (127.0.0.1 does not count).
But 'refused to start' lacks some specific details:

1) What vnc stanza have you use?

2) What's the list of IPs on the host that runs QEMU?

> I tried using 0.0.0.0:5901 and it started but I cannot connect
> remotely using Vinegre by specifying the port even though there is no
> firewall issue.

VNC follows the simple rule: VNC port + 5900 = TCP port.

So, you should either use tcp port 11801, or specify 0.0.0.0:1.

Reco

[Andrew Wood]

On 30/10/15 09:36, Reco wrote:
> Specifing $SOME_IP instead of 0.0.0.0 should be possible, although I
> have to admit that I've never tried it (127.0.0.1 does not count). But
> 'refused to start' lacks some specific details: 1) What vnc stanza
> have you use? 2) What's the list of IPs on the host that runs QEMU?

> VNC follows the simple rule: VNC port + 5900 = TCP port. So, you
> should either use tcp port 11801, or specify 0.0.0.0:1. Reco

Sorry for the delay in picking this up, I do a bit of experimenting with
it as and when.

It works now it was because I was trying to specify the port literally
rather than +1. Who thought of that? It seems rather strange. Does than
mean you cant put it on a port below 5900?

Also is there any option in QEMU to require some sort of VNC
authentication? I cant find anything online about it under QEMU but I
believe the VNC protocol does support authentication? Would it for
example be possible to ask it to verify a users username & password
against the standard Debian users file and even go one step further and
allow or deny access to certain qemu guests based on the users group?

[Reco]

Hi.

On Tue, 29 Dec 2015 21:05:20 +0000
Andrew Wood <andrewj...@ymail.com> wrote:

> On 30/10/15 09:36, Reco wrote:
> > Specifing $SOME_IP instead of 0.0.0.0 should be possible, although I
> > have to admit that I've never tried it (127.0.0.1 does not count). But
> > 'refused to start' lacks some specific details: 1) What vnc stanza
> > have you use? 2) What's the list of IPs on the host that runs QEMU?
>
> > VNC follows the simple rule: VNC port + 5900 = TCP port. So, you
> > should either use tcp port 11801, or specify 0.0.0.0:1. Reco
>
> Sorry for the delay in picking this up, I do a bit of experimenting with
> it as and when.
>
> It works now it was because I was trying to specify the port literally
> rather than +1. Who thought of that? It seems rather strange. Does than
> mean you cant put it on a port below 5900?

Not by QEMU itself:

$ qemu-system-x86_64 -vnc 127.0.0.1:-1
qemu-system-x86_64: Failed to start VNC server on `127.0.0.1:-1': can't
convert to a number: -1

It should be possible though if you use 'nat' table of iptables, or any
port bouncer. For example this should allow to connect to QEMU's VNC
via tcp port 443:

iptables -t nat -I PREROUTING -p tcp --dport 443 \
-j REDIRECT --to-ports 5901

> Also is there any option in QEMU to require some sort of VNC
> authentication?

Yes. A basic form of authentication would look like this:

qemu-system-x86_64 -vnc 127.0.0.1:1,password=foo

Since supplying a password in process' arguments is an extremely bad
idea - you'd probably better use SASL. See qemu-system-x86-64(1).

> I cant find anything online about it under QEMU but I
> believe the VNC protocol does support authentication?

Indeed it does. The trouble is - every form of VNC authentication is an
extension of VNC protocol, and QEMU managed to implement its own
VNC-via-TLS, for example). A basic QEMU's password authentication
works with TightVNC client though.

> Would it for example be possible to ask it to verify a users username &
> password against the standard Debian users file and even go one step
> further and allow or deny access to certain qemu guests based on the
> users group?

Even such authentication is not possible via simple means, as that
would require two things:

1) Running QEMU as root. A very bad idea.
2) Implementing PAM authentication in QEMU. It is not there (yet?).

Best you can do is either have 'one password fits all' security model,
or a custom 'username-password' pairs SASL database. If you manage to
convince SASL to work with Kerberos, and to convince Debian OS users
also authenticate with Kerberos - than you'll have an illusion of what
you're trying to achieve.

Reco