Re: VirtualBox + VIMAGE
On Wed, Jan 26, 2011 at 5:19 PM, Bernhard Froehlich de...@freebsd.org wrote: On Wed, 26 Jan 2011 16:25:28 +0200, Mikolaj Golub wrote: On Wed, 26 Jan 2011 10:22:40 +0100 Bernhard Froehlich wrote: BF Sounds like it's my turn now. Which FreeBSD version is required to be BF able to use it? As Bjoern noted it is for __FreeBSD_version = 800500. BF Is VIMAGE enabled per default and what happens if VIMAGE is disabled - BF does it at least build fine with that patch? We have VIMAGE disabled by default. I have added to src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile: .if defined(VIMAGE) CFLAGS += -DVIMAGE .endif So to build the driver for VIMAGE enabled kernel one should run VIMAGE=1 make If VIMAGE variable is not defined the module for VIMAGE disabled kernel will be built. http://home.bluelife.at/patches/virtualbox-ose-kmod-devel-VIMAGE.diff I've integrated it a bit better into the VirtualBox build system, added the ports stuff and updated the patch for VirtualBox 4.0.2. It is currently unclear to me why you add VIMAGE to CFLAGS but nowhere check for VIMAGE in VBoxNetFlt-freebsd.c. Shouldn't we add a check for VIMAGE in the #if defined line or is this already done somewhere deep in the included headers? -- Bernhard Froehlich http://www.bluelife.at/ I managed to completely miss your patch posted this thread, so I just gave it a try on bluelife's virtualbox-ose-kmod svn r1239; it's working well. I've started each of my guests with bridged networking to be sure, and I see no panic (or any other anomaly) during boot or normal operation. Do you have plans on merging the patch soon? -Brandon ___ 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: VirtualBox + VIMAGE
On Wed, Mar 2, 2011 at 2:52 PM, Bernhard Froehlich de...@bluelife.at wrote: On Wed, 02 Mar 2011 21:31:45 +0100, Bernhard Froehlich wrote: On Wed, 2 Mar 2011 08:30:01 -0600, Brandon Gooch wrote: On Wed, Jan 26, 2011 at 5:19 PM, Bernhard Froehlich de...@freebsd.org wrote: On Wed, 26 Jan 2011 16:25:28 +0200, Mikolaj Golub wrote: On Wed, 26 Jan 2011 10:22:40 +0100 Bernhard Froehlich wrote: BF Sounds like it's my turn now. Which FreeBSD version is required to be BF able to use it? As Bjoern noted it is for __FreeBSD_version = 800500. BF Is VIMAGE enabled per default and what happens if VIMAGE is disabled - BF does it at least build fine with that patch? We have VIMAGE disabled by default. I have added to src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile: .if defined(VIMAGE) CFLAGS += -DVIMAGE .endif So to build the driver for VIMAGE enabled kernel one should run VIMAGE=1 make If VIMAGE variable is not defined the module for VIMAGE disabled kernel will be built. http://home.bluelife.at/patches/virtualbox-ose-kmod-devel-VIMAGE.diff I've integrated it a bit better into the VirtualBox build system, added the ports stuff and updated the patch for VirtualBox 4.0.2. It is currently unclear to me why you add VIMAGE to CFLAGS but nowhere check for VIMAGE in VBoxNetFlt-freebsd.c. Shouldn't we add a check for VIMAGE in the #if defined line or is this already done somewhere deep in the included headers? -- Bernhard Froehlich http://www.bluelife.at/ I managed to completely miss your patch posted this thread, so I just gave it a try on bluelife's virtualbox-ose-kmod svn r1239; it's working well. I've started each of my guests with bridged networking to be sure, and I see no panic (or any other anomaly) during boot or normal operation. Do you have plans on merging the patch soon? It's not committed because it doesn't work. What i have tested so far is with stock 8.2-REL so without VIMAGE. enabled VIMAGE option on stock 8.2-REL: bridging works fine disabled VIMAGE option on stock 8.2-REL: crashes vm with an assert Expression: !pPatchToGuestRec Location : /usr/home/decke/blueports/emulators/virtualbox-ose/work/VirtualBox-4.0.4_OSE/src/VBox/VMM/VMMR3/PATM.cpp(116 6) void patmr3AddP2GLookupRecord(VM*, _PATCHINFO*, uint8_t*, RTRCPTR, PATM_LOOKUP_TYPE, bool) It looks like that assert is not related to the VIMAGE patch. Works fine now since half an hour. Could someone with an VIMAGE kernel please test the patch? Just configure a VM with bridging and let it transfer a few bytes. Once with the option enabled and once disabled. I've had a machine running a linux guest for almost a day, bridging with a VIMAGE kernel, while capturing traffic on the virtual interface (and performing a few other tasks) -- so far, so good. No panics, and no anomalies. I surely don't know what the above mentioned assert is about; I haven't seen such a panic myself. -Brandon ___ 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: VirtualBox + VIMAGE
On Wed, Jan 26, 2011 at 8:25 AM, Mikolaj Golub to.my.troc...@gmail.com wrote:
[SNIP]
I suppose we should have an option in ports, something:
.if ${OSVERSION} 800500
OPTIONS+= VIMAGE Build for VIMAGE kernel off
.endif
and if it is on set VIMAGE make environment variable. Or may be you have
a better solution.
As of r217203 on 9-CURRENT and r217403 on 8-STABLE, VIMAGE is
announced as a feature via sysctl(8). Would it be possible to query
this value to decide how to build the module?
[SNIP]
-Brandon
___
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: Would there be interest in virtualization of the ixgbe driver?
On Tue, Jan 4, 2011 at 4:50 PM, Ryan Stone ryst...@gmail.com wrote: At $WORK I've implemented an extension of the ixgbe driver that provides multiple virtualized ixgbe interfaces. The implementation uses the 8259[89]'s virtualization features, so the rx and tx paths of the virtual interfaces are completely independent. From the perspective of everything above the ixgbe driver, it's as if there are multiple physical interfaces present. The use-case for the feature at $WORK is very specific to our architecture, but I can imagine that having hardware-based virtual interfaces could be useful with jails, vnet or when using FreeBSD as the host OS for something like VirtualBox. I'm really not very familiar with what people do or want to do with virtualization on FreeBSD, so I don't have any kind of idea as to whether this feature could be useful to the community. Currently the code is not in a state that could be submitted to jfv@ for consideration: I disabled certain features like RSS because I didn't need them in my implementation, and interfaces can only be created at boot(via tunable). Before I start working on cleaning it up, I want to know if people think that such a feature would be worthwhile or useful to them. The way that I envision this working is that you'd run something like ifconfig vix0 create parent ix1 to create a new virtual interface sharing the same physical interface as ix1. From that point on, vix0 would be a completely different interface from ix1, with its own MAC, vlan table, IPs, etc. It would be nice to split up the hardware for use with vnet jails. The virtualization technique you are describing -- it sounds similar to how network device virtualization is done in the Solaris Project Crossbow implementation. Can you comment on this? In other words, would we have the ability to have a vnet jail tied to specific hardware resources (Rx/Tx rings with their own DMA channels and interrupts, etc...). I'm sorry, I don't have a link to the Project Crossbow features to which I'm referring. -Brandon ___ 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: way for determine VIMAGE feature
On Sun, Jan 9, 2011 at 9:17 AM, Subbsd sub...@gmail.com wrote: Hi is there any mechanism to find out from userland is supports the current kernel VIMAGE or not? something like 'sysctl kern.features.vnet=1' ? Thanks I've not been able to determine this either, but as it requires kernel re-configuration, I usually just know. In my scripts, I make sure and fail if the call to create a vnet jail fails: sh -c 'TEST=$(sudo jail -c vnet name=test host.hostname=test path=/) ; if [ $? = 1 ]; then echo VIMAGE NOT AVAILABLE ; exit 1 ; fi' ...or something like that. There may be a better way, or perhaps there should be. -Brandon ___ 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: VIMAGE: Freed UMA keg was not empty
On Wed, Nov 17, 2010 at 7:17 AM, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On Wed, 17 Nov 2010, Marko Zec wrote: Actually, we never seriously discussed or revisited the issue with separate UMA pools for each vnet instance. My original motivation when O introduced separate UMA pools was primarily in making it easier to spot resource leaks, and to prove the correctness of the whole VIMAGE / VNET thing. Having more or less achieved those goals, perhaps the time has come to move on. Having said that, and given that the current VIMAGE resource allocation model is far from being optimal (a lot of memory sits reserved but 99% unused, and cannot be reclaimed later on vnet teardown), perhaps it's time that we reconsider using unified UMA pools. I think there is a misunderstanding here; it can be reclaimed by the time we have the teardown properly sorted out and it will immediately help normal non-VIMAGE systems under memory pressure as well. The problem is that, at least for TCP (and UDP in one special case as I found after lots of testing), we are no there yet. After that, when it comes to resource usage, I am still wondering how trasz' resource limits will plug into that. By the time we can see those coming together we should be able to decide whether to go left or right. I've been running into this memory exhaustion as well, having a need to stop and start my VIMAGE jails frequently. I'm confident that the proper solution will be worked out, but I wonder what sort of time-frame we may be looking at -- is VIMAGE expected to be production by 9.0-RELEASE? Also, does anyone know the current status of trasz's work (which I believe is to be completed December of this year)? I hope it's still on schedule :) -Brandon ___ 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: limitations on jail style virtualization
On Sat, Nov 13, 2010 at 2:59 PM, Julian Elischer jul...@freebsd.org wrote: We discussed this at MeetBSD last week and it woudl seem that the next big hurdle for virtualization would seem to be a good concept to allow jails to have virtual versions of various virtual devices.. for example pf has been virtualized (when IS that patch going to get committed?) but pfsync and pflog use special devices in /dev. similarly bpf uses /dev entries but the way they are used means they are still useful. so what happend when a device that is accessed from within a jail creates a cloning device? should it just turn up in the devfs for that jail? and should it be visible in other jails that happen to be sharing the same /dev? I have no preconceived ideas abot this. Just possibilities. should the cloning code work alongside a new devfs feature that would make 'per jail' entries? i.e. tun0 would be a different device depending on what jail you were in looking at the /dev? Was this brought up in any of the discussions? http://www.7he.at/freebsd/vps/ I'm not sure if the VPS project pertains directly to what you're talking about, but perhaps some of the code or ideas from the project might? Even if it doesn't, it's still an exciting project that adds a ton of value to FreeBSD's light-weight virtualization strategy. What do think about the VPS concept in relation to the current virtualization effort being put in to jails? It seems to me that recent efforts at virtualizing kernel-level objects makes VPS the future of FreeBSD's virtualization, leaving jails as a great way to isolate applications... -Brandon ___ 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
