VMware player has some well-known issues with setting up the network for player under Ubuntu 12.04 (that is, where Ubuntu is the host OS).
With one small change, I followed the great instructions here: http://www.kartook.com/2012/05/vmware-virtual-network-device-unable-to-loadcompile-vm-player-4-0-2-in-ubuntu-12-04/
The change is that the script you download has the recognised version numbers hardcoded in the header.
Before you run the script (patch-modules_3.2.0.sh), open the file using your preferred text editor, and change the 4.0.2 to 4.0.3, so it looks like:
plreqver=4.0.3
The script (and VMware player) seems to run fine for VMware Player 4.0.3 on Ubuntu 12.04. If it should make a difference, I'm running x86_64 Ubuntu 12.04.
Showing posts with label vmware. Show all posts
Showing posts with label vmware. Show all posts
Tuesday, May 22, 2012
Monday, June 20, 2011
How to build a (modern) Windows Server
http://jeremywaldrop.wordpress.com/2008/10/28/how-to-build-a-windows-2008-vmware-esx-vm-template/
Excellent. I think some of the decisions are little odd (turn off the firewall?!?), but this covers a lot of ground.
Excellent. I think some of the decisions are little odd (turn off the firewall?!?), but this covers a lot of ground.
Tuesday, February 08, 2011
The cloud - public, private, and the appliances within
I talked to a sales guy the other day, one of the better ones. Not only was he forthcoming, helpful, and charming, he was knowledgable and experienced; a rare breed. I had been out of this vendor's loop for a bit and asked what was going on; he mentioned all kinds of things he thought I'd be interested in, including a big cloud push for the vendor's software. Great. I segued into software appliances and he told me they were dead. Not limping, not re-purposed - DEAD.
From a techie's point of view (which is, to be fair, not the same as a salesman's) I see these as points along a continuum, or at least pre-requisite. "The Cloud" is all about ecomomies of scale, and industrialisation of information technology. In order to achieve the desired outcomes from The Cloud, standardisation and mechanisation are pre-requisites. A software applicance is a standardised "unit" (when properly built), an abstraction of an underlying mechanisation, it's the thing you want in The Cloud.
Amazon knows this, rPath knows this, VMware knows this, and Google has been doing this implicitly (as have all big web shops) since its inception; but the commentariat seem to have completely missed it, the analysts have missed it, and most of the vendors have missed it. It's a joke.
The Cloud is only a cloud while the hard bits are hidden. When the hard bits start peeking out, The Cloud becomes The Mess. When the hard bits get hidden, you're running someone else's software, on someone else's hardware (or your own - pick a public or private cloud as suits you), and we all become a lot more happier with the result.
The Cloud == Appliances.
From a techie's point of view (which is, to be fair, not the same as a salesman's) I see these as points along a continuum, or at least pre-requisite. "The Cloud" is all about ecomomies of scale, and industrialisation of information technology. In order to achieve the desired outcomes from The Cloud, standardisation and mechanisation are pre-requisites. A software applicance is a standardised "unit" (when properly built), an abstraction of an underlying mechanisation, it's the thing you want in The Cloud.
Amazon knows this, rPath knows this, VMware knows this, and Google has been doing this implicitly (as have all big web shops) since its inception; but the commentariat seem to have completely missed it, the analysts have missed it, and most of the vendors have missed it. It's a joke.
The Cloud is only a cloud while the hard bits are hidden. When the hard bits start peeking out, The Cloud becomes The Mess. When the hard bits get hidden, you're running someone else's software, on someone else's hardware (or your own - pick a public or private cloud as suits you), and we all become a lot more happier with the result.
The Cloud == Appliances.
Wednesday, June 30, 2010
Virtualisation and Service Oriented Architecture
I was reading over at the TIBCOmmunity site regarding the impact of virtualisation on architecture
( http://www.tibcommunity.com/blogs/soa-architecture/2009/07/24/virtualization-and-its-affect-on-architecture ). There's some handy information here, but it feels a bit lost under a heading of "SOA architecture"; so I thought I'd have a go, under the heading of "I think...".
Virtualisation is the capability to encapsulate arbitrarily complex environments (by adding yet another layer of abstraction, naturally). Virtualisation is a means of utilising commodity hardware in ways that were previously the preserve of esoteric, expensive, proprietary systems.
What does this mean in the context of SOA?
I think the eventual result is that services can/will be built as software appliances. The moves around OSGi are heading in this direction, allowing a more 'focussed' environment to be built. I'll expand on my view of a software appliance life cycle in a later post.
I do believe that the eventual goal around a SOA (at a technical level) should be something like an AMI virtual machine (the lingua franca of the cloud), with defined "production", and management, services. This could/should be hosted in some cloud (public/private), or combination of clouds. The services/VMs may depend on other defined services (provided in a SaaS, or other, manner). Some overarching management environment will be required to manage the relationships between services (and I believe that this is where VMware is heading, fast).
( http://www.tibcommunity.com/blogs/soa-architecture/2009/07/24/virtualization-and-its-affect-on-architecture ). There's some handy information here, but it feels a bit lost under a heading of "SOA architecture"; so I thought I'd have a go, under the heading of "I think...".
Virtualisation is the capability to encapsulate arbitrarily complex environments (by adding yet another layer of abstraction, naturally). Virtualisation is a means of utilising commodity hardware in ways that were previously the preserve of esoteric, expensive, proprietary systems.
What does this mean in the context of SOA?
I think the eventual result is that services can/will be built as software appliances. The moves around OSGi are heading in this direction, allowing a more 'focussed' environment to be built. I'll expand on my view of a software appliance life cycle in a later post.
I do believe that the eventual goal around a SOA (at a technical level) should be something like an AMI virtual machine (the lingua franca of the cloud), with defined "production", and management, services. This could/should be hosted in some cloud (public/private), or combination of clouds. The services/VMs may depend on other defined services (provided in a SaaS, or other, manner). Some overarching management environment will be required to manage the relationships between services (and I believe that this is where VMware is heading, fast).
Friday, June 06, 2008
Vista and VMWare network irritation
I've been working with VMWare a bit recently, on my machines. As both the machines I use are relatively new, they came with Vista. Vista has been irritating, but less so than a downgrade.
Vista wants to describe and categorize all the network interfaces. Unfortunately, that includes the virtual network adapters that VMWare sets up (and probably the same for Windows qemu users fiddling with openvpn for its TAP implementation); and it gets its knickers in a twist because they don't seem to lead anywhere. The solution for Vista (pre-SP1) was to take advantage of a bug and add bogus default gateways to the virtual interfaces. The solution for Vista SP1 is more involved, but at least seems more "proper".
Essentially, you need to hack the Windows registry and tell Vista that these interfaces aren't leading anywhere. This seems a bit odd, as there may be an extensive network infrastructure of VMs; but that's it.
Use the registry editor of your choice and follow this:
http://communities.vmware.com/message/916766#916766
Vista wants to describe and categorize all the network interfaces. Unfortunately, that includes the virtual network adapters that VMWare sets up (and probably the same for Windows qemu users fiddling with openvpn for its TAP implementation); and it gets its knickers in a twist because they don't seem to lead anywhere. The solution for Vista (pre-SP1) was to take advantage of a bug and add bogus default gateways to the virtual interfaces. The solution for Vista SP1 is more involved, but at least seems more "proper".
Essentially, you need to hack the Windows registry and tell Vista that these interfaces aren't leading anywhere. This seems a bit odd, as there may be an extensive network infrastructure of VMs; but that's it.
Use the registry editor of your choice and follow this:
http://communities.vmware.com/message/916766#916766
Subscribe to:
Posts (Atom)