From owner-freebsd-virtualization@FreeBSD.ORG Mon Jun 3 11:06:54 2013 Return-Path: Delivered-To: freebsd-virtualization@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4F88B602 for ; Mon, 3 Jun 2013 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 408D413C9 for ; Mon, 3 Jun 2013 11:06:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r53B6sDE015208 for ; Mon, 3 Jun 2013 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r53B6r4q015206 for freebsd-virtualization@FreeBSD.org; Mon, 3 Jun 2013 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Jun 2013 11:06:53 GMT Message-Id: <201306031106.r53B6r4q015206@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-virtualization@FreeBSD.org Subject: Current problem reports assigned to freebsd-virtualization@FreeBSD.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 11:06:54 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/170096 virtualization[vimage] Dynamically-attached network interface will c o kern/169991 virtualization[run] [vimage] panic after device plugged in o kern/165252 virtualization[vimage] [pf] [panic] kernel panics with VIMAGE and PF o kern/161094 virtualization[vimage] [pf] [panic] kernel panic with pf + VIMAGE wh o kern/160541 virtualization[vimage][pf][patch] panic: userret: Returning on td 0x o kern/160496 virtualization[vimage] [pf] [patch] kernel panic with pf + VIMAGE o kern/148155 virtualization[vimage] [pf] Kernel panic with PF + VIMAGE kernel opt a kern/147950 virtualization[vimage] [carp] VIMAGE + CARP = kernel crash s kern/143808 virtualization[pf] pf does not work inside jail a kern/141696 virtualization[rum] [vimage] [panic] rum(4)+ vimage = kernel panic 10 problems total. From owner-freebsd-virtualization@FreeBSD.ORG Mon Jun 3 11:58:46 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3E003C5A; Mon, 3 Jun 2013 11:58:46 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by mx1.freebsd.org (Postfix) with ESMTP id B9E771914; Mon, 3 Jun 2013 11:58:45 +0000 (UTC) Received: from [192.168.44.85] ([217.115.146.100]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LyVcA-1UMu8v0b1a-015qGr; Mon, 03 Jun 2013 13:58:39 +0200 Message-ID: <51AC84EE.6020009@gmx.com> Date: Mon, 03 Jun 2013 13:58:38 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "freebsd-pf@freebsd.org" , freebsd-virtualization@freebsd.org Subject: pf + vimage patch Content-Type: multipart/mixed; boundary="------------020601030809060207010704" X-Provags-ID: V03:K0:PhTuxnXAoOCGPr7+w0Z7PuTn7Di6qw8RkjxEUG/7G5y/bX7Tzas P0cSTnXl1i71RD8baKQ+ANJOXhTjY3jP4uXdkL01Nc8N6Nkr3ftQ+rcbb7qjneFXQWvzdT5 /X6XcNWEbNJlkrsGfXwtV1wYebS87s7R4pRvyJNHl3FBLJj3XNgcCI00NGAOooDhDacuTvc OIgrOd70iLNDhhnKy9nBg== X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 11:58:46 -0000 This is a multi-part message in MIME format. --------------020601030809060207010704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Please review this patch. It fixes some problems with pf and vimage. For the time being only pf works. ALTQ, pflog, pfsync are not changed nor tested but as time permits, I'll work on them. Basic packet filtering functionality per VNET should be ok. Thanks in advance for reviewing, Nikos --------------020601030809060207010704 Content-Type: text/x-patch; name="pf.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pf.diff" Index: sys/net/pfvar.h =================================================================== --- sys/net/pfvar.h (revision 251294) +++ sys/net/pfvar.h (working copy) @@ -901,7 +901,6 @@ struct pf_ruleset *, struct pf_pdesc *, int); extern pflog_packet_t *pflog_packet_ptr; -#define V_pf_end_threads VNET(pf_end_threads) #endif /* _KERNEL */ #define PFSYNC_FLAG_SRCNODE 0x04 Index: sys/netpfil/pf/pf.c =================================================================== --- sys/netpfil/pf/pf.c (revision 251294) +++ sys/netpfil/pf/pf.c (working copy) @@ -300,8 +300,6 @@ int in4_cksum(struct mbuf *m, u_int8_t nxt, int off, int len); -VNET_DECLARE(int, pf_end_threads); - VNET_DEFINE(struct pf_limit, pf_limits[PF_LIMIT_MAX]); #define PACKET_LOOPED(pd) ((pd)->pf_mtag && \ @@ -359,15 +357,13 @@ SYSCTL_NODE(_net, OID_AUTO, pf, CTLFLAG_RW, 0, "pf(4)"); -VNET_DEFINE(u_long, pf_hashsize); -#define V_pf_hashsize VNET(pf_hashsize) -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, - &VNET_NAME(pf_hashsize), 0, "Size of pf(4) states hashtable"); +u_long pf_hashsize; +SYSCTL_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, + &pf_hashsize, 0, "Size of pf(4) states hashtable"); -VNET_DEFINE(u_long, pf_srchashsize); -#define V_pf_srchashsize VNET(pf_srchashsize) -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable"); +u_long pf_srchashsize; +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); VNET_DEFINE(void *, pf_swi_cookie); @@ -698,12 +694,12 @@ struct pf_srchash *sh; u_int i; - TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &V_pf_hashsize); - if (V_pf_hashsize == 0 || !powerof2(V_pf_hashsize)) - V_pf_hashsize = PF_HASHSIZ; - TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &V_pf_srchashsize); - if (V_pf_srchashsize == 0 || !powerof2(V_pf_srchashsize)) - V_pf_srchashsize = PF_HASHSIZ / 4; + TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &pf_hashsize); + if (pf_hashsize == 0 || !powerof2(pf_hashsize)) + pf_hashsize = PF_HASHSIZ; + TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &pf_srchashsize); + if (pf_srchashsize == 0 || !powerof2(pf_srchashsize)) + pf_srchashsize = PF_HASHSIZ / 4; V_pf_hashseed = arc4random(); @@ -717,11 +713,11 @@ V_pf_state_key_z = uma_zcreate("pf state keys", sizeof(struct pf_state_key), pf_state_key_ctor, NULL, NULL, NULL, UMA_ALIGN_PTR, 0); - V_pf_keyhash = malloc(V_pf_hashsize * sizeof(struct pf_keyhash), + V_pf_keyhash = malloc(pf_hashsize * sizeof(struct pf_keyhash), M_PFHASH, M_WAITOK | M_ZERO); - V_pf_idhash = malloc(V_pf_hashsize * sizeof(struct pf_idhash), + V_pf_idhash = malloc(pf_hashsize * sizeof(struct pf_idhash), M_PFHASH, M_WAITOK | M_ZERO); - V_pf_hashmask = V_pf_hashsize - 1; + V_pf_hashmask = pf_hashsize - 1; for (i = 0, kh = V_pf_keyhash, ih = V_pf_idhash; i <= V_pf_hashmask; i++, kh++, ih++) { mtx_init(&kh->lock, "pf_keyhash", NULL, MTX_DEF); @@ -735,9 +731,9 @@ V_pf_limits[PF_LIMIT_SRC_NODES].zone = V_pf_sources_z; uma_zone_set_max(V_pf_sources_z, PFSNODE_HIWAT); uma_zone_set_warning(V_pf_sources_z, "PF source nodes limit reached"); - V_pf_srchash = malloc(V_pf_srchashsize * sizeof(struct pf_srchash), + V_pf_srchash = malloc(pf_srchashsize * sizeof(struct pf_srchash), M_PFHASH, M_WAITOK|M_ZERO); - V_pf_srchashmask = V_pf_srchashsize - 1; + V_pf_srchashmask = pf_srchashsize - 1; for (i = 0, sh = V_pf_srchash; i <= V_pf_srchashmask; i++, sh++) mtx_init(&sh->lock, "pf_srchash", NULL, MTX_DEF); @@ -757,13 +753,17 @@ STAILQ_INIT(&V_pf_sendqueue); SLIST_INIT(&V_pf_overloadqueue); TASK_INIT(&V_pf_overloadtask, 0, pf_overload_task, &V_pf_overloadqueue); - mtx_init(&pf_sendqueue_mtx, "pf send queue", NULL, MTX_DEF); - mtx_init(&pf_overloadqueue_mtx, "pf overload/flush queue", NULL, - MTX_DEF); + if (IS_DEFAULT_VNET(curvnet)) { + mtx_init(&pf_sendqueue_mtx, "pf send queue", NULL, MTX_DEF); + mtx_init(&pf_overloadqueue_mtx, "pf overload/flush queue", NULL, + MTX_DEF); + } /* Unlinked, but may be referenced rules. */ TAILQ_INIT(&V_pf_unlinked_rules); - mtx_init(&pf_unlnkdrules_mtx, "pf unlinked rules", NULL, MTX_DEF); + if (IS_DEFAULT_VNET(curvnet)) + mtx_init(&pf_unlnkdrules_mtx, "pf unlinked rules", NULL, MTX_DEF); + } void @@ -1309,68 +1309,35 @@ pf_purge_thread(void *v) { u_int idx = 0; + VNET_ITERATOR_DECL(vnet_iter); - CURVNET_SET((struct vnet *)v); - for (;;) { - PF_RULES_RLOCK(); - rw_sleep(pf_purge_thread, &pf_rules_lock, 0, "pftm", hz / 10); + tsleep(pf_purge_thread, PWAIT, "pftm", hz / 10); + VNET_LIST_RLOCK(); + VNET_FOREACH(vnet_iter) { + CURVNET_SET(vnet_iter); - if (V_pf_end_threads) { - /* - * To cleanse up all kifs and rules we need - * two runs: first one clears reference flags, - * then pf_purge_expired_states() doesn't - * raise them, and then second run frees. - */ - PF_RULES_RUNLOCK(); - pf_purge_unlinked_rules(); - pfi_kif_purge(); - - /* - * Now purge everything. - */ - pf_purge_expired_states(0, V_pf_hashmask); - pf_purge_expired_fragments(); - pf_purge_expired_src_nodes(); - - /* - * Now all kifs & rules should be unreferenced, - * thus should be successfully freed. - */ - pf_purge_unlinked_rules(); - pfi_kif_purge(); - - /* - * Announce success and exit. - */ - PF_RULES_RLOCK(); - V_pf_end_threads++; - PF_RULES_RUNLOCK(); - wakeup(pf_purge_thread); - kproc_exit(0); - } - PF_RULES_RUNLOCK(); - /* Process 1/interval fraction of the state table every run. */ idx = pf_purge_expired_states(idx, V_pf_hashmask / - (V_pf_default_rule.timeout[PFTM_INTERVAL] * 10)); + (V_pf_default_rule.timeout[PFTM_INTERVAL] * 10)); /* Purge other expired types every PFTM_INTERVAL seconds. */ if (idx == 0) { - /* - * Order is important: - * - states and src nodes reference rules - * - states and rules reference kifs - */ - pf_purge_expired_fragments(); - pf_purge_expired_src_nodes(); - pf_purge_unlinked_rules(); - pfi_kif_purge(); + /* + * Order is important: + * - states and src nodes reference rules + * - states and rules reference kifs + */ + pf_purge_expired_fragments(); + pf_purge_expired_src_nodes(); + pf_purge_unlinked_rules(); + pfi_kif_purge(); } + CURVNET_RESTORE(); + } + VNET_LIST_RUNLOCK(); } /* not reached */ - CURVNET_RESTORE(); } u_int32_t Index: sys/netpfil/pf/pf_if.c =================================================================== --- sys/netpfil/pf/pf_if.c (revision 251294) +++ sys/netpfil/pf/pf_if.c (working copy) @@ -110,7 +110,8 @@ V_pfi_buffer = malloc(V_pfi_buffer_max * sizeof(*V_pfi_buffer), PFI_MTYPE, M_WAITOK); - mtx_init(&pfi_unlnkdkifs_mtx, "pf unlinked interfaces", NULL, MTX_DEF); + if (IS_DEFAULT_VNET(curvnet)) + mtx_init(&pfi_unlnkdkifs_mtx, "pf unlinked interfaces", NULL, MTX_DEF); kif = malloc(sizeof(*kif), PFI_MTYPE, M_WAITOK); PF_RULES_WLOCK(); @@ -124,18 +125,20 @@ pfi_attach_ifnet(ifp); IFNET_RUNLOCK(); - pfi_attach_cookie = EVENTHANDLER_REGISTER(ifnet_arrival_event, - pfi_attach_ifnet_event, NULL, EVENTHANDLER_PRI_ANY); - pfi_detach_cookie = EVENTHANDLER_REGISTER(ifnet_departure_event, - pfi_detach_ifnet_event, NULL, EVENTHANDLER_PRI_ANY); - pfi_attach_group_cookie = EVENTHANDLER_REGISTER(group_attach_event, - pfi_attach_group_event, curvnet, EVENTHANDLER_PRI_ANY); - pfi_change_group_cookie = EVENTHANDLER_REGISTER(group_change_event, - pfi_change_group_event, curvnet, EVENTHANDLER_PRI_ANY); - pfi_detach_group_cookie = EVENTHANDLER_REGISTER(group_detach_event, - pfi_detach_group_event, curvnet, EVENTHANDLER_PRI_ANY); - pfi_ifaddr_event_cookie = EVENTHANDLER_REGISTER(ifaddr_event, - pfi_ifaddr_event, NULL, EVENTHANDLER_PRI_ANY); + if (IS_DEFAULT_VNET(curvnet)) { + pfi_attach_cookie = EVENTHANDLER_REGISTER(ifnet_arrival_event, + pfi_attach_ifnet_event, NULL, EVENTHANDLER_PRI_ANY); + pfi_detach_cookie = EVENTHANDLER_REGISTER(ifnet_departure_event, + pfi_detach_ifnet_event, NULL, EVENTHANDLER_PRI_ANY); + pfi_attach_group_cookie = EVENTHANDLER_REGISTER(group_attach_event, + pfi_attach_group_event, curvnet, EVENTHANDLER_PRI_ANY); + pfi_change_group_cookie = EVENTHANDLER_REGISTER(group_change_event, + pfi_change_group_event, curvnet, EVENTHANDLER_PRI_ANY); + pfi_detach_group_cookie = EVENTHANDLER_REGISTER(group_detach_event, + pfi_detach_group_event, curvnet, EVENTHANDLER_PRI_ANY); + pfi_ifaddr_event_cookie = EVENTHANDLER_REGISTER(ifaddr_event, + pfi_ifaddr_event, NULL, EVENTHANDLER_PRI_ANY); + } } void Index: sys/netpfil/pf/pf_ioctl.c =================================================================== --- sys/netpfil/pf/pf_ioctl.c (revision 251294) +++ sys/netpfil/pf/pf_ioctl.c (working copy) @@ -183,7 +183,6 @@ static volatile VNET_DEFINE(int, pf_pfil_hooked); #define V_pf_pfil_hooked VNET(pf_pfil_hooked) -VNET_DEFINE(int, pf_end_threads); struct rwlock pf_rules_lock; @@ -254,10 +253,13 @@ /* XXX do our best to avoid a conflict */ V_pf_status.hostid = arc4random(); - if ((error = kproc_create(pf_purge_thread, curvnet, NULL, 0, 0, - "pf purge")) != 0) - /* XXXGL: leaked all above. */ - return (error); + if (IS_DEFAULT_VNET(curvnet)) { + if ((error = kproc_create(pf_purge_thread, curvnet, NULL, 0, 0, + "pf purge")) != 0) { + /* XXXGL: leaked all above. */ + return (error); + } + } if ((error = swi_add(NULL, "pf send", pf_intr, curvnet, SWI_NET, INTR_MPSAFE, &V_pf_swi_cookie)) != 0) /* XXXGL: leaked all above. */ @@ -3631,24 +3633,22 @@ static int pf_load(void) { - int error; - VNET_ITERATOR_DECL(vnet_iter); + rw_init(&pf_rules_lock, "pf rulesets"); + pf_dev = make_dev(&pf_cdevsw, 0, 0, 0, 0600, PF_NAME); - VNET_LIST_RLOCK(); - VNET_FOREACH(vnet_iter) { - CURVNET_SET(vnet_iter); - V_pf_pfil_hooked = 0; - V_pf_end_threads = 0; - TAILQ_INIT(&V_pf_tags); - TAILQ_INIT(&V_pf_qids); - CURVNET_RESTORE(); - } - VNET_LIST_RUNLOCK(); + return (0); +} - rw_init(&pf_rules_lock, "pf rulesets"); +static int +vnet_pf_init(void) +{ + int error; - pf_dev = make_dev(&pf_cdevsw, 0, 0, 0, 0600, PF_NAME); + V_pf_pfil_hooked = 0; + TAILQ_INIT(&V_pf_tags); + TAILQ_INIT(&V_pf_qids); + if ((error = pfattach()) != 0) return (error); @@ -3676,11 +3676,6 @@ } PF_RULES_WLOCK(); shutdown_pf(); - V_pf_end_threads = 1; - while (V_pf_end_threads < 2) { - wakeup_one(pf_purge_thread); - rw_sleep(pf_purge_thread, &pf_rules_lock, 0, "pftmo", 0); - } pf_normalize_cleanup(); pfi_cleanup(); pfr_cleanup(); @@ -3727,3 +3722,6 @@ DECLARE_MODULE(pf, pf_mod, SI_SUB_PSEUDO, SI_ORDER_FIRST); MODULE_VERSION(pf, PF_MODVER); + +VNET_SYSINIT(vnet_pf_init, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_ANY - 255, + vnet_pf_init, NULL); Index: sys/netpfil/pf/pf_norm.c =================================================================== --- sys/netpfil/pf/pf_norm.c (revision 251294) +++ sys/netpfil/pf/pf_norm.c (working copy) @@ -163,7 +163,8 @@ uma_zone_set_max(V_pf_frent_z, PFFRAG_FRENT_HIWAT); uma_zone_set_warning(V_pf_frent_z, "PF frag entries limit reached"); - mtx_init(&pf_frag_mtx, "pf fragments", NULL, MTX_DEF); + if (IS_DEFAULT_VNET(curvnet)) + mtx_init(&pf_frag_mtx, "pf fragments", NULL, MTX_DEF); TAILQ_INIT(&V_pf_fragqueue); TAILQ_INIT(&V_pf_cachequeue); Index: sys/netpfil/pf/pf_table.c =================================================================== --- sys/netpfil/pf/pf_table.c (revision 251294) +++ sys/netpfil/pf/pf_table.c (working copy) @@ -183,10 +183,14 @@ static RB_PROTOTYPE(pfr_ktablehead, pfr_ktable, pfrkt_tree, pfr_ktable_compare); static RB_GENERATE(pfr_ktablehead, pfr_ktable, pfrkt_tree, pfr_ktable_compare); -struct pfr_ktablehead pfr_ktables; +VNET_DEFINE(struct pfr_ktablehead, pfr_ktables); +#define V_pfr_ktables VNET(pfr_ktables) + struct pfr_table pfr_nulltable; -int pfr_ktable_cnt; +VNET_DEFINE(int, pfr_ktable_cnt); +#define V_pfr_ktable_cnt VNET(pfr_ktable_cnt) + void pfr_initialize(void) { @@ -1082,7 +1086,7 @@ return (ENOENT); SLIST_INIT(&workq); - RB_FOREACH(p, pfr_ktablehead, &pfr_ktables) { + RB_FOREACH(p, pfr_ktablehead, &V_pfr_ktables) { if (pfr_skip_table(filter, p, flags)) continue; if (!strcmp(p->pfrkt_anchor, PF_RESERVED_ANCHOR)) @@ -1117,7 +1121,7 @@ flags & PFR_FLAG_USERIOCTL)) senderr(EINVAL); key.pfrkt_flags |= PFR_TFLAG_ACTIVE; - p = RB_FIND(pfr_ktablehead, &pfr_ktables, &key); + p = RB_FIND(pfr_ktablehead, &V_pfr_ktables, &key); if (p == NULL) { p = pfr_create_ktable(&key.pfrkt_t, tzero, 1); if (p == NULL) @@ -1133,7 +1137,7 @@ /* find or create root table */ bzero(key.pfrkt_anchor, sizeof(key.pfrkt_anchor)); - r = RB_FIND(pfr_ktablehead, &pfr_ktables, &key); + r = RB_FIND(pfr_ktablehead, &V_pfr_ktables, &key); if (r != NULL) { p->pfrkt_root = r; goto _skip; @@ -1189,7 +1193,7 @@ if (pfr_validate_table(&key.pfrkt_t, 0, flags & PFR_FLAG_USERIOCTL)) return (EINVAL); - p = RB_FIND(pfr_ktablehead, &pfr_ktables, &key); + p = RB_FIND(pfr_ktablehead, &V_pfr_ktables, &key); if (p != NULL && (p->pfrkt_flags & PFR_TFLAG_ACTIVE)) { SLIST_FOREACH(q, &workq, pfrkt_workq) if (!pfr_ktable_compare(p, q)) @@ -1228,7 +1232,7 @@ *size = n; return (0); } - RB_FOREACH(p, pfr_ktablehead, &pfr_ktables) { + RB_FOREACH(p, pfr_ktablehead, &V_pfr_ktables) { if (pfr_skip_table(filter, p, flags)) continue; if (n-- <= 0) @@ -1263,7 +1267,7 @@ return (0); } SLIST_INIT(&workq); - RB_FOREACH(p, pfr_ktablehead, &pfr_ktables) { + RB_FOREACH(p, pfr_ktablehead, &V_pfr_ktables) { if (pfr_skip_table(filter, p, flags)) continue; if (n-- <= 0) @@ -1295,7 +1299,7 @@ bcopy(tbl + i, &key.pfrkt_t, sizeof(key.pfrkt_t)); if (pfr_validate_table(&key.pfrkt_t, 0, 0)) return (EINVAL); - p = RB_FIND(pfr_ktablehead, &pfr_ktables, &key); + p = RB_FIND(pfr_ktablehead, &V_pfr_ktables, &key); if (p != NULL) { SLIST_INSERT_HEAD(&workq, p, pfrkt_workq); xzero++; @@ -1327,7 +1331,7 @@ if (pfr_validate_table(&key.pfrkt_t, 0, flags & PFR_FLAG_USERIOCTL)) return (EINVAL); - p = RB_FIND(pfr_ktablehead, &pfr_ktables, &key); + p = RB_FIND(pfr_ktablehead, &V_pfr_ktables, &key); if (p != NULL && (p->pfrkt_flags & PFR_TFLAG_ACTIVE)) { p->pfrkt_nflags = (p->pfrkt_flags | setflag) & ~clrflag; @@ -1369,7 +1373,7 @@ if (rs == NULL) return (ENOMEM); SLIST_INIT(&workq); - RB_FOREACH(p, pfr_ktablehead, &pfr_ktables) { + RB_FOREACH(p, pfr_ktablehead, &V_pfr_ktables) { if (!(p->pfrkt_flags & PFR_TFLAG_INACTIVE) || pfr_skip_table(trs, p, 0)) continue; @@ -1414,7 +1418,7 @@ return (EBUSY); tbl->pfrt_flags |= PFR_TFLAG_INACTIVE; SLIST_INIT(&tableq); - kt = RB_FIND(pfr_ktablehead, &pfr_ktables, (struct pfr_ktable *)tbl); + kt = RB_FIND(pfr_ktablehead, &V_pfr_ktables, (struct pfr_ktable *)tbl); if (kt == NULL) { kt = pfr_create_ktable(tbl, 0, 1); if (kt == NULL) @@ -1427,7 +1431,7 @@ /* find or create root table */ bzero(&key, sizeof(key)); strlcpy(key.pfrkt_name, tbl->pfrt_name, sizeof(key.pfrkt_name)); - rt = RB_FIND(pfr_ktablehead, &pfr_ktables, &key); + rt = RB_FIND(pfr_ktablehead, &V_pfr_ktables, &key); if (rt != NULL) { kt->pfrkt_root = rt; goto _skip; @@ -1504,7 +1508,7 @@ if (rs == NULL || !rs->topen || ticket != rs->tticket) return (0); SLIST_INIT(&workq); - RB_FOREACH(p, pfr_ktablehead, &pfr_ktables) { + RB_FOREACH(p, pfr_ktablehead, &V_pfr_ktables) { if (!(p->pfrkt_flags & PFR_TFLAG_INACTIVE) || pfr_skip_table(trs, p, 0)) continue; @@ -1540,7 +1544,7 @@ return (EBUSY); SLIST_INIT(&workq); - RB_FOREACH(p, pfr_ktablehead, &pfr_ktables) { + RB_FOREACH(p, pfr_ktablehead, &V_pfr_ktables) { if (!(p->pfrkt_flags & PFR_TFLAG_INACTIVE) || pfr_skip_table(trs, p, 0)) continue; @@ -1686,7 +1690,7 @@ PF_RULES_ASSERT(); if (flags & PFR_FLAG_ALLRSETS) - return (pfr_ktable_cnt); + return (V_pfr_ktable_cnt); if (filter->pfrt_anchor[0]) { rs = pf_find_ruleset(filter->pfrt_anchor); return ((rs != NULL) ? rs->tables : -1); @@ -1719,8 +1723,8 @@ PF_RULES_WASSERT(); - RB_INSERT(pfr_ktablehead, &pfr_ktables, kt); - pfr_ktable_cnt++; + RB_INSERT(pfr_ktablehead, &V_pfr_ktables, kt); + V_pfr_ktable_cnt++; if (kt->pfrkt_root != NULL) if (!kt->pfrkt_root->pfrkt_refcnt[PFR_REFCNT_ANCHOR]++) pfr_setflags_ktable(kt->pfrkt_root, @@ -1751,14 +1755,14 @@ if (!(newf & PFR_TFLAG_ACTIVE)) newf &= ~PFR_TFLAG_USRMASK; if (!(newf & PFR_TFLAG_SETMASK)) { - RB_REMOVE(pfr_ktablehead, &pfr_ktables, kt); + RB_REMOVE(pfr_ktablehead, &V_pfr_ktables, kt); if (kt->pfrkt_root != NULL) if (!--kt->pfrkt_root->pfrkt_refcnt[PFR_REFCNT_ANCHOR]) pfr_setflags_ktable(kt->pfrkt_root, kt->pfrkt_root->pfrkt_flags & ~PFR_TFLAG_REFDANCHOR); pfr_destroy_ktable(kt, 1); - pfr_ktable_cnt--; + V_pfr_ktable_cnt--; return; } if (!(newf & PFR_TFLAG_ACTIVE) && kt->pfrkt_cnt) { @@ -1883,7 +1887,7 @@ pfr_lookup_table(struct pfr_table *tbl) { /* struct pfr_ktable start like a struct pfr_table */ - return (RB_FIND(pfr_ktablehead, &pfr_ktables, + return (RB_FIND(pfr_ktablehead, &V_pfr_ktables, (struct pfr_ktable *)tbl)); } --------------020601030809060207010704-- From owner-freebsd-virtualization@FreeBSD.ORG Tue Jun 4 15:31:27 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 830E0193; Tue, 4 Jun 2013 15:31:27 +0000 (UTC) (envelope-from larrymelia@gmail.com) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8DD18F6; Tue, 4 Jun 2013 15:31:27 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id um15so406747pbc.10 for ; Tue, 04 Jun 2013 08:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=wD/zunvXGeAH8GfOhlIYBpMoU3Q4cyXJFnMX69+JwtQ=; b=BkAtX694t1t/t/1fulN4LoWWGAm0vxkMRKpnVxrPAZzmarhylz38mpaN7hHB612yW/ HY9GYqTDxsU7ySqH11UAD6HZYlrKe2ZWReIxIS4X+vkUbRz1hnHi6TRWHS5uvMLWfp6n NyDDjaz76LqK1YgMiX1054FMly1RmHotYxevs8tzEBdw60svQgAuPjR9ua7rEFLyvLfr Z1r9aw8XU5AEIZm0Z3Hvz6Un/CmjTVorzBGm5tU+xNhJIYZ4hURcD/wglm68YBNCXVar rRrAy1CfHQFLpnbBZ2iY0tCiTpOOVdv7K8T5zngFADNyWPuCv2ywCpCt1g9to58798Lo aVnA== X-Received: by 10.66.193.199 with SMTP id hq7mr28098105pac.183.1370359887146; Tue, 04 Jun 2013 08:31:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.3.162 with HTTP; Tue, 4 Jun 2013 08:30:47 -0700 (PDT) From: Larry Melia Date: Tue, 4 Jun 2013 08:30:47 -0700 Message-ID: Subject: more granular detection and control to disable/enable PCI-ATA devices To: freebsd-virtualization@freebsd.org, Alexander Motin , KY Srinivasan , "Abhishek Gupta (LIS)" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 15:31:27 -0000 Hi Alexander- With you suggestions, I finally was able to get the override driver working-see https://github.com/FreeBSDonHyper-V/freebsd-snapshot/blob/hyperv-dev-ata-override/sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.c. While it operates wonderfully, allowing our "enlightened" driver to improve performance, some versions of Hyper-V still use the native CD-ROM driver, because there is no "enlightened" support for it in the hypervisor. From my limited knowledge of the ATA drivers, it seems likely that the PCI-ATA driver be attached when a CD-ROM is detected, but lower-level drivers disabled (during a probe) when a hard drive is detected. On Hyper-V, therefore, a user would be able to configure a PCI/IDE virtual controller with two devices, the first device a hard disk and the second one a CD-ROM. The CD-ROM would operate via the native driver, whereas the hard disk would use the "enlightened" driver (to improve performance). Is there an easy way to add more granular detection, disabling the native ATA driver(s) selectively for hard drives, while allowing CD-ROM devices to be natively attached? Any suggestions would be very much appreciated. -Larry From owner-freebsd-virtualization@FreeBSD.ORG Tue Jun 4 16:23:25 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 938804BD for ; Tue, 4 Jun 2013 16:23:25 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id 260E01C70 for ; Tue, 4 Jun 2013 16:23:24 +0000 (UTC) Received: by mail-bk0-f48.google.com with SMTP id jf17so288823bkc.7 for ; Tue, 04 Jun 2013 09:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=i7wUhgYCQpqMHmsNnJaK7eLZnnsbFaqplQe2ZN49+LY=; b=f4MbNsDglKyM+Vgn4J6N9sCefuN1K9sBs/V3KmOwSft68CYV1Suqtu80zcyrHZpfpa /uSlW9MgffCoFZ2gau0S6CwLnz9Zt2RYRWpdcSJWbt9bEqDMketVTKKtbkaKHxcZjVsD ktSGODk9g4eec3nPc7id56C62RgtXA9hBis2u/egFCyaJms/DOu95zPKgP4NwcyrnCPX fOLJNY3bo542l7w0U+xNpZDopPmmNRpuMnuWgAJJxpMNgISF7AfRUmgsqtt17BGwrCaJ JGeHBcMH6dB5G+AUgr0vvfpXp+PD2srmkEavHXdafEv62ZK8YkpjI4jfOA2W7IWv6ytY 2aFA== X-Received: by 10.204.187.9 with SMTP id cu9mr8446831bkb.104.1370363004198; Tue, 04 Jun 2013 09:23:24 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPSA id iy11sm23591341bkb.11.2013.06.04.09.23.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 09:23:23 -0700 (PDT) Sender: Alexander Motin Message-ID: <51AE1478.2000409@FreeBSD.org> Date: Tue, 04 Jun 2013 19:23:20 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130413 Thunderbird/17.0.5 MIME-Version: 1.0 To: Larry Melia Subject: Re: more granular detection and control to disable/enable PCI-ATA devices References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Abhishek Gupta \(LIS\)" , KY Srinivasan , freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 16:23:25 -0000 Hi. On 04.06.2013 18:30, Larry Melia wrote: > With you suggestions, I finally was able to get the override driver > working-see > https://github.com/FreeBSDonHyper-V/freebsd-snapshot/blob/hyperv-dev-ata-override/sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.c. > While it operates wonderfully, allowing our "enlightened" driver to > improve performance, some versions of Hyper-V still use the native > CD-ROM driver, because there is no "enlightened" support for it in the > hypervisor. From my limited knowledge of the ATA drivers, it seems > likely that the PCI-ATA driver be attached when a CD-ROM is detected, > but lower-level drivers disabled (during a probe) when a hard drive is > detected. On Hyper-V, therefore, a user would be able to configure a > PCI/IDE virtual controller with two devices, the first device a hard > disk and the second one a CD-ROM. The CD-ROM would operate via the > native driver, whereas the hard disk would use the "enlightened" driver > (to improve performance). Is there an easy way to add more granular > detection, disabling the native ATA driver(s) selectively for hard > drives, while allowing CD-ROM devices to be natively attached? Any > suggestions would be very much appreciated. Unfortunately, CAM subsystem used for both ATA and SCSI stacks in FreeBSD 9.x and above is mostly unaware of "NewBus" infrastructure used for driver probe and attachment. That is why you can't replace driver for a single disk in the same way as you replaced driver for the whole controller. The highest level present in "NewBus" is ATA channel. So if disk and CD-ROM are always live on different channels, you can create dummy driver not for the whole controller (atapciX), but for single hardcoded ATA channel (ataX). Another possible way is to make controller driver not dummy, making it mostly duplicating default one, but filtering out unwanted devices. That may look like overkill, but it is not necessary so, because ATA stack is quite modularized, and you probably don't need to implement all ATA functionality such as mode setting, etc. Only thing that should be different in your driver is a reset method -- never reporting ATA disks to upper layers, only ATAPI devices. You may find number of drivers for example in sys/dev/ata/chipsets. The later way is definitely more complicated then just a few lines hack blocking CAM ada driver (ATA disk driver), but it still can be made modular and non-invasive. -- Alexander Motin From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 5 08:52:27 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2F7C3C15; Wed, 5 Jun 2013 08:52:27 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 3774D1C64; Wed, 5 Jun 2013 08:52:26 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id it19so693182bkc.13 for ; Wed, 05 Jun 2013 01:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=RhwcelCQpqAxDJ72aASwgKzRrHLb5Sq5Q1IaIK54REo=; b=muEOfzhTxJbfoJ3AGV4M0fafYBKSTDhyhUvVnL/Hn8wkkL2SpUTZRfBv3+5rvjjXSQ 4SLZK6QAUWZuXQMI+vU7nodCU+cQogf0NSwyIL/6tqth8acRNI0mklaoFE3n7O67CC/e j/E+qzH6ET/9GJbFrURL2dQJNWrn7kEFdXZPwQfQhzv/YBZRbGDp4iBiTrL+Nsyy5VNz 7bvj+Y3f91NJ5HZeO3u7AtOeG0Cpta9xW+SCLEVpACJC3ZA3kYsg7GmUgbz3EJgRV9N7 iIxd2iiFDBJloS7HtD46Cz4XUCbFvqFFmt+RbT16twSIUYZ2bFpkaMAC2ChAhHVEfd0p 0aSA== X-Received: by 10.204.62.137 with SMTP id x9mr9224354bkh.90.1370422344859; Wed, 05 Jun 2013 01:52:24 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id jm15sm25045160bkb.13.2013.06.05.01.52.22 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 05 Jun 2013 01:52:23 -0700 (PDT) Sender: Mikolaj Golub Date: Wed, 5 Jun 2013 11:52:20 +0300 From: Mikolaj Golub To: Nikos Vassiliadis Subject: Re: pf + vimage patch Message-ID: <20130605085219.GA53217@gmail.com> References: <51AC84EE.6020009@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51AC84EE.6020009@gmx.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-jail@freebsd.org, Gleb Smirnoff , freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 08:52:27 -0000 Hi, On Mon, Jun 03, 2013 at 01:58:38PM +0200, Nikos Vassiliadis wrote: > Hi, > > Please review this patch. It fixes some problems with pf and vimage. > For the time being only pf works. ALTQ, pflog, pfsync are not changed > nor tested but as time permits, I'll work on them. Basic packet > filtering functionality per VNET should be ok. > Thank you for working on this. I'd really like to see pf and vimage integrated, as it looks like one of the main stoppers to have vimage in GENERIC. I hoped more knowledgeable people would comment on this though. Anyway, not being familiar with pf, here is a couple of things I would recommend to make your patch more attractive for potential reviewers: 1) It looks like the patch can be split on several parts. A log message to every change describing why it is needed and what problem solves would be very helpful. As a tool to maintain such changes I personally prefer git. 2) You use spaces for indentation, where tabs should be. This adds unnecessary noise and makes the patch less readable. Also someone will need to fix this when eventually committing to the tree. 3) When generating diff from svn, adding -x-pu options will make the diff more readable. Also see some questions/comments below. > Index: sys/net/pfvar.h > =================================================================== > --- sys/net/pfvar.h (revision 251294) > +++ sys/net/pfvar.h (working copy) > @@ -901,7 +901,6 @@ > struct pf_ruleset *, struct pf_pdesc *, int); > extern pflog_packet_t *pflog_packet_ptr; > > -#define V_pf_end_threads VNET(pf_end_threads) > #endif /* _KERNEL */ > > #define PFSYNC_FLAG_SRCNODE 0x04 > Index: sys/netpfil/pf/pf.c > =================================================================== > --- sys/netpfil/pf/pf.c (revision 251294) > +++ sys/netpfil/pf/pf.c (working copy) > @@ -300,8 +300,6 @@ > > int in4_cksum(struct mbuf *m, u_int8_t nxt, int off, int len); > > -VNET_DECLARE(int, pf_end_threads); > - > VNET_DEFINE(struct pf_limit, pf_limits[PF_LIMIT_MAX]); > > #define PACKET_LOOPED(pd) ((pd)->pf_mtag && \ > @@ -359,15 +357,13 @@ > > SYSCTL_NODE(_net, OID_AUTO, pf, CTLFLAG_RW, 0, "pf(4)"); > > -VNET_DEFINE(u_long, pf_hashsize); > -#define V_pf_hashsize VNET(pf_hashsize) > -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, > - &VNET_NAME(pf_hashsize), 0, "Size of pf(4) states hashtable"); > +u_long pf_hashsize; > +SYSCTL_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, > + &pf_hashsize, 0, "Size of pf(4) states hashtable"); > > -VNET_DEFINE(u_long, pf_srchashsize); > -#define V_pf_srchashsize VNET(pf_srchashsize) > -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, > - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable"); > +u_long pf_srchashsize; > +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, > + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); > Why do you have to devirtualize these variables? Are per vnet hashtables sizes not useful or do they cause issues? > VNET_DEFINE(void *, pf_swi_cookie); > > @@ -698,12 +694,12 @@ > struct pf_srchash *sh; > u_int i; > > - TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &V_pf_hashsize); > - if (V_pf_hashsize == 0 || !powerof2(V_pf_hashsize)) > - V_pf_hashsize = PF_HASHSIZ; > - TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &V_pf_srchashsize); > - if (V_pf_srchashsize == 0 || !powerof2(V_pf_srchashsize)) > - V_pf_srchashsize = PF_HASHSIZ / 4; > + TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &pf_hashsize); > + if (pf_hashsize == 0 || !powerof2(pf_hashsize)) > + pf_hashsize = PF_HASHSIZ; > + TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &pf_srchashsize); > + if (pf_srchashsize == 0 || !powerof2(pf_srchashsize)) > + pf_srchashsize = PF_HASHSIZ / 4; > > V_pf_hashseed = arc4random(); > > @@ -717,11 +713,11 @@ > V_pf_state_key_z = uma_zcreate("pf state keys", > sizeof(struct pf_state_key), pf_state_key_ctor, NULL, NULL, NULL, > UMA_ALIGN_PTR, 0); > - V_pf_keyhash = malloc(V_pf_hashsize * sizeof(struct pf_keyhash), > + V_pf_keyhash = malloc(pf_hashsize * sizeof(struct pf_keyhash), > M_PFHASH, M_WAITOK | M_ZERO); > - V_pf_idhash = malloc(V_pf_hashsize * sizeof(struct pf_idhash), > + V_pf_idhash = malloc(pf_hashsize * sizeof(struct pf_idhash), > M_PFHASH, M_WAITOK | M_ZERO); > - V_pf_hashmask = V_pf_hashsize - 1; > + V_pf_hashmask = pf_hashsize - 1; > for (i = 0, kh = V_pf_keyhash, ih = V_pf_idhash; i <= V_pf_hashmask; > i++, kh++, ih++) { > mtx_init(&kh->lock, "pf_keyhash", NULL, MTX_DEF); > @@ -735,9 +731,9 @@ > V_pf_limits[PF_LIMIT_SRC_NODES].zone = V_pf_sources_z; > uma_zone_set_max(V_pf_sources_z, PFSNODE_HIWAT); > uma_zone_set_warning(V_pf_sources_z, "PF source nodes limit reached"); > - V_pf_srchash = malloc(V_pf_srchashsize * sizeof(struct pf_srchash), > + V_pf_srchash = malloc(pf_srchashsize * sizeof(struct pf_srchash), > M_PFHASH, M_WAITOK|M_ZERO); > - V_pf_srchashmask = V_pf_srchashsize - 1; > + V_pf_srchashmask = pf_srchashsize - 1; > for (i = 0, sh = V_pf_srchash; i <= V_pf_srchashmask; i++, sh++) > mtx_init(&sh->lock, "pf_srchash", NULL, MTX_DEF); > > @@ -757,13 +753,17 @@ > STAILQ_INIT(&V_pf_sendqueue); > SLIST_INIT(&V_pf_overloadqueue); > TASK_INIT(&V_pf_overloadtask, 0, pf_overload_task, &V_pf_overloadqueue); > - mtx_init(&pf_sendqueue_mtx, "pf send queue", NULL, MTX_DEF); > - mtx_init(&pf_overloadqueue_mtx, "pf overload/flush queue", NULL, > - MTX_DEF); > + if (IS_DEFAULT_VNET(curvnet)) { > + mtx_init(&pf_sendqueue_mtx, "pf send queue", NULL, MTX_DEF); > + mtx_init(&pf_overloadqueue_mtx, "pf overload/flush queue", NULL, > + MTX_DEF); > + } > > /* Unlinked, but may be referenced rules. */ > TAILQ_INIT(&V_pf_unlinked_rules); > - mtx_init(&pf_unlnkdrules_mtx, "pf unlinked rules", NULL, MTX_DEF); > + if (IS_DEFAULT_VNET(curvnet)) > + mtx_init(&pf_unlnkdrules_mtx, "pf unlinked rules", NULL, MTX_DEF); > + > } "if (IS_DEFAULT_VNET(curvnet))" constructions look a little ugly for me. Isn't possible to split these initialization functions on two parts: one (not "virtualized") to run by pf_load() and the other by vnet_pf_init()? > > void > @@ -1309,68 +1309,35 @@ > pf_purge_thread(void *v) > { > u_int idx = 0; > + VNET_ITERATOR_DECL(vnet_iter); > > - CURVNET_SET((struct vnet *)v); > - > for (;;) { > - PF_RULES_RLOCK(); > - rw_sleep(pf_purge_thread, &pf_rules_lock, 0, "pftm", hz / 10); > + tsleep(pf_purge_thread, PWAIT, "pftm", hz / 10); > + VNET_LIST_RLOCK(); > + VNET_FOREACH(vnet_iter) { > + CURVNET_SET(vnet_iter); > > - if (V_pf_end_threads) { > - /* > - * To cleanse up all kifs and rules we need > - * two runs: first one clears reference flags, > - * then pf_purge_expired_states() doesn't > - * raise them, and then second run frees. > - */ > - PF_RULES_RUNLOCK(); > - pf_purge_unlinked_rules(); > - pfi_kif_purge(); > - > - /* > - * Now purge everything. > - */ > - pf_purge_expired_states(0, V_pf_hashmask); > - pf_purge_expired_fragments(); > - pf_purge_expired_src_nodes(); > - > - /* > - * Now all kifs & rules should be unreferenced, > - * thus should be successfully freed. > - */ > - pf_purge_unlinked_rules(); > - pfi_kif_purge(); > - > - /* > - * Announce success and exit. > - */ > - PF_RULES_RLOCK(); > - V_pf_end_threads++; > - PF_RULES_RUNLOCK(); > - wakeup(pf_purge_thread); > - kproc_exit(0); > - } Running only one instance of pf_purge_thread, which iterates over all vnets looks like a good idea to me, but do we really not need this clean up stuff for our only thread? Don't you have issues e.g. on pf module unload? > - PF_RULES_RUNLOCK(); > - > /* Process 1/interval fraction of the state table every run. */ > idx = pf_purge_expired_states(idx, V_pf_hashmask / > - (V_pf_default_rule.timeout[PFTM_INTERVAL] * 10)); > + (V_pf_default_rule.timeout[PFTM_INTERVAL] * 10)); > > /* Purge other expired types every PFTM_INTERVAL seconds. */ > if (idx == 0) { > - /* > - * Order is important: > - * - states and src nodes reference rules > - * - states and rules reference kifs > - */ > - pf_purge_expired_fragments(); > - pf_purge_expired_src_nodes(); > - pf_purge_unlinked_rules(); > - pfi_kif_purge(); > + /* > + * Order is important: > + * - states and src nodes reference rules > + * - states and rules reference kifs > + */ > + pf_purge_expired_fragments(); > + pf_purge_expired_src_nodes(); > + pf_purge_unlinked_rules(); > + pfi_kif_purge(); This is a good example of unnecessary whitespace noise. > } > + CURVNET_RESTORE(); > + } > + VNET_LIST_RUNLOCK(); > } > /* not reached */ > - CURVNET_RESTORE(); > } > -- Mikolaj Golub From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 5 14:24:27 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7AAFE706 for ; Wed, 5 Jun 2013 14:24:27 +0000 (UTC) (envelope-from tj@melodicninja.co.uk) Received: from wallago.co.uk (mail.wallago.co.uk [91.213.195.71]) by mx1.freebsd.org (Postfix) with ESMTP id 461FD1C38 for ; Wed, 5 Jun 2013 14:24:26 +0000 (UTC) Received: from [178.78.126.226] (helo=[192.168.1.154]) by wallago.co.uk with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UkEZk-000Lxh-Ol for freebsd-virtualization@freebsd.org; Wed, 05 Jun 2013 15:20:33 +0100 Message-ID: <51AF4934.70105@melodicninja.co.uk> Date: Wed, 05 Jun 2013 15:20:36 +0100 From: TJ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org Subject: Best VM setup for FreeBSD Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:24:27 -0000 Hi guys, i am looking to setting up some virtual FreeBSD servers. I run a run a network that only has FreeBSD hosts and i want to setup a few test boxes but would be much easier if i could virtualise them. I know there is bhyve in CURRENT but it is still young and wanted something tried and true, the FreeBSD handbook suggest VirtualBox, but there are also things like qemu and xen. What is the best and easiest to manage? I have only ever used EXSi before but the ESXi client is not available for *nix so it makes managing a bit more difficult. Thanks From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 6 10:36:09 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AD93465C; Thu, 6 Jun 2013 10:36:09 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by mx1.freebsd.org (Postfix) with ESMTP id 593C51816; Thu, 6 Jun 2013 10:36:09 +0000 (UTC) Received: from [172.31.0.42] ([85.216.121.245]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Meutp-1V0Akm46gr-00OU2F; Thu, 06 Jun 2013 12:36:08 +0200 Message-ID: <51B065F5.4080209@gmx.com> Date: Thu, 06 Jun 2013 12:35:33 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mikolaj Golub Subject: Re: pf + vimage patch References: <51AC84EE.6020009@gmx.com> <20130605085219.GA53217@gmail.com> In-Reply-To: <20130605085219.GA53217@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:D++XOwS5R0lcMZ6V04weTtl/e1jFrUz3b2Q08P1soMzHg95wMGR SUvuUkPK5aAZIvOoScAfo8OQyRIXUFRvDrV8xf7fMp4w3V+OcjFx2q+Cp/02Y2H1ZUy5f49 dSUvretEMHOaLoN+BRt06i/RTffplPnrT3jWkOCgyOmdlc1jdSzcricwNb0qM0es0O4YdHb pLy1jCyEhqMsPMYPrxqRQ== Cc: "Bjoern A. Zeeb" , freebsd-jail@freebsd.org, Gleb Smirnoff , freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 10:36:09 -0000 Hi, Comments below. On 06/05/2013 10:52 AM, Mikolaj Golub wrote: > 1) It looks like the patch can be split on several parts. A log > message to every change describing why it is needed and what problem > solves would be very helpful. As a tool to maintain such changes I > personally prefer git. I'll try to break it in parts. It should be easy now to break it. Getting familiar with git will need some time so I'll handle it myself this time. > 2) You use spaces for indentation, where tabs should be. This adds > unnecessary noise and makes the patch less readable. Also someone > will need to fix this when eventually committing to the tree. Yes, I wrongly assumed that pf didn't follow style(9) strictly. Will fix that. > 3) When generating diff from svn, adding -x-pu options will make the > diff more readable. Yes indeed, thanks! > Also see some questions/comments below. > >> Index: sys/net/pfvar.h >> =================================================================== >> --- sys/net/pfvar.h (revision 251294) >> +++ sys/net/pfvar.h (working copy) >> @@ -901,7 +901,6 @@ >> struct pf_ruleset *, struct pf_pdesc *, int); >> extern pflog_packet_t *pflog_packet_ptr; >> >> -#define V_pf_end_threads VNET(pf_end_threads) >> #endif /* _KERNEL */ >> >> #define PFSYNC_FLAG_SRCNODE 0x04 >> Index: sys/netpfil/pf/pf.c >> =================================================================== >> --- sys/netpfil/pf/pf.c (revision 251294) >> +++ sys/netpfil/pf/pf.c (working copy) >> @@ -300,8 +300,6 @@ >> >> int in4_cksum(struct mbuf *m, u_int8_t nxt, int off, int len); >> >> -VNET_DECLARE(int, pf_end_threads); >> - >> VNET_DEFINE(struct pf_limit, pf_limits[PF_LIMIT_MAX]); >> >> #define PACKET_LOOPED(pd) ((pd)->pf_mtag && \ >> @@ -359,15 +357,13 @@ >> >> SYSCTL_NODE(_net, OID_AUTO, pf, CTLFLAG_RW, 0, "pf(4)"); >> >> -VNET_DEFINE(u_long, pf_hashsize); >> -#define V_pf_hashsize VNET(pf_hashsize) >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, >> - &VNET_NAME(pf_hashsize), 0, "Size of pf(4) states hashtable"); >> +u_long pf_hashsize; >> +SYSCTL_UINT(_net_pf, OID_AUTO, states_hashsize, CTLFLAG_RDTUN, >> + &pf_hashsize, 0, "Size of pf(4) states hashtable"); >> >> -VNET_DEFINE(u_long, pf_srchashsize); >> -#define V_pf_srchashsize VNET(pf_srchashsize) >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, >> - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable"); >> +u_long pf_srchashsize; >> +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, >> + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); >> > > Why do you have to devirtualize these variables? Are per vnet > hashtables sizes not useful or do they cause issues? Per VNET variables are not useful for pf_hashsize and pf_srchashsize since these values are RO and cannot be modified at runtime. >> VNET_DEFINE(void *, pf_swi_cookie); >> >> @@ -698,12 +694,12 @@ >> struct pf_srchash *sh; >> u_int i; >> >> - TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &V_pf_hashsize); >> - if (V_pf_hashsize == 0 || !powerof2(V_pf_hashsize)) >> - V_pf_hashsize = PF_HASHSIZ; >> - TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &V_pf_srchashsize); >> - if (V_pf_srchashsize == 0 || !powerof2(V_pf_srchashsize)) >> - V_pf_srchashsize = PF_HASHSIZ / 4; >> + TUNABLE_ULONG_FETCH("net.pf.states_hashsize", &pf_hashsize); >> + if (pf_hashsize == 0 || !powerof2(pf_hashsize)) >> + pf_hashsize = PF_HASHSIZ; >> + TUNABLE_ULONG_FETCH("net.pf.source_nodes_hashsize", &pf_srchashsize); >> + if (pf_srchashsize == 0 || !powerof2(pf_srchashsize)) >> + pf_srchashsize = PF_HASHSIZ / 4; >> >> V_pf_hashseed = arc4random(); >> >> @@ -717,11 +713,11 @@ >> V_pf_state_key_z = uma_zcreate("pf state keys", >> sizeof(struct pf_state_key), pf_state_key_ctor, NULL, NULL, NULL, >> UMA_ALIGN_PTR, 0); >> - V_pf_keyhash = malloc(V_pf_hashsize * sizeof(struct pf_keyhash), >> + V_pf_keyhash = malloc(pf_hashsize * sizeof(struct pf_keyhash), >> M_PFHASH, M_WAITOK | M_ZERO); >> - V_pf_idhash = malloc(V_pf_hashsize * sizeof(struct pf_idhash), >> + V_pf_idhash = malloc(pf_hashsize * sizeof(struct pf_idhash), >> M_PFHASH, M_WAITOK | M_ZERO); >> - V_pf_hashmask = V_pf_hashsize - 1; >> + V_pf_hashmask = pf_hashsize - 1; >> for (i = 0, kh = V_pf_keyhash, ih = V_pf_idhash; i <= V_pf_hashmask; >> i++, kh++, ih++) { >> mtx_init(&kh->lock, "pf_keyhash", NULL, MTX_DEF); >> @@ -735,9 +731,9 @@ >> V_pf_limits[PF_LIMIT_SRC_NODES].zone = V_pf_sources_z; >> uma_zone_set_max(V_pf_sources_z, PFSNODE_HIWAT); >> uma_zone_set_warning(V_pf_sources_z, "PF source nodes limit reached"); >> - V_pf_srchash = malloc(V_pf_srchashsize * sizeof(struct pf_srchash), >> + V_pf_srchash = malloc(pf_srchashsize * sizeof(struct pf_srchash), >> M_PFHASH, M_WAITOK|M_ZERO); >> - V_pf_srchashmask = V_pf_srchashsize - 1; >> + V_pf_srchashmask = pf_srchashsize - 1; >> for (i = 0, sh = V_pf_srchash; i <= V_pf_srchashmask; i++, sh++) >> mtx_init(&sh->lock, "pf_srchash", NULL, MTX_DEF); >> >> @@ -757,13 +753,17 @@ >> STAILQ_INIT(&V_pf_sendqueue); >> SLIST_INIT(&V_pf_overloadqueue); >> TASK_INIT(&V_pf_overloadtask, 0, pf_overload_task, &V_pf_overloadqueue); >> - mtx_init(&pf_sendqueue_mtx, "pf send queue", NULL, MTX_DEF); >> - mtx_init(&pf_overloadqueue_mtx, "pf overload/flush queue", NULL, >> - MTX_DEF); >> + if (IS_DEFAULT_VNET(curvnet)) { >> + mtx_init(&pf_sendqueue_mtx, "pf send queue", NULL, MTX_DEF); >> + mtx_init(&pf_overloadqueue_mtx, "pf overload/flush queue", NULL, >> + MTX_DEF); >> + } >> >> /* Unlinked, but may be referenced rules. */ >> TAILQ_INIT(&V_pf_unlinked_rules); >> - mtx_init(&pf_unlnkdrules_mtx, "pf unlinked rules", NULL, MTX_DEF); >> + if (IS_DEFAULT_VNET(curvnet)) >> + mtx_init(&pf_unlnkdrules_mtx, "pf unlinked rules", NULL, MTX_DEF); >> + >> } > > "if (IS_DEFAULT_VNET(curvnet))" constructions look a little ugly for > me. Isn't possible to split these initialization functions on two > parts: one (not "virtualized") to run by pf_load() and the other by > vnet_pf_init()? It is indeed ugly. I was trying not to diverse to much from the original code. I will do it properly. >> >> void >> @@ -1309,68 +1309,35 @@ >> pf_purge_thread(void *v) >> { >> u_int idx = 0; >> + VNET_ITERATOR_DECL(vnet_iter); >> >> - CURVNET_SET((struct vnet *)v); >> - >> for (;;) { >> - PF_RULES_RLOCK(); >> - rw_sleep(pf_purge_thread, &pf_rules_lock, 0, "pftm", hz / 10); >> + tsleep(pf_purge_thread, PWAIT, "pftm", hz / 10); >> + VNET_LIST_RLOCK(); >> + VNET_FOREACH(vnet_iter) { >> + CURVNET_SET(vnet_iter); >> >> - if (V_pf_end_threads) { >> - /* >> - * To cleanse up all kifs and rules we need >> - * two runs: first one clears reference flags, >> - * then pf_purge_expired_states() doesn't >> - * raise them, and then second run frees. >> - */ >> - PF_RULES_RUNLOCK(); >> - pf_purge_unlinked_rules(); >> - pfi_kif_purge(); >> - >> - /* >> - * Now purge everything. >> - */ >> - pf_purge_expired_states(0, V_pf_hashmask); >> - pf_purge_expired_fragments(); >> - pf_purge_expired_src_nodes(); >> - >> - /* >> - * Now all kifs & rules should be unreferenced, >> - * thus should be successfully freed. >> - */ >> - pf_purge_unlinked_rules(); >> - pfi_kif_purge(); >> - >> - /* >> - * Announce success and exit. >> - */ >> - PF_RULES_RLOCK(); >> - V_pf_end_threads++; >> - PF_RULES_RUNLOCK(); >> - wakeup(pf_purge_thread); >> - kproc_exit(0); >> - } > > Running only one instance of pf_purge_thread, which iterates over all > vnets looks like a good idea to me, but do we really not need this > clean up stuff for our only thread? Don't you have issues e.g. on pf > module unload? module unload is broken:( Maybe it can be fixed at a (bit) later date? >> - PF_RULES_RUNLOCK(); >> - >> /* Process 1/interval fraction of the state table every run. */ >> idx = pf_purge_expired_states(idx, V_pf_hashmask / >> - (V_pf_default_rule.timeout[PFTM_INTERVAL] * 10)); >> + (V_pf_default_rule.timeout[PFTM_INTERVAL] * 10)); >> >> /* Purge other expired types every PFTM_INTERVAL seconds. */ >> if (idx == 0) { >> - /* >> - * Order is important: >> - * - states and src nodes reference rules >> - * - states and rules reference kifs >> - */ >> - pf_purge_expired_fragments(); >> - pf_purge_expired_src_nodes(); >> - pf_purge_unlinked_rules(); >> - pfi_kif_purge(); >> + /* >> + * Order is important: >> + * - states and src nodes reference rules >> + * - states and rules reference kifs >> + */ >> + pf_purge_expired_fragments(); >> + pf_purge_expired_src_nodes(); >> + pf_purge_unlinked_rules(); >> + pfi_kif_purge(); > > This is a good example of unnecessary whitespace noise. will fix these. >> } >> + CURVNET_RESTORE(); >> + } >> + VNET_LIST_RUNLOCK(); >> } >> /* not reached */ >> - CURVNET_RESTORE(); >> } >> > Thank you for your comments. I was informed by bz@ that there is a security issue with pf being exposed in a jail, so I'll start from there and then will continue with your comments. Nikos From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 6 11:44:27 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0791BDB7 for ; Thu, 6 Jun 2013 11:44:27 +0000 (UTC) (envelope-from david@code.davidpcaldwell.com) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id D36711B30 for ; Thu, 6 Jun 2013 11:44:26 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id x14so6659203ief.40 for ; Thu, 06 Jun 2013 04:44:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=gAs78fpCBXdRcnzPfMdz1LGUyvstKH4agipINUTLun8=; b=mCzTa9nk11nKhGN/a+y8OLshfPXhuIOp63cwoCjgSJxY3EZsmbFZCKKcx4OHVGV27f /Ozi8aPLf1Kw69UQPI3cCZoeU99ODamex8U4P2u3sww8ayrE1uWYXk4traiZZnt+sZRY DCIFd2z6ohmaZa1UXTk2x9jzj8++smdBMvufj6ZHzXVMYbZYHD4XJqwheD9eZ4VrcqCE Xe/dALeiW3dES4Yldz6X3o6plGVOCvbmebrxRXl5q6ej6v08QbCM4xflpWU3rp8WlyOq 5kZNWlymzEu2bvEjG6IQWGZ84fhHJDDLawSoZbS8ARHLMcPAVQHc5MF1RDUG2xsf42au xKEg== X-Received: by 10.50.176.202 with SMTP id ck10mr5507885igc.9.1370519066469; Thu, 06 Jun 2013 04:44:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.166 with HTTP; Thu, 6 Jun 2013 04:44:05 -0700 (PDT) X-Originating-IP: [74.97.25.177] From: "David P. Caldwell" Date: Thu, 6 Jun 2013 07:44:05 -0400 Message-ID: Subject: VirtualBox and HAL instructions from the handbook To: freebsd-virtualization@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnxIttPaiq+8IFFdXNA33AhG1hvY1VRHwDPbxepNQT9oKZDDkzghOLtnyuyVAKOp/vxvt0k X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 11:44:27 -0000 The FreeBSD Handbook indicates at http://www.freebsd.org/doc/en/books/handbook/virtualization-guest.html that a /usr/local/etc/hal/fdi/policy/90-vboxguest.fdi should be created by copying it from /usr/local/share/hal/fdi/policy/10osvendor/90-vboxguest.fdi. My install scripts performed these steps when installing under 9.0 but under 9.1-RELEASE the second file is missing. I'm currently installing from binary packages. 1. Is this file still necessary? 2. Does its absence indicate anything went wrong with my install, or was it removed from the guest additions by mistake, or ...? -- David Caldwell http://www.davidpcaldwell.com/ From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 6 12:24:17 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 14C80278; Thu, 6 Jun 2013 12:24:17 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id E611F1DE6; Thu, 6 Jun 2013 12:24:15 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id r7so1570276bkg.31 for ; Thu, 06 Jun 2013 05:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=eIZGnFUwokq+esK0tN2UdK4DZfTSBmtRPjlpxKUkiq0=; b=tiXxjS0oPRWCZjUWM041S7SLylnm9facT8wCnDGt5gNO54dPQWTrqTh2DDDBAxmfIV lnIU+Fu3R2b9PcADqugtJxT4U2GZfmDV0F0X0FOxPtKbkeinb4LzHteEtxf2gaEn8c04 MXNl2K29EcP6b9jr6ZpS9alpaoEvh8usMLP+f2ozljqhsYjV2J4XF5x2NTVdsIGC+YZD uN5yRngJQPgXiNcCZBsrhUX8jkZRJXpPvThK0u6yB3g72u9vRpjHnEnr8sOpOrBB4QpW NVWjc2teC25pPMeFeuCFHDsFHEJTfqOQDo8Nl53E/Mrw6UJxyrEkWkb1ewFD6qr0SkcA LpbA== X-Received: by 10.204.72.137 with SMTP id m9mr634498bkj.122.1370521454805; Thu, 06 Jun 2013 05:24:14 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id fz10sm27756318bkc.9.2013.06.06.05.24.12 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 06 Jun 2013 05:24:13 -0700 (PDT) Sender: Mikolaj Golub Date: Thu, 6 Jun 2013 15:24:10 +0300 From: Mikolaj Golub To: Nikos Vassiliadis Subject: Re: pf + vimage patch Message-ID: <20130606122409.GA10459@gmail.com> References: <51AC84EE.6020009@gmx.com> <20130605085219.GA53217@gmail.com> <51B065F5.4080209@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51B065F5.4080209@gmx.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Bjoern A. Zeeb" , freebsd-jail@freebsd.org, Gleb Smirnoff , freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 12:24:17 -0000 On Thu, Jun 06, 2013 at 12:35:33PM +0200, Nikos Vassiliadis wrote: > >> -VNET_DEFINE(u_long, pf_srchashsize); > >> -#define V_pf_srchashsize VNET(pf_srchashsize) > >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, > >> - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable"); > >> +u_long pf_srchashsize; > >> +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, > >> + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); > >> > > > > Why do you have to devirtualize these variables? Are per vnet > > hashtables sizes not useful or do they cause issues? > > Per VNET variables are not useful for pf_hashsize and pf_srchashsize > since these values are RO and cannot be modified at runtime. Indeed. I missed RDTUN flag. > module unload is broken:( Maybe it can be fixed at a (bit) later date? I don't think Gleb will be happy with this. Some time ago he removed some vimage related stuff to prevent crashing on module unload (see r229849). Actually your patch looks like a partial revert of that commit. So I think you need to think about this issue from start. At least it should not crash non-vimage kernel and there should be understanding how to fix it for vimage kernel. Your approach with keeping only one purge thread might make it simpler. -- Mikolaj Golub From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 6 12:28:58 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 45AA838E; Thu, 6 Jun 2013 12:28:58 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 629C61E29; Thu, 6 Jun 2013 12:28:57 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r56CSuta046057; Thu, 6 Jun 2013 16:28:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r56CSuQL046056; Thu, 6 Jun 2013 16:28:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 6 Jun 2013 16:28:55 +0400 From: Gleb Smirnoff To: Mikolaj Golub Subject: Re: pf + vimage patch Message-ID: <20130606122855.GC14667@glebius.int.ru> References: <51AC84EE.6020009@gmx.com> <20130605085219.GA53217@gmail.com> <51B065F5.4080209@gmx.com> <20130606122409.GA10459@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20130606122409.GA10459@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-jail@freebsd.org, "Bjoern A. Zeeb" , freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 12:28:58 -0000 On Thu, Jun 06, 2013 at 03:24:10PM +0300, Mikolaj Golub wrote: M> > >> -VNET_DEFINE(u_long, pf_srchashsize); M> > >> -#define V_pf_srchashsize VNET(pf_srchashsize) M> > >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, M> > >> - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes hashtable"); M> > >> +u_long pf_srchashsize; M> > >> +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, CTLFLAG_RDTUN, M> > >> + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); M> > >> M> > > M> > > Why do you have to devirtualize these variables? Are per vnet M> > > hashtables sizes not useful or do they cause issues? M> > M> > Per VNET variables are not useful for pf_hashsize and pf_srchashsize M> > since these values are RO and cannot be modified at runtime. M> M> Indeed. I missed RDTUN flag. M> M> > module unload is broken:( Maybe it can be fixed at a (bit) later date? M> M> I don't think Gleb will be happy with this. Some time ago he removed M> some vimage related stuff to prevent crashing on module unload (see M> r229849). Actually your patch looks like a partial revert of that M> commit. So I think you need to think about this issue from start. At M> least it should not crash non-vimage kernel and there should be M> understanding how to fix it for vimage kernel. Your approach with M> keeping only one purge thread might make it simpler. True. It is very much appreciated that you are working on vimage + pf, but breaking module unload isn't an option. When hacking on a part of kernel, having a possibility to avoid a reboot after each compile is very important. -- Totus tuus, Glebius. From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 6 13:19:39 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 333C32AE for ; Thu, 6 Jun 2013 13:19:39 +0000 (UTC) (envelope-from david@code.davidpcaldwell.com) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 07DC410DD for ; Thu, 6 Jun 2013 13:19:38 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id e14so7217843iej.29 for ; Thu, 06 Jun 2013 06:19:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:content-type:x-gm-message-state; bh=rOyTYCg5HdJpjXa4oxPkmaYIVFeAom1oCv9DxJ5+Zw0=; b=BXlYMooE927Zwa2Vgm/Q5Wk5rdaNF0SYUBcSPShnhOD63vXdHn78bFXumGfyRO89jF z2ZvruYS6wSwX9NmVqmwFWmeuYmWeSTMPqxWhiB8qhuo4B93KHf3LX+sffGiBB5jqW1T c4Ulf6io7Ep//JL4exy5hydgN0lMtXulTJ1JM9Hty3kELn7n1Tp4Nfiy2mcxG55CKjEm p7la4m/pAL/MDZUTHYEux8WQKbSHHSvkMHzEJtA6MLhzB/qdiPZOMr09JYaK33m1n0il Ix98FsN5MSzgvPYs2VdDZ5RwUHAEh03guunOXzIVyGw45314RTXGHxl3XJbRK/y2QmXM +RiQ== X-Received: by 10.50.61.141 with SMTP id p13mr5708839igr.9.1370524778585; Thu, 06 Jun 2013 06:19:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.166 with HTTP; Thu, 6 Jun 2013 06:19:18 -0700 (PDT) X-Originating-IP: [74.97.25.177] In-Reply-To: References: From: "David P. Caldwell" Date: Thu, 6 Jun 2013 09:19:18 -0400 Message-ID: Subject: Re: VirtualBox and HAL instructions from the handbook To: freebsd-virtualization@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn/2Thf1ECmZ8ES8NZC3Z6vhAxjhXudttetcV/KxU4QLJB+QQEdKkzIyFdSuyunERBinx+b X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:19:39 -0000 I can confirm it is necessary for mouse capture to work properly. If it's not installed to /usr/local/share/hal/... by the port, and it appears not to be, I think that's a PR either for the handbook or the port, but I'm not sure which it should be (suggestions welcome). Although you can hand-type it in (and the handbook actually includes this as an option, to its credit) it seems to me that if it's static content, having it available for copy makes more sense. (Or should the port simply install it to the correct location? I don't see a reason why not but I am not an expert.) -- David Caldwell http://www.davidpcaldwell.com/ On Thu, Jun 6, 2013 at 7:44 AM, David P. Caldwell wrote: > The FreeBSD Handbook indicates at > http://www.freebsd.org/doc/en/books/handbook/virtualization-guest.html > that a /usr/local/etc/hal/fdi/policy/90-vboxguest.fdi should be > created by copying it from > /usr/local/share/hal/fdi/policy/10osvendor/90-vboxguest.fdi. My > install scripts performed these steps when installing under 9.0 but > under 9.1-RELEASE the second file is missing. > > I'm currently installing from binary packages. > > 1. Is this file still necessary? > 2. Does its absence indicate anything went wrong with my install, or > was it removed from the guest additions by mistake, or ...? > > -- David Caldwell > http://www.davidpcaldwell.com/ From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 6 13:30:44 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D14C6BE3; Thu, 6 Jun 2013 13:30:44 +0000 (UTC) (envelope-from titi5187@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 765361198; Thu, 6 Jun 2013 13:30:44 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id s9so7105216iec.30 for ; Thu, 06 Jun 2013 06:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GSpRu686kn7cS675oheBZtUm+9tcakEOjGvbZuLM0C0=; b=hpYiz3ocl2invRhNmAVQ450cz/9DVr0t64JMHDT9tZRPZ6wVMTgXj20YOFrx7SzFqN WhkSo6UkhAILyYyCpRGcIIxdzLTc/lqWCq7LmSUI7tKm0tmUlXgI1lR2cuNdQ9f14BKz v7TQ+UWXVAEDCU65W5J4OwhOGbqoQtxCiNV+xoM7HnY+kCzRi8Ydw9Vu4gKVdwDwTHFY lZf7om2JcUPu0R1PrWRjO/qpD+HyZ4wKtrbX+/uhMRJ/gKoKCjbi4P9/6cXf/BQPFJ5F wa0XPHCqmBAaRVkFkQnreAq54HwDmfPmdQ/k+16g/wufoIH44XoNlttwTLSrNM/LaqGz vwYw== MIME-Version: 1.0 X-Received: by 10.50.47.105 with SMTP id c9mr5808925ign.50.1370525444206; Thu, 06 Jun 2013 06:30:44 -0700 (PDT) Received: by 10.64.89.71 with HTTP; Thu, 6 Jun 2013 06:30:44 -0700 (PDT) In-Reply-To: <20130606122855.GC14667@glebius.int.ru> References: <51AC84EE.6020009@gmx.com> <20130605085219.GA53217@gmail.com> <51B065F5.4080209@gmx.com> <20130606122409.GA10459@gmail.com> <20130606122855.GC14667@glebius.int.ru> Date: Thu, 6 Jun 2013 15:30:44 +0200 Message-ID: Subject: Re: pf + vimage patch From: Thibault Noel To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Mikolaj Golub , "Bjoern A. Zeeb" , freebsd-jail@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:30:44 -0000 Hi, I quite agree with Gleb Smirnoff on the possibility of avoiding a reboot after each compile. I don't now if it's a good moment to speak of this, but I observed that if pfsync is active in the kernel, it will use its state table even if nothing is set in the rc.conf. I think that if no parameters is written in the rc.conf (syncpeer, etc. ..) it will not be usefull to create lock to block the state table thus it will slow pf. What do you think ? 2013/6/6 Gleb Smirnoff > On Thu, Jun 06, 2013 at 03:24:10PM +0300, Mikolaj Golub wrote: > M> > >> -VNET_DEFINE(u_long, pf_srchashsize); > M> > >> -#define V_pf_srchashsize VNET(pf_srchashsize) > M> > >> -SYSCTL_VNET_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, > CTLFLAG_RDTUN, > M> > >> - &VNET_NAME(pf_srchashsize), 0, "Size of pf(4) source nodes > hashtable"); > M> > >> +u_long pf_srchashsize; > M> > >> +SYSCTL_UINT(_net_pf, OID_AUTO, source_nodes_hashsize, > CTLFLAG_RDTUN, > M> > >> + &pf_srchashsize, 0, "Size of pf(4) source nodes hashtable"); > M> > >> > M> > > > M> > > Why do you have to devirtualize these variables? Are per vnet > M> > > hashtables sizes not useful or do they cause issues? > M> > > M> > Per VNET variables are not useful for pf_hashsize and pf_srchashsize > M> > since these values are RO and cannot be modified at runtime. > M> > M> Indeed. I missed RDTUN flag. > M> > M> > module unload is broken:( Maybe it can be fixed at a (bit) later date? > M> > M> I don't think Gleb will be happy with this. Some time ago he removed > M> some vimage related stuff to prevent crashing on module unload (see > M> r229849). Actually your patch looks like a partial revert of that > M> commit. So I think you need to think about this issue from start. At > M> least it should not crash non-vimage kernel and there should be > M> understanding how to fix it for vimage kernel. Your approach with > M> keeping only one purge thread might make it simpler. > > True. It is very much appreciated that you are working on vimage + pf, > but breaking module unload isn't an option. > > When hacking on a part of kernel, having a possibility to avoid a reboot > after each compile is very important. > > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to " > freebsd-virtualization-unsubscribe@freebsd.org" > From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 6 14:21:57 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E9C58265 for ; Thu, 6 Jun 2013 14:21:57 +0000 (UTC) (envelope-from david@code.davidpcaldwell.com) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id C159C1696 for ; Thu, 6 Jun 2013 14:21:57 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id aq17so7004052iec.5 for ; Thu, 06 Jun 2013 07:21:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:cc:content-type:x-gm-message-state; bh=NyDEE8LyZYMN/POhaUgI0814PkfFIL0NeZhZyLqf3kw=; b=U8PS2Ot5Kn+3CdrkQMK3olwVgJDRDPoIOUjVpa+H3pvNnTyLV0XsS5pcjzHLQde3Y5 B0kOGlpyQyt8vyVAB0GT/Fm97Qmnz14popyYHeDbDDZMarzBES9e9oEC84QxW+gjivRR FFNBAqi4N+CE75KnlrTjHJgWj48JjnX7ztoT3yeIdzKZBaJCGVjAO80X9NYEdwHCoL2u vkXAOQmvNQoOb0q4emWgDKhxooTRUOQKgY6P8JyLSLIStXWjkrHDFxZQ5pJBCDFYCmyT T0WJQyKXDJn2avMboMM+OrMQEzf7wjplQNbDgwbvKLCm1FxncrlKTn81qQzhRWgo/cgs Vt7w== X-Received: by 10.50.22.106 with SMTP id c10mr5725457igf.14.1370528517466; Thu, 06 Jun 2013 07:21:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.166 with HTTP; Thu, 6 Jun 2013 07:21:37 -0700 (PDT) X-Originating-IP: [74.97.25.177] In-Reply-To: <51AF4934.70105@melodicninja.co.uk> References: <51AF4934.70105@melodicninja.co.uk> From: "David P. Caldwell" Date: Thu, 6 Jun 2013 10:21:37 -0400 Message-ID: Subject: Re: Best VM setup for FreeBSD Cc: freebsd-virtualization@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmPmGTJ6T7umMKbSOuKrPpDsY9R0PnewNNDVpJHA/QmOC8IPRZB6g6PoU21B2lCACiqOJsB X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:21:58 -0000 I am using VirtualBox without incident, with a Windows 7 host. -- David Caldwell http://www.davidpcaldwell.com/ On Wed, Jun 5, 2013 at 10:20 AM, TJ wrote: > Hi guys, > i am looking to setting up some virtual FreeBSD servers. > > I run a run a network that only has FreeBSD hosts and i want to setup a few > test boxes but would be much easier if i could virtualise them. > > I know there is bhyve in CURRENT but it is still young and wanted something > tried and true, the FreeBSD handbook suggest VirtualBox, but there are also > things like qemu and xen. > > What is the best and easiest to manage? > > I have only ever used EXSi before but the ESXi client is not available for > *nix so it makes managing a bit more difficult. > > Thanks > > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org" From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 6 14:25:51 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6823D554 for ; Thu, 6 Jun 2013 14:25:51 +0000 (UTC) (envelope-from Kamil.Choudhury@anserinae.net) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id 2D09A16E4 for ; Thu, 6 Jun 2013 14:25:51 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=fZsvOjsF c=1 sm=0 a=jrWvM0xCa/yzQsHFmCBh5A==:17 a=XtYZqdvDNwYA:10 a=WWGGoYozHbgA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=NUNO_Q2GAAAA:8 a=1dnpbELdzHQA:10 a=6I5d2MoRAAAA:8 a=jSlUy61IAAAA:8 a=4ckiwXijAAAA:8 a=vni2BHERwoZKm0jKpkUA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=LweTLliqTwMA:10 a=jrWvM0xCa/yzQsHFmCBh5A==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 74.73.121.187 Received: from [74.73.121.187] ([74.73.121.187:53093] helo=janus.anserinae.net) by hrndva-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id C4/90-10569-EEB90B15; Thu, 06 Jun 2013 14:25:50 +0000 Received: from JANUS.anserinae.net ([fe80::192c:4b89:9fe9:dc6d]) by janus.anserinae.net ([fe80::192c:4b89:9fe9:dc6d%11]) with mapi id 14.03.0123.003; Thu, 6 Jun 2013 10:25:49 -0400 From: Kamil Choudhury To: "David P. Caldwell" Subject: RE: Best VM setup for FreeBSD Thread-Topic: Best VM setup for FreeBSD Thread-Index: AQHOYsE6M88hkcgouk26cKjZTo5MFZkovZX2 Date: Thu, 6 Jun 2013 14:25:49 +0000 Message-ID: References: <51AF4934.70105@melodicninja.co.uk>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-virtualization@freebsd.org" X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:25:51 -0000 Virtualbox + iscsi + ZFS snapshotting =3D a pretty good time overall. =0A= =0A= ________________________________________=0A= From: owner-freebsd-virtualization@freebsd.org [owner-freebsd-virtualizatio= n@freebsd.org] on behalf of David P. Caldwell [david@code.davidpcaldwell.co= m]=0A= Sent: Thursday, June 06, 2013 10:21=0A= Cc: freebsd-virtualization@freebsd.org=0A= Subject: Re: Best VM setup for FreeBSD=0A= =0A= I am using VirtualBox without incident, with a Windows 7 host.=0A= =0A= -- David Caldwell=0A= http://www.davidpcaldwell.com/=0A= =0A= On Wed, Jun 5, 2013 at 10:20 AM, TJ wrote:=0A= > Hi guys,=0A= > i am looking to setting up some virtual FreeBSD servers.=0A= >=0A= > I run a run a network that only has FreeBSD hosts and i want to setup a f= ew=0A= > test boxes but would be much easier if i could virtualise them.=0A= >=0A= > I know there is bhyve in CURRENT but it is still young and wanted somethi= ng=0A= > tried and true, the FreeBSD handbook suggest VirtualBox, but there are al= so=0A= > things like qemu and xen.=0A= >=0A= > What is the best and easiest to manage?=0A= >=0A= > I have only ever used EXSi before but the ESXi client is not available fo= r=0A= > *nix so it makes managing a bit more difficult.=0A= >=0A= > Thanks=0A= >=0A= > _______________________________________________=0A= > freebsd-virtualization@freebsd.org mailing list=0A= > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization=0A= > To unsubscribe, send any mail to=0A= > "freebsd-virtualization-unsubscribe@freebsd.org"=0A= _______________________________________________=0A= freebsd-virtualization@freebsd.org mailing list=0A= http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization=0A= To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebs= d.org"=0A= From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 6 14:26:29 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 428ED590 for ; Thu, 6 Jun 2013 14:26:29 +0000 (UTC) (envelope-from tj@melodicninja.co.uk) Received: from wallago.co.uk (mail.wallago.co.uk [91.213.195.71]) by mx1.freebsd.org (Postfix) with ESMTP id 0AECC16E9 for ; Thu, 6 Jun 2013 14:26:28 +0000 (UTC) Received: from [178.78.126.226] (helo=[192.168.1.154]) by wallago.co.uk with esmtpa (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Ukb8u-000Nyg-Uq; Thu, 06 Jun 2013 15:26:20 +0100 Message-ID: <51B09C11.3010100@melodicninja.co.uk> Date: Thu, 06 Jun 2013 15:26:25 +0100 From: TJ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "David P. Caldwell" Subject: Re: Best VM setup for FreeBSD References: <51AF4934.70105@melodicninja.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:26:29 -0000 I have been looking into VirtualBox. My biggest hurdle at the moment is getting multiple hosts on one machine and setting up the VRDE to use different ports. I have also tried qemu and was having vnc issues too. On 06/06/13 15:21, David P. Caldwell wrote: > I am using VirtualBox without incident, with a Windows 7 host. > > -- David Caldwell > http://www.davidpcaldwell.com/ > > On Wed, Jun 5, 2013 at 10:20 AM, TJ wrote: >> Hi guys, >> i am looking to setting up some virtual FreeBSD servers. >> >> I run a run a network that only has FreeBSD hosts and i want to setup a few >> test boxes but would be much easier if i could virtualise them. >> >> I know there is bhyve in CURRENT but it is still young and wanted something >> tried and true, the FreeBSD handbook suggest VirtualBox, but there are also >> things like qemu and xen. >> >> What is the best and easiest to manage? >> >> I have only ever used EXSi before but the ESXi client is not available for >> *nix so it makes managing a bit more difficult. >> >> Thanks >> >> _______________________________________________ >> freebsd-virtualization@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >> To unsubscribe, send any mail to >> "freebsd-virtualization-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 6 16:47:17 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1A36CEEC; Thu, 6 Jun 2013 16:47:17 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id A7C0F1D9A; Thu, 6 Jun 2013 16:47:16 +0000 (UTC) Received: from [172.31.0.42] ([85.216.121.245]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M6ilI-1UPe5B3EJQ-00wXDy; Thu, 06 Jun 2013 18:47:10 +0200 Message-ID: <51B0BD05.60102@gmx.com> Date: Thu, 06 Jun 2013 18:47:01 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: pf + vimage patch References: <51AC84EE.6020009@gmx.com> <20130605085219.GA53217@gmail.com> <51B065F5.4080209@gmx.com> <20130606122409.GA10459@gmail.com> <20130606122855.GC14667@glebius.int.ru> In-Reply-To: <20130606122855.GC14667@glebius.int.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:yLPARyYTKHkkRyMtMbsVYPXLJmfa+iUwAGfyu/gWFigeoljAbek VURb4qnVbCeCSutaraVeR5+cQsGY6dqwta+KHp2Lhpkc6jc+4Ns8Ov8aCm9ARWdepLnqwvq j/Z9aJIJ/x21zUjY5JgwGE1dA4TOgBZeCHVhGulJQH3SYRQNvT0LpyINMl/H+xpcFUBVc0s jHUNEiKxYm0gHLIptgxGQ== Cc: Mikolaj Golub , "Bjoern A. Zeeb" , freebsd-jail@freebsd.org, freebsd-virtualization@freebsd.org, freebsd-pf@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 16:47:17 -0000 On 06/06/2013 02:28 PM, Gleb Smirnoff wrote: > M> > module unload is broken:( Maybe it can be fixed at a (bit) later date? > M> > M> I don't think Gleb will be happy with this. Some time ago he removed > M> some vimage related stuff to prevent crashing on module unload (see > M> r229849). Actually your patch looks like a partial revert of that > M> commit. So I think you need to think about this issue from start. At > M> least it should not crash non-vimage kernel and there should be > M> understanding how to fix it for vimage kernel. Your approach with > M> keeping only one purge thread might make it simpler. Unloading should be simple in the non-vimage case as well - I think. > True. It is very much appreciated that you are working on vimage + pf, > but breaking module unload isn't an option. > > When hacking on a part of kernel, having a possibility to avoid a reboot > after each compile is very important. > Good point. Thank you both for your comments. Nikos From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 6 17:18:06 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EB4F5737 for ; Thu, 6 Jun 2013 17:18:06 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by mx1.freebsd.org (Postfix) with ESMTP id B8B5C1EBB for ; Thu, 6 Jun 2013 17:18:06 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id v19so5097860obq.35 for ; Thu, 06 Jun 2013 10:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=whVPHRGIFYw/eJ+VdzICjkw5c/vl7BSuUMzAgO2DIj8=; b=CKkUMrsAsSQa4ovokYTOgLyzpJJJVKESUEQnZzcpv1r0QH/7O5ucmKPh17GMrHSHoe j8kvXc/ytOw6me7i4l0Wm4UNclQiydl0VTZXYa0ls9LSvZiLkeKpMvrCuUQUgJ951R/C 5ITskQz3sk9ldPMGn5FQNG3O8NnC9vZMgy3dlpkNQnrCEUiaSzBeyxC0OzFge6AKm6Yi zMnKaIN2X6HQv/ll5zwaKrZb/pIZZOpk7WavPebJlt7kamK2A9197HKk23WWrY8dCUjH GF42WBBUF64IkzHDmhDvx/oxA23ApdyTE++EL10vSELCvpPIB2swDqyDB8cgIEYuynUO Iveg== MIME-Version: 1.0 X-Received: by 10.60.132.6 with SMTP id oq6mr18625187oeb.113.1370539086253; Thu, 06 Jun 2013 10:18:06 -0700 (PDT) Received: by 10.76.169.68 with HTTP; Thu, 6 Jun 2013 10:18:06 -0700 (PDT) In-Reply-To: <51B09C11.3010100@melodicninja.co.uk> References: <51AF4934.70105@melodicninja.co.uk> <51B09C11.3010100@melodicninja.co.uk> Date: Thu, 6 Jun 2013 13:18:06 -0400 Message-ID: Subject: Re: Best VM setup for FreeBSD From: Outback Dingo To: TJ Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:18:07 -0000 On Thu, Jun 6, 2013 at 10:26 AM, TJ wrote: > > I have been looking into VirtualBox. > > My biggest hurdle at the moment is getting multiple hosts on one machine > and setting up the VRDE to use different ports. > > I have also tried qemu and was having vnc issues too. > > > On 06/06/13 15:21, David P. Caldwell wrote: > >> I am using VirtualBox without incident, with a Windows 7 host. >> >> -- David Caldwell >> http://www.davidpcaldwell.com/ >> >> On Wed, Jun 5, 2013 at 10:20 AM, TJ wrote: >> >>> Hi guys, >>> i am looking to setting up some virtual FreeBSD servers. >>> >>> I run a run a network that only has FreeBSD hosts and i want to setup a >>> few >>> test boxes but would be much easier if i could virtualise them. >>> >>> I know there is bhyve in CURRENT but it is still young and wanted >>> something >>> tried and true, the FreeBSD handbook suggest VirtualBox, but there are >>> also >>> things like qemu and xen. >>> >>> What is the best and easiest to manage? >>> >>> I have only ever used EXSi before but the ESXi client is not available >>> for >>> *nix so it makes managing a bit more difficult. >>> >>> Id say definitely XEN XCP (Xen Cloud Platform) its free, and i run FreeBSD XENHVM guests on it all day long > Thanks >>> >>> ______________________________**_________________ >>> freebsd-virtualization@**freebsd.orgmailing list >>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**virtualization >>> To unsubscribe, send any mail to >>> "freebsd-virtualization-**unsubscribe@freebsd.org >>> " >>> >> ______________________________**_________________ >> freebsd-virtualization@**freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-**virtualization >> To unsubscribe, send any mail to "freebsd-virtualization-** >> unsubscribe@freebsd.org " >> > > ______________________________**_________________ > freebsd-virtualization@**freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**virtualization > To unsubscribe, send any mail to "freebsd-virtualization-** > unsubscribe@freebsd.org " > From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 6 19:16:43 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 18216233 for ; Thu, 6 Jun 2013 19:16:43 +0000 (UTC) (envelope-from michael.berman@tidalscale.com) Received: from smtp125.dfw.emailsrvr.com (smtp125.dfw.emailsrvr.com [67.192.241.125]) by mx1.freebsd.org (Postfix) with ESMTP id D55951306 for ; Thu, 6 Jun 2013 19:16:42 +0000 (UTC) Received: from smtp2.relay.dfw1a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp2.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id AC3F678882 for ; Thu, 6 Jun 2013 15:10:51 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox 2.7.4 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id A823D7888C for ; Thu, 6 Jun 2013 15:10:51 -0400 (EDT) X-Virus-Scanned: OK Received: from smtp133.ord.emailsrvr.com (smtp133.ord.emailsrvr.com [173.203.6.133]) by smtp2.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTPS id 8F4B678882 for ; Thu, 6 Jun 2013 15:10:51 -0400 (EDT) Received: from smtp25.relay.ord1a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp25.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id AB01F3F0129; Thu, 6 Jun 2013 15:10:45 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox 2.7.4 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id A31503F00BC; Thu, 6 Jun 2013 15:10:45 -0400 (EDT) X-Virus-Scanned: OK Received: from smtp192.mex05.mlsrvr.com (unknown [184.106.31.85]) by smtp25.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTPS id 845853F014F; Thu, 6 Jun 2013 15:10:45 -0400 (EDT) Received: from ORD2MBX05C.mex05.mlsrvr.com ([fe80::90e2:baff:fe30:7498]) by ORD2HUB25.mex05.mlsrvr.com ([fe80::be30:5bff:fef5:2014%15]) with mapi id 14.03.0123.003; Thu, 6 Jun 2013 14:10:45 -0500 From: Michael Berman To: TJ Subject: Re: Best VM setup for FreeBSD Thread-Topic: Best VM setup for FreeBSD Thread-Index: AQHOYfhnCX3n8CcYjECPV9258dtLRpkpEi+AgAABWID//9oUAA== Date: Thu, 6 Jun 2013 19:10:44 +0000 Message-ID: In-Reply-To: <51B09C11.3010100@melodicninja.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [152.179.42.173] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-virtualization@freebsd.org" X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 19:16:43 -0000 I run multiple VMs using VMware Fusion. VMware has *nix support in their Workstation product. On 6/6/13 7:26 AM, "TJ" wrote: > >I have been looking into VirtualBox. > >My biggest hurdle at the moment is getting multiple hosts on one machine >and setting up the VRDE to use different ports. > >I have also tried qemu and was having vnc issues too. > >On 06/06/13 15:21, David P. Caldwell wrote: >> I am using VirtualBox without incident, with a Windows 7 host. >> >> -- David Caldwell >> http://www.davidpcaldwell.com/ >> >> On Wed, Jun 5, 2013 at 10:20 AM, TJ wrote: >>> Hi guys, >>> i am looking to setting up some virtual FreeBSD servers. >>> >>> I run a run a network that only has FreeBSD hosts and i want to setup >>>a few >>> test boxes but would be much easier if i could virtualise them. >>> >>> I know there is bhyve in CURRENT but it is still young and wanted >>>something >>> tried and true, the FreeBSD handbook suggest VirtualBox, but there are >>>also >>> things like qemu and xen. >>> >>> What is the best and easiest to manage? >>> >>> I have only ever used EXSi before but the ESXi client is not available >>>for >>> *nix so it makes managing a bit more difficult. >>> >>> Thanks >>> >>> _______________________________________________ >>> freebsd-virtualization@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >>> To unsubscribe, send any mail to >>> "freebsd-virtualization-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-virtualization@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >> To unsubscribe, send any mail to >>"freebsd-virtualization-unsubscribe@freebsd.org" > >_______________________________________________ >freebsd-virtualization@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >To unsubscribe, send any mail to >"freebsd-virtualization-unsubscribe@freebsd.org" From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 6 20:12:23 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4713CAE4 for ; Thu, 6 Jun 2013 20:12:23 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 24E0F1198 for ; Thu, 6 Jun 2013 20:12:23 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id um15so3719966pbc.38 for ; Thu, 06 Jun 2013 13:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v9vyNUAD+R6ZVsJq/kJJVaW2Q974vVKeIT5gjCtzz9w=; b=bMRV3hIOnxEek8101UBdRvHTOu7J0ArIz8I1SqyRH0CJiWOLy5GAtxydfgdlDNYIOX JALpxCRHiGTA0ikdJL+Pa+fwQGCqSGdwtJWVqC8VbPpxXYbr8alFrMrNZ53L/aXice0q mqHIxBbh09uW7FXn+ft57+SNJKV7SBMfizrfFNPmSTWkl5Ln5eoKrjZaRQMOfiAa/7pE b0a9EMy//Wm/Xd9j+2cX0fnsim1Q8xPV0RDf/pWiCxkuVFBfBg6giVjxi7wUICy5PRT7 f9WpPN8/hAZ/o1J6nntP+21FSYskoBfUiIwLZ/wFqrQuPuABtE1kSP1ChVJRylXYd0TQ URLw== MIME-Version: 1.0 X-Received: by 10.66.87.5 with SMTP id t5mr19613479paz.169.1370547778057; Thu, 06 Jun 2013 12:42:58 -0700 (PDT) Received: by 10.70.31.195 with HTTP; Thu, 6 Jun 2013 12:42:57 -0700 (PDT) In-Reply-To: <51B09C11.3010100@melodicninja.co.uk> References: <51AF4934.70105@melodicninja.co.uk> <51B09C11.3010100@melodicninja.co.uk> Date: Thu, 6 Jun 2013 14:42:57 -0500 Message-ID: Subject: Re: Best VM setup for FreeBSD From: Adam Vande More To: TJ Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 20:12:23 -0000 On Thu, Jun 6, 2013 at 9:26 AM, TJ wrote: > > I have been looking into VirtualBox. > > My biggest hurdle at the moment is getting multiple hosts on one machine > and setting up the VRDE to use different ports. Works great for me. -- Adam Vande More From owner-freebsd-virtualization@FreeBSD.ORG Fri Jun 7 10:31:35 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4310CB0E; Fri, 7 Jun 2013 10:31:35 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id A0D1216CD; Fri, 7 Jun 2013 10:31:34 +0000 (UTC) Received: by mail-bk0-f45.google.com with SMTP id je9so657808bkc.18 for ; Fri, 07 Jun 2013 03:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=GsqbKxXHey+LKdsWRkiu9ghv0/KYndRzMc5eSWCdTp0=; b=jHJBXlys1DPiQKvi6vpm6xRLbqlNQtwJWaSnD3K8Hcjz3tPrb/cggOkFgxkNrdYxDz /eNFbkjY3PiMUgZlTU7jziQupH8lbOAtjW++SwRKMRvYpXiBVhHbQVPTqOdTwA5jJj4z 1I56d0t16EnzHyVNPtnazH7LhqblF9d+C312eX/sZolKzYl5GqRs677Fjx+LYwc+3de9 IdK8vMX0y+P+eCOIHQvspNSAG4KB64FouUCSCvVrehusjVBB+fKYSsM4jYMU0dmCG0bO SQTmMFObt9hmqJASOn8m1VaDFXtfOpL7WvDeKRy3fgCk9rbZ/qqGbgBjQ32ayJiOVG2B QRfQ== X-Received: by 10.204.113.78 with SMTP id z14mr12522472bkp.44.1370601093762; Fri, 07 Jun 2013 03:31:33 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id iy11sm30153983bkb.11.2013.06.07.03.31.31 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 07 Jun 2013 03:31:32 -0700 (PDT) Sender: Mikolaj Golub Date: Fri, 7 Jun 2013 13:31:30 +0300 From: Mikolaj Golub To: Nikos Vassiliadis Subject: Re: lagg panic Message-ID: <20130607103129.GC10459@gmail.com> References: <5118E5C1.2000809@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5118E5C1.2000809@gmx.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Marko Zec , freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 10:31:35 -0000 On Mon, Feb 11, 2013 at 02:36:17PM +0200, Nikos Vassiliadis wrote: > Hi, > > I just noticed this is not committed. Could somebody commit it? > > http://lists.freebsd.org/pipermail/freebsd-net/2011-November/030526.html > Committed (r251490). Thanks. -- Mikolaj Golub