VT-d Required for pfSense in Hypervisor?
-
Hi,
I have a problem with one host where I cannot enable VT-d in a XenServer environment. I'm wondering if pfSense requires this to run effectively.
I tried running XenServer 6.5 on this particular host (special edition Proliant DL180 G6), and pfSense ran terribly on it, whereas it ran fine on another very similar host that had VT-d enabled. The problem is not related to checksumming, as I fixed this on both.
So, any thoughts on VT-d and pfSense?
Thanks
-
not necessary, but far more secure. i would use hyper v or vmware instead of xen
-
@tyh:
So, any thoughts on
VT-dXen and pfSense?afaik you don't want to use xen if you want performance. esxi is your best bet.
https://forum.pfsense.org/index.php?topic=88467.0
https://forum.pfsense.org/index.php?topic=121579 -
@tyh:
So, any thoughts on
VT-dXen and pfSense?afaik you don't want to use xen if you want performance. esxi is your best bet.
https://forum.pfsense.org/index.php?topic=88467.0
https://forum.pfsense.org/index.php?topic=121579Xen works perfectly fine. Cant replicate the performance on ESX, KVM or Hyper-V for that matter. Sure, don't muddle with weird virtual interfaces, otherwise it's fine.
Regarding VT-d: you don't need it to run it, but you will need it to run it well. That goes for any hypervisor. I'd suggest not doing anything production-type without VT-d. If you want good performance, SR-IOV or VT-d passthrough is the best way. For virtual networking, you can do with any virtual networking system since it basically doesn't care about the layer 0/1 transport.
-
If you want security you need IOMMU SR-IOV passed through network interfaces, involving the host netcode is a bad idea for a variety of reasons.
-
If you want security you need IOMMU SR-IOV passed through network interfaces, involving the host netcode is a bad idea for a variety of reasons.
Second that. Basically, anything that can be done in the IOMMU and IO virt is not only more performant but also more secure. With Xen you have a control domain and optionally driver/device domains, with ESX and Hyper-V, all the control code is in the same management level. In both cases, however, not using VT-x, and VT-d is less secure. With only VT-x (IOMMU without device support) you can have a secure setup with Xen as far as device isolation goes using device/driver domains and Flask/XSM, but that's about as good as you're going to get without VT-d.
Basically, if you're not getting VT-d capable hardware, you're not going to get secure virtualisation either if you need the VM's to talk to the world. If it's a virtual-only system, VT-x might be enough. Anything less and you might as well just use containers instead…
-
@johnkeates:
If you want security you need IOMMU SR-IOV passed through network interfaces, involving the host netcode is a bad idea for a variety of reasons.
Second that. Basically, anything that can be done in the IOMMU and IO virt is not only more performant but also more secure. With Xen you have a control domain and optionally driver/device domains, with ESX and Hyper-V, all the control code is in the same management level. In both cases, however, not using VT-x, and VT-d is less secure. With only VT-x (IOMMU without device support) you can have a secure setup with Xen as far as device isolation goes using device/driver domains and Flask/XSM, but that's about as good as you're going to get without VT-d.
Basically, if you're not getting VT-d capable hardware, you're not going to get secure virtualisation either if you need the VM's to talk to the world. If it's a virtual-only system, VT-x might be enough. Anything less and you might as well just use containers instead…
https://en.wikipedia.org/wiki/X86_virtualization#Intel_virtualization_.28VT-x.29
VT-x is intels marketing name for VMX, hardware virtualization for cpus, not IOMMU, which "without device support" (device assignment) would simply be a device to remap RAM addresses for larger address spaces - it has nothing to do with virtualization, and these days referring to IOMMU means referring to the type that has device assignment support.Driver domains are impossible without IOMMU device assignment.
If you want driver domains in hyperv or whatever you can easily do that with the windows routing tools, but then you're still involving the netcode, it would be better to have a remapping aware guest that enables DMA protection for its assigned device.
So that everyone knows AMD's marketing name for IOMMU is AMD-Vi.
-
@johnkeates:
If you want security you need IOMMU SR-IOV passed through network interfaces, involving the host netcode is a bad idea for a variety of reasons.
Second that. Basically, anything that can be done in the IOMMU and IO virt is not only more performant but also more secure. With Xen you have a control domain and optionally driver/device domains, with ESX and Hyper-V, all the control code is in the same management level. In both cases, however, not using VT-x, and VT-d is less secure. With only VT-x (IOMMU without device support) you can have a secure setup with Xen as far as device isolation goes using device/driver domains and Flask/XSM, but that's about as good as you're going to get without VT-d.
Basically, if you're not getting VT-d capable hardware, you're not going to get secure virtualisation either if you need the VM's to talk to the world. If it's a virtual-only system, VT-x might be enough. Anything less and you might as well just use containers instead…
https://en.wikipedia.org/wiki/X86_virtualization#Intel_virtualization_.28VT-x.29
VT-x is intels marketing name for VMX, hardware virtualization for cpus, not IOMMU, which "without device support" (device assignment) would simply be a device to remap RAM addresses for larger address spaces - it has nothing to do with virtualization, and these days referring to IOMMU means referring to the type that has device assignment support.Driver domains are impossible without IOMMU device assignment.
If you want driver domains in hyperv or whatever you can easily do that with the windows routing tools, but then you're still involving the netcode, it would be better to have a remapping aware guest that enables DMA protection for its assigned device.
So that everyone knows AMD's marketing name for IOMMU is AMD-Vi.
I thought AMD called it's VT-x Pacifia, and Intel called it Vanderpool Technology. Anyway: it comes down to what you said: IOMMU is virtualisation for everything that is not the CPU, VT-x (or, VMX) is for the CPU. Without VMX, you'd have slow virtualisation. VMX, VT-x, Vi, it doesn't matter, what matters is that it's the lowest you can go without falling back to full virtualisation a la QEMU. Sure, x86-on-x86 still reasonable since it won't need translation like PPC-on-x86 or ARM-on-PPC would need for example.
You can still virtualise without all of those, emulation still makes for a virtual environment, it just won't be very useable or secure ;-)
But as far as this topic goes: unless you want to do strange hobby research, you'll need hardware and firmware that does IOMMU.
-
Or you could do paravirt.