I am frequently asked to help people setup virtual machines. One of the most common questions is about how to setup networking properly, so I thought I’d share that information here.
Virtual machines have a variety of networking setups available. In addition there are also many options for the underlying OS, such as Windows, OSX, or Linux. Before you can make real use of a virtual machine, it will be necessary to make sure that you have a proper IP address. Enterprise deployments should be on a dedicated hypervisor, such as vSphere / ESXi from VMware, VirtualBox, Hyper-V, etc. For them you setup networking as you would any other machine.
The VMcan use either a static IP address or DHCP. By default virtual machines are often preset for DHCP or dynamic setup. If you want to use a static address you will need to set it to an appropriate value. For more details on linux networking, check the Ubuntu Network Configuration guide.
Desktop VM Network Configuration
VMware provides three types of networking configurations: Nat, Bridged, and Private or host-only. I expect most desktop hypervisors to have similar options.
NAT means that the VM is running on a private network confined to the host machine. It can see external machines, but is generally unavailable to other machines on the network – they cannot see it. The IP address for the VM is supplied from the VM server itself, using DHCP. This setup is well suited to normal, personal use or a demo, but is usually inappropriate for an actual deployment.
Bridged lets your virtual machine share the network adapter from the host machine. In
this setup, your machine gets a “normal” IP address on your network. Typically this
is something like DHCP, and may require you to give the MAC address of the VM to your system administrator. This is a good setup if you need others to be able to access the VM. You can find your MAC address by following the instructions above under “Getting the MAC address”. If you know the correct range of IP addresses, you can also assign a fixed address this way, but you’ll need to have all the necessary information for a static network configuration.
Host-only mode lets your VMONLY see your host machine. The VM has no access to
the network or the world at large. This is ok for certain demos, but not useful for general purpose use. It is very secure.
You can find your network address and mac address either by using the ifconfig command from a prompt for linux, (described above under “Getting the MAC address”), or from the user menu when logged in you can select “System – Preferences – Network Connections”. For windows you can using the ipconfig command or right-click your networking icon.
Getting the MAC address
If you want to use DHCP for the address, you will probably need to give the MAC address for the VM to your system administrator. Some networks may require the MAC address for any access at all. From the VM terminal (see “logging in” for details) you can run the command: “ifconfig”. You will see two or more entries. One is “lo” which is for the loopback and can be ignored. The other should be eth followed by some number, such as eth1 or eth2. Take note of this value as you will use it later on in the configuration. On the same line as the ethx you should see a label that says “HWaddr” – the value following that label is your mac address for that network interface.
If there are others tricks you know, please share them. If there are other topics you’d like me to cover, let me know.
These days everyone it seems like everyone has their head in the cloud. At least from an interest level that is. When it comes to actually using the cloud, they’re not necessarily ready for a real cloud deployment. The conversation usually goes something like this:“Do you support cloud?”
“Sure, what did you have in mind?”
“We don’t know, but we know we want to do cloud at some point. Can you make your tools available to us in the cloud?”
“Yes, I can, what model do you want to use and will fit your security needs?”
“We can’t actually open our firewall, and we can’t share our source code outside the network. Maybe a private cloud…”
And it goes on from there. I’ve played this script over and over again. Lots of intellectual interest in cloud, but without any real understanding of both the issues involved as well as the benefits. Why on earth would you be switching to the cloud if you didn’t have some idea of what it was going to do for you? And yet people do it all the time.
Perhaps they are simply falling for the hype – cloud providers are claiming lower start-up costs, less overhead, better scalability and reliability, streamlined process, and cures for cancer. OK, I made that last one up, but it’s close. Seriously, a commenter to my piece on What Went Wrong with Static Analysis? said that all the potential pitfalls of static analysis are avoided if you simply use the cloud. As you’ve probably guessed, he worked at a company providing cloud services.
I don’t want to dive into a detailed list of what cloud can and cannot do at this point, although I may at a later date. But I do want to caution people to at least think about it. If someone says that the cloud will make your life better, ask them to explain how. If it makes sense, great. If not, beware of snake oil.
With that in mind, I want to talk about something that actually will make your life easier, namely a special kind of private cloud called micro cloud. This is an especially useful tool for software development that can make your life easier.
It’s not secret that I’m a VMware (VMW) fan. One of the aspects I like best is that it’s well suited for extreme scalability. You can start with desktop use, like running an alternate OS on your machine without having to reboot. Then you can push that onto an ESXi box in your server room when the virtual machine you were using unexpectedly becomes something useful you actually depend on. And ultimately you can push it off into the cloud as needed and scale it up as needed.
This is where the connection to software development comes in. One of the tedious pieces of getting a software project up and running is setting up the infrastructure. This is known as Application Lifecycle Management, or ALM. You need to have quite a few different goodies available, and while none of them are super complicated, it takes time to put the whole thing together. And then at some point you realize you either need another one, and have to do it again, or the one you have is tool small/slow for the team as the project has grown.
The list of necessary tools includes things like requirements management, project management, source control, compilers, development IDE, build management, continuous integration, testing, reporting, static analysis, code coverage, etc. Each of the items isn’t the complicated by itself. Putting them all together just takes more time than it should. In addition, it turns out the software developers really aren’t the best choice for system administrators, and don’t always deploy infrastructure in the way that you want. This is an excellent fit for virtualization.
Instead of putting together your software in an ad hoc way that has a tendency to grow like Frankenstein’s monster (come on, we know it happens to all of us) you can plan and coordinate between developers, architects, managers, and sysadmins. Figure out what kind of tools you’re going to need all the time, layout the requirements for them, and get the admin guys to build you up a virtual machine that has everything you want. Then test it, fix it, and from then on you can use use it over and over again.
Do it on a virtual machine rather than a physical one, that way when you need a new one for a new project, you can just stand up a new instance of the virtual machine. When you outgrow your hardware, scale it up on the back-end in the hypervisor. If you need to share geographically push it out to a cloud provider or data center.
You can use one that someone else has already built. If you have a small project and you don’t have security issues that preclude you putting your code outside your own firewall, there are a couple of pure cloud plays that have pretty much what you need. For example you could go to GitHub and use their tools. Or you can check out Cloud Foundry, which also uses Git as a source control system.
If you can’t put your source in the cloud for whatever reason, or if Git isn’t your cup of tea, then you should look for a micro cloud instead. This is a virtual machine pre-built that you can use on a desktop, or in your own server room or even scale it up to your datacenter. Again, you could do all this yourself, but if you can find one that has what you need, you can save a lot of time.
As a reminder, I work for Parasoft, a company that make a variety of tools for software development, including an ALMvirtual machine suitable for micro cloud. This is however my personal blog, and everything said here is my personal opinion and in no way the view or opinion of Parasoft or possibly anyone else at all.
With that behind me, let me relate a personal story. I was working on a personal project at home and wanted to setup a source control system. I happen to be an SVN guy, so I normally setup a subversion server and then use Apache to access it. The SVN install is quick and easy. Apache isn’t too difficult, but by the time you get HTTPS up and running with certificates and the WebDAVSVN connector going it can be difficult. Add to that the normal scenario that you don’t do it very often and it’s easy to forget the little things that will trip you up during setup. Need to say, I wasn’t looking forward to setting the darn thing up.
I started with using a VM like I always do, and as I was adding Apache and SVN to it, I got a feeling of deja vu. I knew of course that I had done it before, many times. Then I figured out why the deja vu. I helped create the VM for Parasoft that just happened to have everything I needed in it. So I download that VM, started it up on my desktop, and set the configuration for what I needed. Other than download time, total setup and configuration was about 20 minutes. Total time and frustration saved: a lot.
Micro cloud is a great way to not only handle your development infrastructure, you can also do tech support on specific environments, setup complicated QA, provide quick POC projects etc. This is one of the cases where it’s easy to see how cloud helps – it not only drastically reduces start-up time and costs, but leaves you in good shape to scale quickly and efficiently.
If there are clouds in your forecast, micro cloud might be the place to start.