Re: [Bulk] Re: slow qemu openbsd
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-miscm=133612760603867w=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-AT compat cpu0 at mainbus0: apid
Re: [Bulk] Re: slow qemu openbsd
On 2014-06-10, Kevin Chadwick ma1l1i...@yahoo.co.uk 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
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 ___
slow qemu openbsd
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???
Re: slow qemu openbsd
On Mon, 26 May 2014 19:16:12 +0400 Швецов Михаил mv...@ya.ru 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-miscm=133612666103598 kind regards, Robert
Re: slow qemu openbsd
On Mon, May 26, 2014 at 10:16 AM, Швецов Михаил mv...@ya.ru 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: [Bulk] Re: slow qemu openbsd
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-miscm=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 ___
