Re: [Bulk] Re: slow qemu openbsd

2014-06-10 Thread Stuart Henderson
On 2014-06-10, Kevin Chadwick  wrote:
> The kqemu port entry from the attic states.
>
> "remove kqemu (which was broken, reported by Alexander Schrijver and
> probably others) and qemu-old; the current qemu version in
> emulators/qemu works well now (kqemu is no longer supported upstream)."
>
> I guess works well means for emulating OpenBSD for kernel debugging
> (will these missing cpu features affect that?) and such which is more
> important but perhaps we need a second port for running Windows and if
> that is now failing what else may be (Linux?).

"a second port", you mean reinstate qemu-old? If so, you will also
need a port of gcc3, and backport some security fixes.



Re: [Bulk] Re: slow qemu openbsd

2014-06-10 Thread Kevin Chadwick
previously on this list Kevin Chadwick contributed:

> > So I'm hoping I can boot OpenBSD with qemu or Windows or Linux
> > under multiboot or alternatively boot xenserver or something off a usb
> > and select 2 or more of the multiboots to run concurrently.
> > 
> > Any input as to if this is possible with esxi or anything else would be
> > appreciated.  
> 
> So it seems Alpine-Xen with the bonus of grsecurity on dom0 is the
> closest and most flexible backstop option (if you have the supported
> hardware) and less tied to Linux especially for a single self-contained
> laptop and can boot existing partitions in hvm mode, so I can boot it
> from a multiboot partition or cd/usb or just usb hdd to install X on
> dom0. Please say if you disagree (this machine will be offline too, so
> little need to raise the security concerns that I understand quite
> well).

So I have to say I am rather unimpressed with the video speed of xen,
perhaps because I haven't had time to investigate using anything other
than localhost:vnc as of yet. I know you can use vga passthrough but I
would need two or three separate gpus on a laptop which is rediculous
and this got me thinking; if I have 4 cores likely mostly idle whilst I
am using windows then the case for kvm speed improvements is rather weak
where a power supply is available at least and the case for OpenBSD
native and non kvm strengthened further and so I wanted to compare the
difference. It wasn't the cpu and disk/net I/O that was a problem when
running Windows on Linux on a system without hardware virtualisation
but the gpu too.

So

http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg01415.html

http://openbsd.7691.n7.nabble.com/qemu-1-20-windows-2008-r2-td141219.html

https://bugs.launchpad.net/qemu/+bug/921208

http://marc.info/?l=openbsd-misc&m=133612760603867&w=2

The kqemu port entry from the attic states.

"remove kqemu (which was broken, reported by Alexander Schrijver and
probably others) and qemu-old; the current qemu version in
emulators/qemu works well now (kqemu is no longer supported upstream)."

I guess works well means for emulating OpenBSD for kernel debugging
(will these missing cpu features affect that?) and such which is more
important but perhaps we need a second port for running Windows and if
that is now failing what else may be (Linux?). If I do find I need
windows I guess I will look into the possibility of that port or
learning to love hibernate ;-) Can anyone confirm that a 32bit cd can
work with qemu?

kqemu was removed in aug 2011 and the following video is showing
windows 8 running in september 2011 which I believe is no longer
possible due to I think windows bailing out on missing cpu
options even when I believe the correct cpu type is chosen (Westmere
here).

www.youtube.com/watch?v=jYgUDD6_5JQ

Is virtualisation really just meant for server systems which is
laughably ironic considering the security complications.

It looks like bochs still works, atleast it gets to the 64 bit Windows 7
language selection after literally about 20 minutes.

A dmesg under bochs shows the cpu options to be exactly the same as the
host but under qemu they are reduced. I guess for qemu it is a choice
between blue screens if the unsupported options are ever attempted to
be used by Windows and immediately during the install but as there is a
report of "no crashes" in Sep 2011 I guess attempts to use them did not
or not often caused crashes.

The dmesg also shows the bios vendor to both be Vendor Bochs with qemu
having a date of 2011 and bochs 2007.

The qemu limited dmesg is below but the Actual natively reported CPU
supported features are:

cpu0: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 2926.55 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,
PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,
DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,
SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC
__

>> OpenBSD/amd64 CDBOOT 3.23
boot> 
cannot open cd0a:/etc/random.seed: No such file or directory
booting cd0a:/5.5/amd64/bsd.rd: 4185012+1360197+2919872+0+520656
[100+344496+223625]=0xd1d0b8 entry point at 0x10001e0 [7205c766,
3404, 24448b12, 45b0a304] Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights
reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved.
http://www.OpenBSD.org

OpenBSD 5.5-current (RAMDISK_CD) #131: Mon May 19 09:46:47 MDT 2014
t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 2130698240 (2031MB)
avail mem = 2068701184 (1972MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0a00 (10 entries)
bios0: vendor Bochs version "Bochs" date 01/01/2011
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpimadt0 at acpi0 addr 0xfee0: PC-A

Re: [Bulk] Re: slow qemu openbsd

2014-05-28 Thread Kevin Chadwick
previously on this list Kevin Chadwick contributed:

> So I'm hoping I can boot OpenBSD with qemu or Windows or Linux
> under multiboot or alternatively boot xenserver or something off a usb
> and select 2 or more of the multiboots to run concurrently.
> 
> Any input as to if this is possible with esxi or anything else would be
> appreciated.

So it seems Alpine-Xen with the bonus of grsecurity on dom0 is the
closest and most flexible backstop option (if you have the supported
hardware) and less tied to Linux especially for a single self-contained
laptop and can boot existing partitions in hvm mode, so I can boot it
from a multiboot partition or cd/usb or just usb hdd to install X on
dom0. Please say if you disagree (this machine will be offline too, so
little need to raise the security concerns that I understand quite
well).

The only question I believe I have left is if I should be looking at
KVM instead as OpenBSD has virtio which I guess does not work with xen
paravirtualisation or it's mix of the two (hvm/pv), is that the case?

I also am not sure how much virtio matters for my use case as I expect
cpu and memory and memory available to be the major factors but maybe
viomb matters? Linux swap handling as mentioned recently may be an
issue but hopefully swapiness=0 might fix that.

Thanks and I hope to find that qemu on native OpenBSD is perfectly
adequate for all tasks that I may need to do and just want to be
as prepared as possible if not.


-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___



Re: [Bulk] Re: slow qemu openbsd

2014-05-26 Thread Kevin Chadwick
previously on this list Robert contributed:

> > What I may do to work VM QEMU faster???  
> 
> Not much.
> QEMU is faster on Linux, because they use KVM - which doesn't exist on 
> OpenBSD. 
> 
> http://marc.info/?l=openbsd-misc&m=133612666103598
> 
> kind regards,

I'm switching my main workstation to OpenBSD and investigating if
xenserver can boot existing installations from an external usb without
specialist disk formats but the install seems rather poor (disk
selection, disk size) and makes me wonder about the competency of it's
development. It also seems to require two machines to function at all?

Qemu performance is of no issue for my immediate needs and I obviously
prefer to use OpenBSD native for many reasons including debugging
without wondering if the virtualisation is at fault and it would be nice
to have the last resort performant back stop option on a single laptop
of an external boot device to run multiple existing OS including the
natively installed OpenBSD and say Windows or Linux for certain tasks or
unavoidable commercial packages and switch back to native for most
things. So I'm hoping I can boot OpenBSD with qemu or Windows or Linux
under multiboot or alternatively boot xenserver or something off a usb
and select 2 or more of the multiboots to run concurrently.

Any input as to if this is possible with esxi or anything else would be
appreciated.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___



Re: slow qemu openbsd

2014-05-26 Thread Abel Abraham Camarillo Ojeda
On Mon, May 26, 2014 at 10:16 AM, Швецов Михаил  wrote:
> Maybe I'm doing something wrong. Please help me.
>
> I install openbsd 5.5 i386 and qemu-1.7.0 from packages.
>
> qemu-img create -f qcow2 /vm/qcow2.img 10G
>
> qemu-system-i386 -name qcow2 -nodefaults -m 512 -hda /mnt/ qcow2.img
> -cdrom /obraz/install55.iso -net nic -net
> tap,ifname=tun1,script=no,downscript=no -boot once=d -display
> vnc=0.0.0.0:1 -monitor vc -vga cirrus
>
> qemu-img create -f raw /vm/raw.img 10G
>
> qemu-system-i386 -name raw -nodefaults -m 512 -hda /mnt/raw.img -cdrom
> /obraz/install55.iso -net nic -net
> tap,ifname=tun2,script=no,downscript=no -boot once=d -display
> vnc=0.0.0.0:2 -monitor vc -vga cirrus
>
> QCOW2 works slower RAW, and RAW works slower host machine. I think that
> disc is the weakest link.
>
> I try set -hda /dev/rwd3c (disk itself – not system(wd0)) – but nothing
> changed.
>
> What I may do to work VM QEMU faster???
>


You could try using virtio in disk and network:

qemu-system-i386 -drive file=$img,if=virtio -net tap -net nic,if=virtio

I have found a measurable improvement using them.



Re: slow qemu openbsd

2014-05-26 Thread Robert
On Mon, 26 May 2014 19:16:12 +0400
Швецов Михаил  wrote:
> What I may do to work VM QEMU faster???

Not much.
QEMU is faster on Linux, because they use KVM - which doesn't exist on OpenBSD. 

http://marc.info/?l=openbsd-misc&m=133612666103598

kind regards,
Robert



slow qemu openbsd

2014-05-26 Thread Швецов Михаил
Maybe I'm doing something wrong. Please help me.

I install openbsd 5.5 i386 and qemu-1.7.0 from packages.

qemu-img create -f qcow2 /vm/qcow2.img 10G

qemu-system-i386 -name qcow2 -nodefaults -m 512 -hda /mnt/ qcow2.img 
-cdrom /obraz/install55.iso -net nic -net 
tap,ifname=tun1,script=no,downscript=no -boot once=d -display 
vnc=0.0.0.0:1 -monitor vc -vga cirrus

qemu-img create -f raw /vm/raw.img 10G

qemu-system-i386 -name raw -nodefaults -m 512 -hda /mnt/raw.img -cdrom 
/obraz/install55.iso -net nic -net 
tap,ifname=tun2,script=no,downscript=no -boot once=d -display 
vnc=0.0.0.0:2 -monitor vc -vga cirrus

QCOW2 works slower RAW, and RAW works slower host machine. I think that 
disc is the weakest link.

I try set -hda /dev/rwd3c (disk itself – not system(wd0)) – but nothing 
changed.

What I may do to work VM QEMU faster???