Re: Xen (and others Hypervisors) how do they handle IPIs?
On 26/09/13 03:48, Julian Elischer wrote: On 9/25/13 11:04 PM, Roger Pau Monné wrote: On 25/09/13 16:56, Julian Elischer wrote: If CPUs are mapped around, how are IPIs handled? I assume they must be emulated? I've noticed that under Xen (on both Amazon EC2 and a Redhat server) whenever you schedule a thread it always sits on the run queue for 20 uSecs before it starts running. It looks to me like it's the IPI taking a long time to be emulated. This has been improved on the FreeBSD Xen PVHVM port by using PV IPIs instead of the emulated ones, see r255331. It should be faster than the previous emulated implementation. I missed that.. thanks! Do you (or anyone else) know if this can be used on Amazon EC2? And do you need a specific version/configuration of Xen to be able to use it? The PV IPIs require Xen version 4.0 or greater, and the PV timer requires 4.0.1 or greater if I'm not mistaken. If you are lucky to get an Amazon instance that uses this Xen version (or any superior one) they will be activated by default, if not FreeBSD will switch to the old event delivery method and PV IPIs and PV timer will be disabled in favour of the emulated ones. I guess it's just a matter of time before Amazon switches all their servers to Xen 4.x. Roger. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: Xen (and others Hypervisors) how do they handle IPIs?
On 9/26/13 4:16 PM, Peter Grehan wrote: Hi Julian, If CPUs are mapped around, how are IPIs handled? I assume they must be emulated? For bhyve, if the target vCPU of an IPI is running, a null IPI is sent on the host to force it to exit so the IPI can be injected (vmm.c:vm_interrupt_hostcpu()). If the target is asleep due to being idle, it is woken up. And, if the target is running but not in vCPU context, an interrupt is queued up so it will be injected on the next vmenter (subject to the emulated local APIC interrupt priority) Does anyone know if BHyVe or HyperV also have this problem? Hmmm, hard to say. Would you be able to try your workload out on a bhyve system ? possibly in a few weeks.. I'll try remember when the time is right. later, Peter. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: PXE booting into a Hyper-V 2012 R2 instance - slows to a crawl?
On Tue, Sep 24, 2013 at 6:53 AM, Karl Pielorz kpielorz_...@tdx.co.ukwrote: We are creating new Hyper-V instances using our PXE boot environment (which boots you into a FreeBSD 9.1 amd64 O/S) - we'd build a Hyper-V aware kernel etc. from that (after SVN'ing the latest Hyper-V project source). PXE involves DHCP and TFTP. I would recommend that you do the following: (1) On the machine hosting your TFTP server, look at the TFTP logs and look for any clues. If your TFTP server is a FreeBSD box, look at /var/log/xferlog. I don't know what logs are available for a Windows TFTP server. (2) In between your booting machine, and your TFTP server, use Wireshark or tcpdump to capture the network traffic and analyze what is going on. (3) By default, the FreeBSD PXE loader uses a TFTP blocksize of 512 bytes per block (which is the original TFTP standard). You can increase the size of that to something bigger, depending on the MTU of your network. Usually 1400 bytes will work. In /boot/defaults/loader.conf, you can see this: #tftp.blksize=1428# Set the RFC 2348 TFTP block size. # If the TFTP server does not support RFC 2348, # the block size is set to 512. If the value # is out of range ( 8 || 9008 ) an error is # returned. If you put in yout /boot/loader.conf file: tftp.blksize=1428 you can see if that speeds up the TFTP transfer during PXE booting. Hyper-V would take seconds to boot this - but since changing over to R2 it takes a 'very, very long time'. The initial PXE bit happens quickly (i.e. seeing the server, and getting the BTX output out) but then it gets stuck with the \ spinner - it'll spin for a short time, stop, spin again for a short time, stop again. The spinner is the part where it is loading the kernel. For PXE, this is happening over TFTP. This looks like a slow network problem, so you need to analyze it a bit. I wrote some notes on PXE booting in FreeBSD which you might want to get some ideas from: http://www.freebsd.org/doc/handbook/network-pxe-nfs.html -- Craig ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
bhyve vmrum vm_setup_memory: Inappropriate ioctl for device
Just wanted to start testing with bhyve, but I'm getting this error creating an exmaple VM: # ./vmrun.sh -c 1 vm1 virtio disk device file ./diskdev does not exist. Creating it ... Launching virtual machine vm1 ... vm_setup_memory: Inappropriate ioctl for device ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: bhyve vmrum vm_setup_memory: Inappropriate ioctl for device
Sorry should have posted that info i the first mail! uname -a FreeBSD r2d2 10.0-ALPHA2 FreeBSD 10.0-ALPHA2 #3 r255788M: Mon Sep 23 00:32:50 UTC 2013 root@:/usr/obj/usr/src/sys/GENERIC amd64 dmesg only added an extra line it seams, when I created the tap0, other than that I see nothing! tap0: Ethernet address: 00:bd:05:89:47:00 Thanks On Fri, Sep 27, 2013 at 2:04 AM, Glen Barber g...@freebsd.org wrote: On Fri, Sep 27, 2013 at 01:59:04AM +, Miguel Clara wrote: Just wanted to start testing with bhyve, but I'm getting this error creating an exmaple VM: # ./vmrun.sh -c 1 vm1 virtio disk device file ./diskdev does not exist. Creating it ... Launching virtual machine vm1 ... vm_setup_memory: Inappropriate ioctl for device What does dmesg say? What is 'uname -a' ? Glen ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: bhyve vmrum vm_setup_memory: Inappropriate ioctl for device
Hi Miguel, On Thu, Sep 26, 2013 at 6:59 PM, Miguel Clara miguelmcl...@gmail.comwrote: Just wanted to start testing with bhyve, but I'm getting this error creating an exmaple VM: # ./vmrun.sh -c 1 vm1 virtio disk device file ./diskdev does not exist. Creating it ... Launching virtual machine vm1 ... vm_setup_memory: Inappropriate ioctl for device Your userspace is most likely out of sync with the kernel. Could you try to re-run after a buildworld and installworld? best Neel ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: bhyve vmrum vm_setup_memory: Inappropriate ioctl for device
I was actually just thinking about that... make buildworld is underway... I'll post any updates after the userspace install. Thanks On Fri, Sep 27, 2013 at 2:31 AM, Neel Natu neeln...@gmail.com wrote: Hi Miguel, On Thu, Sep 26, 2013 at 6:59 PM, Miguel Clara miguelmcl...@gmail.comwrote: Just wanted to start testing with bhyve, but I'm getting this error creating an exmaple VM: # ./vmrun.sh -c 1 vm1 virtio disk device file ./diskdev does not exist. Creating it ... Launching virtual machine vm1 ... vm_setup_memory: Inappropriate ioctl for device Your userspace is most likely out of sync with the kernel. Could you try to re-run after a buildworld and installworld? best Neel ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
CFT: PetiteCloud 0.1.3
Version 0.1.3 of PetiteCloud (a front end for bhyve) has been released. We would very much appreciate feedback from anyone inclined to test it. PetiteCloud can be downloaded (as a FreeBSD port) from http://petitecloud.org/port-0.1.3.tar.gz . New Features: * All startup initializations (including loading kernel modules and ifconfig's) are now 100% internal. Only one line needs to be added manually to /etc/rc.conf to start petitecloud at boot time. bootloader.conf needs no modification. * Setting screen added (password and bridged interface are the two current settings available) Bug Fixes: * Fixed wrong assignment of tap on startup * Fixed need for double password entry Instructions can be found in the README file. The user interface is still usable only by experienced sysadmins. (For example, you need to know what a network interface is.) Future versions of PetiteCloud will hide some of these details, making PetiteCloud more accessible to a wider range of users, and will have better input validation, etc. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
