VMware Communities : All Content - All Communities

VI3: Linux Client, Please

esiebert7625 — Fri, 20 Nov 2009 18:19:13 GMT

Here you go:

Private vExpert meeting with Stephen Herrod: vCenter 4.0 for Linux is coming
At
5:30 p.m., it was off to our private vExpert meet-up hosted by Troyer,
which included a Q&A with Stephen Herrod and presentations by Jason
Boche and Steve Kaplan. I recorded part of this, which you can view here. A couple of interesting things came out of it.

VMware hasn't forgotten about a vCenter Server 4.0 Linux-based
appliance. Developers are actively working on it, and although VMware
wanted to mention something at the keynote about it, the company chose
not to. On the client front, VMware is rearchitecting it and rewriting
it in Adobe Flex (Web-based) and intends to have it available in the
next major release, which means we are unlikely to see a specific Linux
client because a universal Web-based client will be used instead.
Finally, the ESX Service Console is going away for good, and ESX and
ESXi are being united. VMware is working on these things, which may or
may not make the next major release. Apparently, getting the
third-party vendors to adapt is the biggest hurdle.

Eric Siebert
VMware Communities User Moderator
-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-
Author of the upcoming book "VMware VI3 Implementation and Administration" now available on Rough Cuts
Check out my website: VMware-land
Read my virtualization blog: SSV Blog
-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

VDI: Free Connection Broker

Rajeev S — Mon, 05 Oct 2009 14:43:46 GMT

Someone able to create a virtual appliance of this tool? Please share

Community ESX(i) Driver Project

nick.couchman — Wed, 25 Feb 2009 17:39:20 GMT

Well, we've started up a community project on SourceForge.net for adding drivers to ESX/ESXi (see link below). I've got a couple of Wiki pages out there describing how to get things going, and I've checked the code into SVN for the first driver that I ported - the Realtek 8169 Gigabit Ethernet driver. I also have an initial binary download for this driver for anyone who wants to try it out. The download is in the form of a .tgz file that you can add to the boot configuration of your existing ESXi system (see the Wiki for detailed instructions). It has the r8169.o module and an updated simple.map file.

We're looking for people to help in developing and testing these drivers. Check out the project page:

http://www.sourceforge.net/projects/open-vdrivers

http://open-vdrivers.sourceforge.net

GPL Components - Build ESX Drivers?

nick.couchman — Sat, 07 Feb 2009 01:06:36 GMT

There's probably a bit more to it than just patching for sata support. First, the ESX Linux emulation layer is actually based more on the 2.4.21 kernel:

Linux <hostname> 2.4.21-57.ELvmnix #1 Thu Nov 20 13:06:23 PST 2008 i686 i686 i386 GNU/Linux

Second, while I haven't done much with the storage drivers, in my meandering through the network driver code I've noticed quite a few things that have been added/removed for VMKernel support. For example, in the network interface code, when a module is compiled for VMKernel support the occurrences of synchronize_irq() are replaced with vmk_synchronize_irq(). There a few things like this, and in some cases there are a lot more detailed things that need to take place, as well. One of the things we'll be working on in the SF.net project we've just started will be documenting these sorts of changes so that there's a clearer picture of what has to be changed.

Good luck!

ESX(i) Community Driver Project

nick.couchman — Fri, 06 Feb 2009 17:10:49 GMT

(I apologize in advance if this would be more appropriate for the Development forum, but I thought people actually using ESXi and looking for broader hardware support would like to know...)

Hi, everyone,

I'm excited to announce that I've started an Community Driver project for VMware ESX and ESXi. The goal of the project is to port hardware drivers, primarily for storage and network controllers, over to the ESX platform. I've started it out by stumbling my way through porting the Realtek 8169 Gigabit Ethernet driver over to this platform. I'd like to expand out to other drivers to provide a wider range of hardware support for ESX and ESXi, especially since VMware is now licensing ESXi for free.

Just to make sure it's understood, this is a community project, including community support, which means that use of these drivers is not Supported by VMware. The one driver I've ported is still in the very early development stages at this point so you may risk crashing your system if you use it right now. I'm sure that will become a non-issue over time as the drivers get further developed, but you have been warned. Also, aside from the drivers themselves not being supported by VMware, using these drivers may render your entire ESX(i) installation UNSupported by VMware, so use at your own risk.

All that said, I definitely would appreciate help with development, testing, and debugging of the drivers by anyone willing to contribute, and I can use help documenting, too. The drivers are all based on the Linux kernel drivers, so they're written in C. Some of them come from vendors and are modified; some come from the kernel sources. I could also use some help developing Makefiles for the drivers - the GPL Sources that VMware provides have a simple build script that could use some work (sorry VMware, no offense meant) or a good port over to a Makefile build system.

The URL for the Source Forge project is below. As of this post, there is absolutely nothing in the project - I'm just getting going. Over the next few days I hope to get the Realtek 8169 driver code checked into the SVN repository as well as some instructions on building that one. If you'd like me to add you to the project as a contributer, send me a Private Message and let me know - send me your SF.net UNIX username and the type of role you'd like to play in developing the drivers.

Project page is:

https://sourceforge.net/projects/open-vdrivers/

More ESX Drivers!

nick.couchman — Wed, 04 Feb 2009 04:51:01 GMT

Well, I think I've finally got it to work - I've modified the RTL8169 driver to be supported under VMware ESX and ESXi! I'll post the patch here before too long, and I hope this will be the first of many additional ESX drivers to come!

ESXi Software iSCSI Boot

englund — Sat, 31 Jan 2009 07:45:57 GMT

Hey,

have you found any solution for this yet? Perhaps works with the latest U3 update?

How did you install ESXi to the iSCSI in the first place? I can't get the installer to see the target when booting from CD (using "option gpxe.keep-san 1;" in the dhcp config). Did you install to a local disk and copy the partitions or did you dig out the install manually from the iso?

Best regards,
Johan

Problem with ESXi Forum

RDPetruska — Fri, 02 Jan 2009 15:35:55 GMT

Robert - I see that the Developer forum now has this implemented. Thanks!

ESXi + PXE

nick.couchman — Sat, 20 Dec 2008 22:35:52 GMT

Finally...success for PXE-booting ESXi. Many of the sites I found with instructions on ESXi PXE booting require that you VC and insert a little program into ESXi that contacts the server to get configuration information. While this is very, very cool, for those of us who do not have VC, it isn't very useful.

I noticed early on, when booting ESXi from a USB device, that after you configure ESXi and save the configuration, there's a local.tgz file written out to the /bootbank directory, which is on the partition of the USB stick from which ESXi boots. I extracted this file and found all of the customizations that I had made to my ESXi machine. So, I followed some of the ESXi PXE boot instructions and got all of the correct tarballs on the PXE server, then threw in the local.tgz file that had all the customizations. This worked - mostly. The hostname and datastore configuration was all there, but there was one minor annoyance: the SSL keys and SSH keys for the host didn't "stick" - they changed every time the machine was booted.

Next, I stumbled upon the vim-cmd command, which seems to command just about every aspect of the ESXi host. The vim-cmd command has many, many "sublevels" of commands - the hostsvc/firmware/backup_config command was particularly interesting. This writes all of the necessary local configuration information to a file and then spits out an HTTP URL you can use to download the file. Very, very useful - you get a "configBundle-<hostname>.tgz" file, which contains a Manifest.xml and the local.tgz file. I then made the mistake of trying to extract the local.tgz file and throw that on the PXE server...which results in a PSOD.

Finally, I came across the following document: http://docs.google.com/View?docid=ddcwgcd6_4fs6s7jcf. In this document are PXE instructions, and among the ones at the end it says to put the entire configBundle-<hostname>.tgz file on the PXE server. Voila! Instead of extracting the local.tgz file, I just needed to take the entire configBundle file generated by the vim-cmd command and boot the PXE clients with that file. And everything works now!

On the PXE side I'm using pxelinux and am able to create individual configuration files per MAC address. I then create an individual config file for each ESXi host, and each config file specifies the correct configBundle for each host and now I can boot all of my ESXi servers from the networks. I also created an NFS datastore that allows me to share VMs between hosts (easily - and access the datastore without the need for a VMFS filesystem).

As far as the effort to run ESXi on Whitebox machines, this is fantastic - most of the problems getting ESXi up and running are due to ESXi's limited support for hardware - mainly for storage controllers. While I understand VMware's reasoning behind this, I'm not opposed to working around that particular issue with things like this, and I'm glad VMware has created a hypervisor that can be PXE booted. Instead of having to have a compatible storage controller, you just need a compatible network controller, which you can come by pretty easily and inexpensively.

Virtual Machine Portability

nick.couchman — Thu, 18 Dec 2008 23:11:34 GMT

Well, I wrote a while back about portability of PV virtual machines, but I've also just had some experience with portability of fully-virtualized VMs (HVM in Xen language). I have a mixture of ESX and Xen for my virtual machines here, and I like to be able to move VMs back and forth. I've recently moved a couple of Linux-based VMs from ESX to Xen, which turned out to be very, very easy. ESX, it seems, creates two files for each disk - the descriptor file, and a "flat" file. The descriptor file simply tells ESX about the disk and then points over to the flat file for the data. The flat file is nothing more than a raw file - it has a partition table and then the data in each of the partitions. So, to move a VM from ESX to Xen, all you have to do is copy out the Flat file to the Xen box and point Xen at the flat file. You can also tell Xen to use the previous MAC address from VMware.

Going the other way isn't all that hard, either. You can copy the raw file from a Xen VM over to the ESX box, then you just need to create a descriptor file for it. I haven't done this, yet, though I'm sure I will, soon. I doubt you can do it from the VI Client, which will mean a little command line work, but I always liked getting my hands dirty on the CLI. The only trick to this will be that VMware limits the MAC addresses you can set on VMs, which means you may end up with a new MAC address if the original VM has a Xen-ranged MAC address. This is slightly annoying, though understandable, and shouldn't cause too many problems.

Anyway, that's it for now - just nice to know that I can move these things around without too much trouble! Using an NFS datastore would help, too, because I could access VMs from both ESX and Xen. I'm just concerned about NFS performance (though VMFS performance isn't anything to brag about), and I'm concerned about getting an NFS server setup that's not a single point-of-failure.

Resource Pool Permissions

nick.couchman — Thu, 18 Dec 2008 18:15:54 GMT

Yah! They've added it back in - one of the latest updates seems to fix it!

Studio Network Configuration, Server Requirement

JMills — Thu, 30 Oct 2008 01:27:34 GMT

JMills wrote:

nick.couchman wrote:

The network configuration on the appliance build is very, very limited.

The ONLY Server 1.x machine that I have here does not have it's bridged
network interface set up on vmnet0, which causes all of the builds to
fail because the newly built ((transient)) appliance can't communicate
with the Studio ((authoring environment)) server. Maybe someone knows
a way to edit the XML file and put in parameters that will allow me
to use interfaces other than vmnet0 and vmnet1?

I will look into how (and where) "bridged" "host-only" and "nat" are translated
during a VA provisioning cycle, I don't recall that section of code off the top of
my head. In the VA profile itself, we're still using textual representations rather
than explicit vmnet# virtual switch numbers.

Unfortunately the mapping between textual representations and explicit vmnet# virtual switch numbers ("bridged" (vmnet0), "hostonly" (vmnet1), and "nat" (vmnet8)) is handled in multiple locations (some deep within the core of our current codebase). Altering this behavior (e.g., to remap "bridged" to vmnet9) would not be as simple as applying a patch to the VMware Studio runtime scripts.

PV Portability

nick.couchman — Wed, 27 Aug 2008 22:39:29 GMT

It's been a while since I compiled a Linux kernel from scratch. I was upgrading a Gentoo VM today and was reconfiguring the new kernel and saw that, not only is VMI PV support built in to the standard kernel, but so is Xen PV support. And, you can compile both in at the same time. Combine that with Xen's support for VMDK files, and it looks like I now have the possibility of creating PV virtual machines and moving them back and forth between my Xen hosts and my ESX/ESXi hosts. If I use an NFS share, I may be able to have the same set of VMs accessible in both places at the same time.

More WhiteBox Success

nick.couchman — Wed, 27 Aug 2008 01:05:42 GMT

I now have five of six of the SuperMicro machines that I own running ESXi. I'll be working on getting the other one running, too - I'm going to try to boot ESXi off PXE on that one and use it for fiddling with ESXi settings. Among the SuperMicro machines I have running are the SuperServer 5013C-i (P4-based processor), a SuperMicro X5DPA-TGM+ motherboard, and a SuperMicro X5DL8-GG motherboard. They all connect to an Openfiler 2.2 machine via the iSCSI software initiator and share that volume for VMs. Next year I'm going to try to replace these five machines (and a few more) with a couple of 8-core machines and decide what hypervisor to run. Anyway, kudos to VMware for releasing ESXi under a free license - working for me!

I'm still ticked off at them, though, for removing support for permissions at the Pool and VM levels!

ESXi PXE Boot

nick.couchman — Mon, 25 Aug 2008 18:14:54 GMT

Cool - thanks!

And I did get USB boot support working - disabling ACPI in the BIOS helped ESXi recognize my hardware a little more successfully.

Virtual Appliances: Increasing Open Source Popularity

nick.couchman — Wed, 20 Aug 2008 18:43:15 GMT

For those of you who aren't real familiar with me, I'm an avid open source fan - I believe that open source software is a fantastic thing and has proved itself to have many, many benefits. Microsoft actively combats the popularity of open source software by trying to throw things like TCO and ROI at us and then see what sticks. Most of it doesn't stick.

One of the things that I think has created a new burst in the popularity of open source software is the concept of virtual appliances, especially VMware Virtual Appliance Marketplace. If you look at the appliances available in the marketplace, they are predominately Linux appliances, and most of the ones that aren't Linux appliances are other open source operating systems, like OpenSolaris, FreeBSD, NetBSD, OpenBSD, etc.

Why? Licensing. While there are a couple of evaluation copies of Windows-based appliances floating around out there, people don't like the idea of downloading something only to have it expire in 60, 90, 180 days, etc. They want something that they can download and try, then use in production if they decide they like it. Microsoft licensing doesn't lend itself well (at all??) to this type of usage. Open Source licensing does. And the virtual appliance concept gives those who may shy away from the "trouble" of installing Linux, Solaris, *BSD, etc., the opportunity to download and run a machine and see what it's like.

Score another victory for the open source community, and keep posting those open virtual appliances out there!

Is there an echo in here??

nick.couchman — Tue, 19 Aug 2008 13:21:23 GMT

One thing that I've noticed in the forums recently here at VMware is that there seem to be a lot of people who like to respond to a discussion and post exactly the same thing that the people before them posted on a thread. It's like a bad echo in the forums - seriously, if you can't post something original on a thread, wait until you have something original to add to an issue. I'm not claiming to be guilt-free in this respect - I'm sure I've done something similar, but it's something I'll be a lot more careful about in the future. I know everyone wants the points, but get them posting something new and not just repeating what everyone else said.

Can I be a consultant, too?!

nick.couchman — Mon, 18 Aug 2008 20:26:45 GMT

In my recent roamings around the VMware Communities, I notice that there are a lot more people with the little VMware logo by their name. In digging a little deeper it appears that VMware has added a bunch of consultants to their payroll. Maybe I can find a way to get in on the action, too!

ESX(i) Network Permissions

nick.couchman — Mon, 18 Aug 2008 12:21:23 GMT

I'd like to suggest the ability in ESX and ESXi (preferably without VC) to set permissions on certain networks and/or switches. I currently use VLAN tagging to get multiple subnets to my ESX hosts, and I'd like to be able to restrict the networks to which people can connect based on roles. This would allow me to have all of my networks available on certain hosts, even the ones that I want to restrict people from using, and then allow those people to run VMs on these hosts without having to worry about whether or not they'll attempt to use a network that they should not be using.

Give me my ESX Features Back

nick.couchman — Sun, 17 Aug 2008 13:45:19 GMT

Answer One: It has nothing to do with roles or administration, it has to do with where you can apply permissions. On my remaining ESX 3.0.1 host with VI Client 2.0.1, I have permissions tabs on the host, resource pools, and virtual machines, allowing me to assign permissions to any of those items. On ESX 3.5.0 with VI Client 2.5.0, the permissions tab is available ONLY on the host object, not on the resource pools or VMs. I also found a KB article that states that they removed it "by design" which really makes me mad. As I said, I don't like to upgrade and lose features in the process.

Answer Two: Actually, I can't afford VC (right now - hopefully next year) but I do need a more granular access control. I have 4 ESX servers and 4 ESXi servers. On the ESX servers I want to give certain members of my IT group access to certain VMs and resource pools without letting them have access to the entire host. For example, my DBA needs to be able to completely administer our VMs for our ERP system, our payroll system, etc., but not touch our domain controllers, print server, etc. So, I want to be able to put his VMs in a resource pool and give him full access to the resource pool but limit access to the other VMs. In ESX 3.0.1, I could do this. In ESX 3.5.0, I cannot. On the ESXi servers, I'm using these partly for certain non-IT employees to be able to install and run VMs for things like testing new versions of software, code development for our software engineering group, etc. In these cases, I want to be able to create a resource pool for the employees on one or more of these hosts and assign permissions to that pool such that they can do tasks like create a VM in the pool, configure it, etc., but limit them to other activities, like adjusting the properties of the pool or, definitely, adjusting the configuration of the host. I also don't want them to be able to create VMs outside a particular pool. With the removal (did I say "by design," yet?) of the permissions tabs from resource pools and VMs, I cannot do this.

Really Annoyed

nick.couchman — Sat, 16 Aug 2008 19:08:13 GMT

Well, I was very impressed that VMware had released ESXi for free, and I have just as suddenly become very unimpressed with them. In ESX 3.0 with VI Client 2.0, you could edit permissions for the host, a resource pool, and/or a VM. I went to adjust permissions on my ESX 3.5 server yesterday and noticed that the tab is now suddenly gone. I went into the ESXi 3.5 client (VI Client 2.5) and found the same. So, I posted a thread and was told that this feature is no longer available in 3.5. I opened an SR, then went over to the VMware KB and found the following arctile, 1004552, which states that this was removed by design! ARE YOU KIDDING ME?! I upgraded to 3.5 and had a feature taken away? I'm not paying any less for 3.5! Also, the price actually went UP recently! And now VMware is removing features?? This makes me really, really mad! The article stated that some similar functionality "may" be restored in the future, but that doesn't help me now. I don't have budget for purchasing Virtual Center, and, reading over the release notes that I read when I installed 3.5, I don't see any mention of this feature being removed.

VMware: please, please, please add it back - removing it is so silly I cannot believe you would do that!

ESXi on Whitebox Hardware

nick.couchman — Fri, 15 Aug 2008 18:58:00 GMT

I've spent the past week playing with ESXi, specifically figuring out which hardware that's not on the official VMware HCL I could get the stuff to run on. First, I found that Dell PCs run ESXi beautifully, straight off a USB stick. I followed the directions out there for transferring from the install image to USB stick and that worked very well. But, I doubt my users are going to understand when I tell them their PCs have been commandeered to run my virtual machines...so...back to the data center.

After clearing out that little bug VMware had in one of their builds, I found that I could successfully install ESXi on the following hardware, none of which is on the HCL:

SuperMicro SuperServer 5013C-i - These are probably 4 or 5 year old P4-based machines. I have three of them with 2-4GB of RAM each and a P4 3.2GHz CPU. The on-board SATA controller is the Intel ICH5R, which happens to be supported by the ata_piix driver present in the ESX(i) kernel. The catch is that the bios must be set up with SATA in "Enhanced" mode and note "legacy" mode, otherwise the SATA connections are seen as IDE drives, not SCSI drives, which prevents VMware from loading them correctly.

SuperMicro X5DPA-TGM+ - This is a motherboard in a SuperChassis that I have here that has 2 x 2.8GHz Xeon processors and 4GB of RAM. It has an onboard Intel Pro 100 and an on-board Intel Pro 1000 ethernet interface, and runs ESXi remarkably well. I don't think I'll be running more than a handful of VMs on it at a time, but I'll take all the ESX(i) servers I can get! The on-board SATA controller is the Adaptec ICH6 controller, which is also supported under the ata_piix chipset. This has to be set up in the BIOS in "combined" mode with the SATA controller in "Native" mode in order for ESXi to see it correctly.

SuperMicro X5DL8-GG -This is a PCI-X motherboard with 2 x 2.8 GHz Xeon processors. This one is a bit more challenging to get running, but I was able to do it at intermittent intervals. First, the on-board Adaptec SCSI controller is the 7902 chipset, which you would think would be supported under the aic79xx or aic7xxx module with ESXi. Unfortunately, these modules crash when loading, so you can't use the on-board SCSI controller. There's no on-board SATA controller, and IDE is out of the question for ESXi, so it has to be an add-in one. I have a couple of LSI Logic 22030-R cards that seemed to work okay. I was also able to boot off USB at one point, however my USB-based KVM system interferes with this older motherboard's ability to see the USB storage device correctly, so it only worked when I wasn't using the USB KVM. Of course, SuperMicro has stopped updating the BIOS for this MB, so there's little hope that USB BIOS support will ever work correctly on it, but maybe I'll be able to kludge my way around this one with the right combo of add-in controllers, USB devices, etc.

Also got ESXi running on a whitebox Intel D865GLC motherboard with 1GB of RAM. The machine has a SATA controller but I booted it off a USB stick as I don't have a SATA disk in the machine. I'm guessing the SATA controller is probably compatible with the ata_piix module in ESXi, but we'll see - I may try that later. This machine has an Intel Pro 100 network card that is recognized by the e100 driver in ESXi. 2.4GHz processor.

That's it, so far. Less successful tests have been done on the Dell D600 laptops, which brings the Purple Screen of Death on trying to boot. My quest to build a massive ESXi server base with all the spare hardware I have lying around will go on!

A Dream, Perhaps...

nick.couchman — Fri, 15 Aug 2008 18:48:36 GMT

Well, I have a vision for hypervisors and VMMs, but one that will likely not happen. See, I have a few legacy applications around the office here that must run on the Sparc architecture, and usually must run on Solaris on Sparc. Now, recently I've started using binary translation applications provided by a certain vendor to run these applications on 64-bit Linux. While this works very well, it occured to me that it would be very, very cool to combine a Sparc emulator into one of the hypervisor sets.

There's a project out there called Qemu that provides Linux binary emulation/translation as well as full system emulation. The project will emulate Sparc, x86(64), PPC, mips, sh6, etc., CPUs for either running Linux binaries on these architectures or for running full system emulators. The degree to which each architecture is supported, especially on the system emulation side, is pretty limited, but it would be really, really cool if you could pull up your favorite virtual machine manager and not only have the choice of which O/S you want to install, but what CPU architecture you'd like to run it on.

I realize there would be several objections to this. First, it kind of violates the line between "virtualization" and "emulation." Virtualization is simply splitting the available architecture between multiple O/Ss and controlling access and isolating the O/Ss from one another. Emulation, on the other hand, requires that CPU instructions be translated from one architecture to the physical architecture running underneath it all. Another issue that would come up is performance, especially given that the emulation must be done.

Still, it doesn't seem all that different to me. I'm just an IT guy who wants to be able to run many virtual machines or guests on a single piece of hardware. You can call it what you like underneath the hood, but it would be really nice to be able to choose the architecture of the guest machine.

Like I said, probably a dream that may never come true, but now it's out there...

ESXi

nick.couchman — Sat, 09 Aug 2008 14:51:20 GMT

Well, I was pretty excited to find out that VMware is now giving away ESXi for free! I have several servers that could benefit from this. While I use Xen in some places, it's only real useful where I have VT-enabled servers so that I can PV & HVM domUs. ESXi gives me the ability to run VMs on some of these others servers where I can't justify purchasing ESX but want the ability to run non-PV VMs.

After spending the past day or so experimenting with ESXi, I've managed to get it to run on some older P4-based SuperMicro servers (SuperServer 5013C-i). ESXi seems to support the SATA ICH5 controllers on these motherboards, so installation is pretty seamless. I've also tried it out on a SuperMicro X5DL8-GG motherboard with less success. First, loading the 7xxx and/or 79xx drivers on this platform fails, even though the motherboard has the on-board Adaptec SCSI adapter (7902, I think). So, on-board SCSI is out. Next, I tried a USB flash drive installation, but this also didn't prove out - the latest BIOS version on this board (circa 2005) still has some issues with USB boot support. I already have a hard enough time with my USB-based KVM switch on this machine, and adding a thumb drive to the mix didn't make the situation any better. So, my only option now is an add-in card supported by ESXi. Problem is that I don't want to spend a lot of money, but most of the chipsets supported by ESXi are "expensive" chipsets, so I need to find a compromise. Also, the chassis has a hot-swap SATA backplane, so a SATA or SAS controller is my best bet. Anyway, I'm sure I'll get that figured out.

Other than that I have a few previous generation Dell servers that may end up running this - a couple of them run VMware Server right now, and a move to ESXi would be a good upgrade, assuming they're supported.

General Beta 2.0 Observations

nick.couchman — Fri, 07 Dec 2007 18:57:25 GMT

1) The Web UI does not work with Firefox on Linux - at least, not Firefox 2 on Linux x86_64 (SuSE Linux 10.2, x86_64, Firefox 2.0.0.8)

2) Where is the VI client for Linux? I know, I know - here I am, again, asking about this, again, but if #1 is true, and you're migrating Server 2.0 to the Virtual Infrastructure way of doing things, including using the VI client, then, please, please, please, please, please don't cripple those of us who choose not to use Microsoft's operating systems. I think migrating everything toward the VI client is a great idea, but please give us Linux users some way to manage it natively!

3) Where'd the ability to add physical disk devices to VMs go? I see either virtual disks or SAN mappings - where are the local device mappings? I know that in a VM environment mapping directly to physical disk devices defeats the portability of VMs, and I'm a huge advocate of not doing things like that. Still, every now and then (and now is one of those times) you need to map a physical disk into a VM (temporarily) and I'm not sure why this functionality has been removed (or at least buried).

--Nick

VMware Server: VM Priority Tuning

spiffed — Sun, 28 Oct 2007 20:18:47 GMT

TvL wrote:
for i in `ps ax | grep "vmware-vmx" | grep -v grep | cut -f 2 -d " "`; do renice 19 -p $i; done

This command will fail if you have 5 digit PIDs because there's no longer a first " " to cut on. The below command uses character cutting and calls renice only once using xargs.

ps ax | grep "vmware-vmx" | grep -v grep|cut -c 1-5|xargs renice 1

Replacing X Login Manager with VMware Server Console

hangglider — Wed, 21 Feb 2007 10:48:52 GMT

Hello, nice solution !

Regards

Message was edited by:
hangglider

ESX3 Starter Edition Backups

nadger — Mon, 04 Sep 2006 15:59:24 GMT

As mittell said vcbMounter and all vcb* tools can be used without the vcb licence if you are not using the proxy and have replaced vmsnap.pl scripts. The vcb scripts are already installed on all ESX3 installations

VMware Server: Include X11 Libs

nick.couchman — Thu, 20 Jul 2006 21:07:31 GMT

Yes, it's true that many distros have a libs-only package, however my point was that often times these packages have other dependencies, which have more dependecies, and a one-package install (for the X11-libs) turns into a half-dozen or a dozen-package install very quickly.

VMware Server: More than two USB Ports per VM

DaveP — Mon, 10 Jul 2006 18:46:43 GMT

There's a paper describing its use with ESX Server. Might be useful reading. http://www.vmware.com/pdf/esx_anywhereusb2.pdf

Virtual Machine Importer: Linux Version

nick.couchman — Thu, 06 Jul 2006 21:23:33 GMT

Well, that depends on what you mean by "the hard way." If you mean, command-line style, then, yes, we like doing things the hard way, because that also means the flexible/agile way. If you mean manually editing a bunch of files, then having to create a BartPE disk to go fix the VM after somehow using Ghost to get it from physical machine to VM and hoping it won't blue-screen on reboot, then no, we like the easy way.

Actually, we'd just really rather not use these Windows servers at all. See, the Linux kernel is very easy to reconfigure for a different hardware platform. You can have multiple kernels, you can have one for one platform, one for another, etc. We'd really rather just run all Linux all the time, but you wonderful Windows desktop users make that very difficult.

Just kidding - please, don't take any of that too seriously - I'm not trying to start a "my O/S is better than your O/S" argument!

VMware Server: Make Permissions Mean Something

nick.couchman — Fri, 30 Jun 2006 13:30:53 GMT

I'm not familiar with ESX at all - haven't had a chance to dive into those, yet - so I don't know. But I guess if that's how they behaved, then, yes, that's how I'd like Server to behave.

VMware Server C API - Suspending VM's

tclendenen — Sun, 30 Apr 2006 17:15:34 GMT

That's what I'm guessing, but I didn't confirm it. If a bug is found, is there a way to report it other than a service request?

Message was edited by:
tclendenen