Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    [HowTo] Install pfSense 2.1 RC0 amd64 on Xen 4.3 as PV HVM

    Scheduled Pinned Locked Moved Virtualization
    19 Posts 5 Posters 17.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • ?
      A Former User
      last edited by

      Thanks for posting the howto Sabrewarrior!

      I'm still trying to get a paravirt kernel built and working, but as a fall back, PVHVM will still make a huge difference to cpu usage (I have NAS4free running PVHVM with my LSI card - the difference between emulated e1000 and xen network driver is huge).

      1 Reply Last reply Reply Quote 0
      • ?
        A Former User
        last edited by

        Great, the howto worked for me, building 2-1 on BSD 8.3, many thanks!

        The only gotcha I encoutnered was that the iso image didn't build - a quick look at the logs and it turns out that I needed to install the cdrtools package.

        cd /usr/ports/sysutils/cdrtools && make depends install
        

        After that the iso image built just fine, and I was able to install from the iso image using a simple HVM xen config, with the extra line "pty='serial'" so that I could use the xen console to do the install.

        In the console text during boot I saw this, confirming its running in PVHVM mode:

        xenbusb_front0: <xen frontend="" devices="">on xenstore0
        xenbusb_add_device: Device device/suspend/event-channel ignored. State 6
        xn0: <virtual network="" interface="">at device/vif/0 on xenbusb_front0
        xenbusb_back0: <xen backend="" devices="">on xenstore0
        xctrl0: <xen control="" device="">on xenstore0
        GEOM: ad0s1: geometry does not match label (255h,63s != 16h,63s).
        xn0: backend features: feature-sg feature-gso-tcp4
        xbd0: 5120MB <virtual block="" device="">at device/vbd/51712 on xenbusb_front0
        SMP: AP CPU #1 Launched!
        Root mount waiting for: usbus0</virtual></xen></xen></virtual></xen> 
        

        I did notice that its still got the re0 device (HVM emulated realtek) showing up alongside the xn0 one, so I'll need to disable that in rc.local.

        I also just did PCI passthrough for an Intel 82574L Gigabit ethernet card (dedicated NIC is for WAN connection, on separate physical subnet - I'm using the Xen network interface xn0 for internal LAN), although I haven't done more than boot the VM with the PCI device at this stage (it let me configure it).

        Now I've got a working install, I'll have a play with making a paravirt domU, although in my experience paravirt performance is largely the same as PVHVM, with the only difference being the ability to pass through PCI devices without needing IOMMU/VT-d.

        (FYI my dom0 is Centos 6.4 using standard Centos-supported xen-4.2 and kernel-3.4.61)

        1 Reply Last reply Reply Quote 0
        • S
          Sabrewarrior
          last edited by

          That's odd that its showing up twice. I would go over the vm config file or do a brctl show in the Dom0 to see whats going on.

          Blog of my random experiments

          1 Reply Last reply Reply Quote 0
          • ?
            A Former User
            last edited by

            Yes - not sure why its showing up twice.

            Here's the output from bridge control:

            ]# brctl show
            bridge name    bridge id              STP enabled    interfaces
            xenbr0          8000.0025900d41b6      no              eth0
                                                                    vif1.0
                                                                    vif5.0
                                                                    vif5.0-emu

            The domU config file is pretty simple - nothing out of the ordinary:

            name = 'pfsense21'
            builder = 'hvm'
            memory = 1024
            vcpus=2
            acpi=1
            vif = [ 'bridge=xenbr0, mac=00:16:3e:14:01:97' ]
            disk = [ 'phy:/dev/vg_ssd/pfsense21,xvda,w' ]
            boot='c'
            serial='pty'
            pci = [ '0000:05:00.0' ]

            An ifconfig on the domU shows  both the xn0 and re0 interfaces (along with others including the pci-passthrough Intel em0 one:

            re0: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
                    options=9b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:16:3e:14:01:97
                    media: Ethernet autoselect (100baseTX <full-duplex,flowcontrol,rxpause,txpause>)
                    status: active
            xn0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                    options=3 <rxcsum,txcsum>ether 00:16:3e:14:01:97
                    inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255
                    inet6 fe80::216:3eff:fe14:197%xn0 prefixlen 64 scopeid 0x8
                    nd6 options=1 <performnud>media: Ethernet manual
                    status: active

            Note in the above, both interfaces have the same MAC address.  Interestingly, a check on the dom0 shows:

            ~]# xl network-list pfsense21
            Idx BE Mac Addr.        handle state evt-ch  tx-/rx-ring-ref BE-path
            0  0  00:16:3e:14:01:97    0    4      7  769/770        /local/domain/0/backend/vif/5/0

            I'd leave it alone, except that I have an issue with networking which seems to be affecting some network traffic via random high latency.  First thing to try is rebuilding my PVHVM kernel with a clean build environment.</performnud></rxcsum,txcsum></up,broadcast,running,simplex,multicast></full-duplex,flowcontrol,rxpause,txpause></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum></broadcast,simplex,multicast>

            1 Reply Last reply Reply Quote 0
            • ?
              A Former User
              last edited by

              I also just switched the active LAN device to the re0 one.. it appears to work:

              re0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                      options=9b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:16:3e:14:01:97
                      inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255
                      inet6 fe80::216:3eff:fe14:197%re0 prefixlen 64 scopeid 0x1
                      nd6 options=1 <performnud>media: Ethernet autoselect (100baseTX <full-duplex>)
                      status: active
              xn0: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
                      options=503 <rxcsum,txcsum,tso4,lro>ether 00:16:3e:14:01:97
                      media: Ethernet manual
                      status: active

              Definitely time to try rebuilding my kernel and see how it goes :)</rxcsum,txcsum,tso4,lro></broadcast,simplex,multicast></full-duplex></performnud></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,simplex,multicast>

              1 Reply Last reply Reply Quote 0
              • ?
                A Former User
                last edited by

                @Sabrewarrior:

                Hello Ren22, theres a difference between PVHVM and PV. I haven't tried to make a pure i386 PV pfSense. I can upload an amd64 PVHVM iso of the 2.1 Release later on today though.

                Hi Sabrewarrior - any chance you could upload the PVHVM amd64 image?  And ideally, the contents of your "conf/kernels" directory?

                I built the i386 32-bit pfSense iso ok and it boots PVHVM, but as noted it has both the re0 and xn0 interfaces - I checked a vanilla XENHVM freeBSD8.3 kernel and it has the same symptoms and appears to be a bug in the 32-bit HVM code, so I decided to have a go at a 64-bit kernel seeing as how you've had success at it.

                I built a vanilla amd64 freeBSD8.3 kernel, and it works just fine without duplicate network interfaces, so I figured a pfSense kernel should be easy.  However, I'm getting a Fatal trap 12 error booting the pfSense XENHVM kernel - which means there has to be an issue in the pfSense code somewhere, unless there's something I'm missing in the options/devices.

                If you could post/upload your amd64 PVHVM iso for me to try, it'll at least give me an indication whether the issue is my build process, or whether it doesn't like my hardware combo (Supermicro X8SIL and Xeon X3450 cpu).

                Any help appreciated - its getting frustrating after about 8 iso builds in the last 24 hours!

                1 Reply Last reply Reply Quote 0
                • S
                  Sabrewarrior
                  last edited by

                  Hello xlot,
                  Sorry for the delay. I am honestly at a loss to explain the 2 interfaces since brctl is only showing 1 interface being shared, assuming vif1.0 is for a different DomU. Also both your interfaces seem to have the same mac address which is a very bad thing and might be the cause of your high latency.

                  As promised I have uploaded the amd64 PVHVM image to my blog which is in my signature (don't worry no ads!). I have attached the config file I used here though. My sever is running AMD not Intel. I have not tested this image so let me know how it works. I will be working on a 32 bit PV image now.

                  pfSense_SMP.8.txt

                  Blog of my random experiments

                  1 Reply Last reply Reply Quote 0
                  • ?
                    A Former User
                    last edited by

                    Many thanks!  The dual-interface problem appears to be something to do with the xenpci driver for the i386 platform.

                    As suspected, your kernel conf file is identical to one of the variations I've tried (note - the same outcome can be achieved by just replacing the import statement to use the "XENHVM" bsd kernel conf instead of "GENERIC" - saves adding the extra lines).

                    I just downloaded your image and will have a try and report back here.  Thanks for your help - using a known-good build will tell me whether the problem lies with my hardware combo, or possibly dom0 (I'm suddenly wondering as I type this whether I should try the old xm toolset using xend, instead of the newer xl/xenstored one).

                    1 Reply Last reply Reply Quote 0
                    • ?
                      A Former User
                      last edited by

                      Ok, your image gives the same error I've been getting on the 64-bit platform.  The trace shows that its the same problem as found here:

                      http://lists.freebsd.org/pipermail/freebsd-xen/2013-June/001613.html  which in turn links to this post that includes a patch:

                      http://lists.freebsd.org/pipermail/freebsd-xen/2012-September/001359.html

                      Here's my trace.  Its the same issue and looks like it might be a problem with xenstored on my dom0 (xen-4.2.3 on kernel  3.4.61 - stock centos packages).

                      
                      Fatal trap 12: page fault while in kernel mode
                      cpuid = 0; apic id = 00
                      fault virtual address   = 0xffffff010294c2ef
                      fault code              = supervisor write data, page not present
                      instruction pointer     = 0x20:0xffffffff80a56a68
                      stack pointer           = 0x28:0xffffffff816b19f0
                      frame pointer           = 0x28:0xffffffff816b1a30
                      code segment            = base 0x0, limit 0xfffff, type 0x1b
                                              = DPL 0, pres 1, long 1, def32 0, gran 1
                      processor eflags        = trace trap, interrupt enabled, resume, IOPL = 0
                      current process         = 0 (swapper)
                      
                      
                      1 Reply Last reply Reply Quote 0
                      • ?
                        A Former User
                        last edited by

                        I just posted to the Development section - patching the xenstore.c file with the fix found on the freebsd-xen mailing list has worked and I've got a pfSense VM running using the Xen-native block device drivers (xn0 and xbd0).

                        Info here:

                        http://forum.pfsense.org/index.php/topic,69546.0.html

                        Thanks for your help sabrewarrior.

                        Incidentally, it seems that there's a problem with my pci-passthrough of an Intel Corporation 82574L NIC - I was getting irq errors and the interface wasn't working, but that was fixed by forcing use of MSI interrupts rather than MSIX, by adding these lines to loader.conf:

                        
                        hw.pci.enable_msi=1
                        hw.pci.enable_msix=0
                        
                        

                        So finally, I've got it all working as wanted, and I can start to actually test the new setup.. woohoo!

                        1 Reply Last reply Reply Quote 0
                        • S
                          Sabrewarrior
                          last edited by

                          Yeah, I am using ubuntu with xen 4.3 so that might be one of the patches that fixes your problem. I get irq errors with my vr interface, I wonder if its a related problem to MSI interrupts.

                          Blog of my random experiments

                          1 Reply Last reply Reply Quote 0
                          • S
                            Sabrewarrior
                            last edited by

                            Well never thought that I could make a pure PV work but after some ridiculous amount of time spent, I have managed to get a working pfSense i386 PV iso. I am gonna make another one with a bit more clean up to make it straightforward and documentation so I can post the how to.

                            Issues so far:
                            SMP is broken. If you use more than 1 vcpu it will not work. Issue is with FreeBSD Xen drivers again. First function that gives an error can be found in src under sys/xen/interface/xen.h at line 80: #define __HYPERVISOR_vcpu_op              24

                            It gives the following panic at vcpu=2:
                            SMP: Added CPU 0 (BSP)
                            SMP: Added CPU 1 (AP)
                            gdtpfn=83ec38 pdptpfn=89c17
                            panic: HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, &ctxt): /usr/pfSensesrc/src/sys/i386/xen/mp_machdep.c:930
                            cpuid = 0
                            KDB: enter: panic

                            Blog of my random experiments

                            1 Reply Last reply Reply Quote 0
                            • ?
                              A Former User
                              last edited by

                              I posted some info before in another thread here:

                              http://forum.pfsense.org/index.php/topic,67866.msg375470.html#msg375470

                              The problems with pure-PV on freeBSD are described here on a post from the freebsd-xen list:

                              http://freebsd.1045724.n5.nabble.com/Paravirt-domU-and-PCI-Passthrough-td5858307.html

                              IIRC, there's also a memory limit for PV on i386 - various old posts on the freebsd-xen list mentioned somewhere around 700 megs.

                              I've been running pfSense as my gateway for a week for one small subnet - and working through reading docs.. PVHVM is seeming workable (I need PCI passthrough - I prefer to run the pfSense VM with a separate physical NIC/subnet for the external interface.

                              1 Reply Last reply Reply Quote 0
                              • A
                                archedraft
                                last edited by

                                Would you mind posting the contents of you pfsense.cfg file?

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post
                                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.