....or at least clearly indicate what hardware is and is not VT-d (or AMD version) capable. Trying to find out what motherboard/CPU combo will actually work in white box form is like trying to pin the tail on the donkey blind folded.
Here's an example of where virtualization on the desktop may take place;
If I'm on the road with my laptop, I can get wireless internet access in hotel rooms but I'd also like to connect my mobile phone with a PBX. I can tether my phone with my laptop and have the phone route its traffic through the laptop. If the phone traffic is routed straight through the laptop then I may run into issues with SIP connections combined with NAT. Sometimes, I can establish a VPN connection with a backend server and have the phone traffic go through the VPN connection.
More often than not, I'd like to have my laptop connected with several PBX servers allowing the phone to be reachable from all PBXs (and vice versa).
Virtualization is not necessarily required, but I currently just run an Asterisk (Trixbox) PBX server in a virtual machine on the laptop. I wouldn't want to install all this software straight onto the laptop('s host), which is running Linux btw. Now the phone is tethered with the laptop and establishes a SIP connection with the (local) Asterisk PBX. Asterisk allows multiple trunk connections to other PBXs and additionally provides IAX which has less trouble with NAT connections.
Following this, combined with frustrating experiences with SIP proxies and the like, I now have an Asterisk PBX running as a (KVM) virtual machine on most of my desktops at various locations. These are desktops which otherwise don't have a local server available (which would then by the place to run the Asterisk server).
But, as you pointed out, you don't need virtualization in your scenario; a simple VPN would work fine, even for connecting to multiple PBX servers (the typical road-warrior scenario for VPN usage uses the VPN as the gateway, so *all* internet traffic flows through it, secure over the untrusted segment (the hotel, the cell network, etc)).
Virtualization is a great technology, but it's still not a magic powder that should be sprinkled on all problems. If a solution other than virtualization exists that is simpler, faster, and cheaper, then virtualization probably isn't the right solution to the problem.
In your case, you'd still need to run through a VPN, since your trunk connections from your virtualized copy of Asterix is still going over the untrusted connection.
Well, as I pointed out, I already use a VPN in order to route the (SIP) phone traffic with the PBX. I may have not made it clear that it's more desirable to have the phone connect with a local PBX (running as a VM on the laptop) than having the phone connect with a remote PBX.
Moreover, it's preferable for me for the phone to make one SIP connection and have Asterisk deal with subsequent connections than having the phone make multiple connections (which I haven't even tried). Additionally, I already have the VPN software running together on the Asterisk VM so using the local PBX is more or less transparent once the phone is tethered with the laptop.
I didn't mention this, but having this PBX-in-a-box is really fruitful. Although I may able to setup Asterisk on a Linux host and run a PBX without virtualization, once the PBX is running by itself I can easily transfer/port this setup to other hosts which inherently are not Asterisk friendly.
Instead of having to deal with PBX, VPN and related stuff for Windows, Linux and Mac OS, I just focus on getting the virtualized PBX running (as a guest) on a particular host and the rest follows automatically. I wouldn't want to configure someone's IP phone setup on a Mac book, but with a virtualized PBX, I don't have to know about the particulars of a specific platform, just how its hypervisor starts/stops the PBX and how the hypervisor provides (virtual) network connections in relation to the host.
If your company has certain policies on how remote clients connect (specific VPN software), how the PBX is accessed etc., then deploying a PBX-as-a-guest or even a corporate-image-as-a-guest can make things a whole lot easier.
One can generalise this to a lot of software that's specific for a given company, has specific run time characteristics and is otherwise sensitive to host settings or is limited to running on a particular platform.
In question #1, the answer said to have at least two gigabit ports. That's fine for test & dev use or home use, but for production/enterprise use, I would definitely shoot for at least 4 - more if you need to segregate traffic. Commingling both management traffic for your hypervisor and production traffic for your virtual machines can be considered bad practice in security perspective, and you might end up having your security team raise a red flag.
While you can segregate management and production traffic by means of VLANs, and even reduce the number of links required by utilizing 802.1Q trunk, there are still many attacks that can hop between VLANs. Physical separation is still the best way to separate traffic (if not always necessary) and for that, you will need more links and thus, more NICs. Check with your security team!
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
8 Comments
Back to Article
chukked - Friday, September 10, 2010 - link
Why intel can not add VT-d, VT-c support on its multimedia series of boards? (added cost is ok).:(
najames - Thursday, September 16, 2010 - link
....or at least clearly indicate what hardware is and is not VT-d (or AMD version) capable. Trying to find out what motherboard/CPU combo will actually work in white box form is like trying to pin the tail on the donkey blind folded.Finite Loop - Friday, September 10, 2010 - link
Here's an example of where virtualization on the desktop may take place;If I'm on the road with my laptop, I can get wireless internet access in hotel rooms but I'd also like to connect my mobile phone with a PBX. I can tether my phone with my laptop and have the phone route its traffic through the laptop. If the phone traffic is routed straight through the laptop then I may run into issues with SIP connections combined with NAT. Sometimes, I can establish a VPN connection with a backend server and have the phone traffic go through the VPN connection.
More often than not, I'd like to have my laptop connected with several PBX servers allowing the phone to be reachable from all PBXs (and vice versa).
Virtualization is not necessarily required, but I currently just run an Asterisk (Trixbox) PBX server in a virtual machine on the laptop. I wouldn't want to install all this software straight onto the laptop('s host), which is running Linux btw. Now the phone is tethered with the laptop and establishes a SIP connection with the (local) Asterisk PBX. Asterisk allows multiple trunk connections to other PBXs and additionally provides IAX which has less trouble with NAT connections.
Following this, combined with frustrating experiences with SIP proxies and the like, I now have an Asterisk PBX running as a (KVM) virtual machine on most of my desktops at various locations. These are desktops which otherwise don't have a local server available (which would then by the place to run the Asterisk server).
Guspaz - Friday, September 10, 2010 - link
But, as you pointed out, you don't need virtualization in your scenario; a simple VPN would work fine, even for connecting to multiple PBX servers (the typical road-warrior scenario for VPN usage uses the VPN as the gateway, so *all* internet traffic flows through it, secure over the untrusted segment (the hotel, the cell network, etc)).Virtualization is a great technology, but it's still not a magic powder that should be sprinkled on all problems. If a solution other than virtualization exists that is simpler, faster, and cheaper, then virtualization probably isn't the right solution to the problem.
In your case, you'd still need to run through a VPN, since your trunk connections from your virtualized copy of Asterix is still going over the untrusted connection.
Finite Loop - Friday, September 10, 2010 - link
Well, as I pointed out, I already use a VPN in order to route the (SIP) phone traffic with the PBX. I may have not made it clear that it's more desirable to have the phone connect with a local PBX (running as a VM on the laptop) than having the phone connect with a remote PBX.Moreover, it's preferable for me for the phone to make one SIP connection and have Asterisk deal with subsequent connections than having the phone make multiple connections (which I haven't even tried). Additionally, I already have the VPN software running together on the Asterisk VM so using the local PBX is more or less transparent once the phone is tethered with the laptop.
Finite Loop - Saturday, September 11, 2010 - link
I didn't mention this, but having this PBX-in-a-box is really fruitful. Although I may able to setup Asterisk on a Linux host and run a PBX without virtualization, once the PBX is running by itself I can easily transfer/port this setup to other hosts which inherently are not Asterisk friendly.Instead of having to deal with PBX, VPN and related stuff for Windows, Linux and Mac OS, I just focus on getting the virtualized PBX running (as a guest) on a particular host and the rest follows automatically. I wouldn't want to configure someone's IP phone setup on a Mac book, but with a virtualized PBX, I don't have to know about the particulars of a specific platform, just how its hypervisor starts/stops the PBX and how the hypervisor provides (virtual) network connections in relation to the host.
If your company has certain policies on how remote clients connect (specific VPN software), how the PBX is accessed etc., then deploying a PBX-as-a-guest or even a corporate-image-as-a-guest can make things a whole lot easier.
One can generalise this to a lot of software that's specific for a given company, has specific run time characteristics and is otherwise sensitive to host settings or is limited to running on a particular platform.
mmatis - Friday, September 10, 2010 - link
but who won the HD 5770s in your Anniversary giveaway?solgae1784 - Friday, September 10, 2010 - link
In question #1, the answer said to have at least two gigabit ports. That's fine for test & dev use or home use, but for production/enterprise use, I would definitely shoot for at least 4 - more if you need to segregate traffic. Commingling both management traffic for your hypervisor and production traffic for your virtual machines can be considered bad practice in security perspective, and you might end up having your security team raise a red flag.While you can segregate management and production traffic by means of VLANs, and even reduce the number of links required by utilizing 802.1Q trunk, there are still many attacks that can hop between VLANs. Physical separation is still the best way to separate traffic (if not always necessary) and for that, you will need more links and thus, more NICs. Check with your security team!