Inchoate Curmudgeon

While looking for an OS X alternative to the ESX Virtual Infrastructure CLient for accessing the console of a virtual machine hosted on ESX, I found this article. An example configuration for accessing the console for a client on the ESX server using VNC port 5901 using a password of “secret” would require adding the following entries in the .vmx file for the virtual machine.

RemoteDisplay.vnc.enabled = "true"
RemoteDisplay.vnc.port = "5901"
RemoteDisplay.vnc.password = "secret"

The instructions work for ESX, except for one small detail: the ESX server won’t accept remote VNC connections. There is likely some way to turn this on, but allowing remote vnc connections to a server is typically not allowed and is considered a security hazard.

The solution is too use ssh port forwarding. If the vnc port on the ESX server is 5901, you create a tunnel with the following ssh command:

ssh -L5901:localhost:5901 user@esxhost

where “esxhost” is the hostname of the esx server and “user” is an authenticated user on the esx host.

Once logged in, you can connect to vnc port 5901 using any vnc client on the ssh client machine you have just connected from. The host should be “localhost”, the port should be “1″ and the password should be “secret”. The console for the client on the ESX server should be displayed. My vnc client of choice on OS X is “Chicken of the VNC” but here are many alternative vnc clients for OS X and other operating systems.

Note that ssh is disabled by default for root on ESX server, so if the “user” for ssh access is root, you will either need to enable root access by editing /etc/ssh/sshd_config on the ESX server and set “PermitRootLogin” to “yes”, or use another user authenticated on the ESX console. The later method is more secure since enabling root ssh access to the console is inadvisable for production installations.

The typical method employed for migrating existing workloads to ESX from physical machines involves instrumentation of the workload in the current environment, coupled with technical and business analysis to determine:

• Workload suitability for virtualization
• ESX resource requirements to support the workload

The technical resource sizing method most often used leverages the VMware Capacity Planner. VMware capacity planner employs an offsite analysis of the workload in a VMware hosted service. This service utilizes collected VMware Capacity Planner metrics for over 20,000 machines, coupled with experience with factors affecting virtualization and ESX resource utilization, to provide a “black box” solution to consolidation target composition.

The solutions provided are generally accurate enough to substantially mitigate risks associated with oversubscription of ESX resources. Typically, organizations are able to migrate with minimal additional empirical workload testing from the physical server to the ESX virtualized environment.

Organizations that cannot use the VMware Capacity Planner facilities for workload analysis, due to policy or technical constraints that disallow the use of the VMware offsite analysis facility, must employ more elaborate and extended empirical testing of workloads to ensure that virtualized workload is suitable for VMware virtualization in the targeted configuration.

“VMware Migration and Consolidation Without the VMware Capacity Planner” discusses the issue and provides an approach for managing migration risks when the Capacity Planner is not an option.

The OMG Model Driven Architecture (MDA) explores the formal concept of transforming and instantiating models. “In the MDA, models are first-class artifacts, integrated into the development process through the chain of transformations from Platform Independent Model (PIM) through Platform Specific Model (PSM) to coded application.”

The “coded application” terminology is bit unfortunate, since the MDA concepts, due to the meta-model approach, could translate to infrastructure implementations: “realization artifacts” might be a better phrase. However, from the viewpoint that the implementation is realized entirely by configuration in emerging infrastructure implementations, such as VMware and Sun Dynamic Infrastructure (DI), the “coded application” wording may still apply.

This whole topic of modeling infrastructure architecture is somewhat messy, probably due in large part to the overwhelming preponderance of Java coders and architects in the architecture modeling domain. The concepts of architecture usually start and stop with software architectures, for Java what I call “inside the container thinking.”

I do know that I personally think the way that we enterprise and infrastructure architects “draw architectures” is completely unconstrained and rife with opportunities to misunderstand what we are “saying”. There has been more than you might think written about this, mostly concluding that the UML is the “best we have.”

However, very few people bother with specifying infrastructure architectures in UML, since using the best available diagram for viewing and manipulating the model, the Implementation Diagram, results in a very cluttered artifact for all but the most trivial cases. The other thing is that the none of the tooling I’ve used does a good job of constraining the implementation model to conform with the Class Diagram, which represents the meta-model for the implementation. As far as I know, this is the same for all modeling tools.

As a plain English example, I might model in a Class Diagram that specifies a server has a connection to two or more load balancers. This is fine for general constraints and specification, but when I draw an implementation model, there are no checks that my implementation actually specifies at least two load balancers. Not good.

The difference for us versus Java developers and architects is that they generally leap from Class Diagram to code. The Implementation Diagram is a representation of the state of a running application, modeling instances of the classes and their relationships. It’s not where they spend their cycles since they can just write the freaking code.

For infrastructure architects and infrastructure implementers, there is no such thing as an “infrastructure compiler”, that is a formal, unified, centralized human readable code that is transformed and realized as a gob of functioning infrastructure. Although some modern mechanisms go a long way, we remain mostly at the infrastructure corollary of wire-wrapping to implement code. We currently need implementation diagrams and other more concrete artifacts than Class Diagrams to tell various disciplines how to wrap their wires.

Going forward, we need a Platform Independent Model, a Platform Specific Model, and the “codes” that instantiate the model, all tied together. Modern provisioning systems centralize the control mechanisms.

The typical interest in CMDB with respect to provisioning is good, since at least has the capability to model the desired end-state. However, CMDB probably isn’t the right place to model the PIM, any more than it is the right place store Java Class Diagrams, unless we expand the notion of CMDB as it is currently used.

The current limitations with respect to implementing architectures with highly distributed configurations shift quite a bit with a combination of the “virtualization of everything” and the capabilties of modern provisioning systems, but we still lack the tools, and frankly the aggregate wherewithal I’m afraid, to make that final leap to “compile infrastructure specifications” into implementations. We have to stop looking at our feet. I imagine all the emerging provisioning and orchestration tools are intended to address this, but I can’t quite see it all tied together yet.

Some of the available MDA tooling might be worth a survey to see how they could be adapted to help realize infrastructure implementations. In particular, one tool I’m aware of, AndroMDA, is capable of accepting user-coded cartridges that can generate code fairly flexibly for different implementations. It’s used for Java, but I think may be agnostic enough for the task.

The vision is that we could generate XML and other text based configurations and specifications for an infrastructure implementation from UML models and diagrams.

Another possible approach is just modeling infrastructure meta-concepts and implementation concepts in a database and figuring out ways to transform them back and forth from PIM to PSM and XML. Some of the things that I and a colleague of mine are considering, that involves using RoR for in a provisioning scenario with DI and Solaris Provisioning System (SPS), would be a subset of this effort. The shortfall of course is visualization, or “diagramming”. We’d have models and transformations but still would lack a pretty “view”, and ways to manipulate the model visually, other than reports or web pages with text. Kinda boring. Perhaps this is just GUI sugar?

An intriguing aspect of ITIL change expected in a virtualization project is CMDB. I missed this on my recent post on ITIL and virtualization. It’s a funny slip, in the sense I’ve been pondering this subject quite a bit lately.

Virtualization concepts are increasingly realized in all the classic components of infrastructure: compute, storage, and networking. What impacts might you expect to CMDB for enterprises deploying virtualization technologies? What are the particular challenges with respect to CMDB and virtualization?

The pondering for me started with a combination training trip and workshop sort of exercise to a CMDB vendor recently. The workshop was more focused on the use of the CMDB as an embedded component of another facility, not a classic CMDB implementation in an enterprise. I was probably more interested in the general and typical utility of the product myself, not having much direct experience with CMDB implementations.

What struck me were the exchanges we had with the vendor with respect to modeling virtualized infrastructure and components. The issue is that this CMDB implementation, like most if not all others I imagine, really had no existing constructs to deal with many emerging virtualization concepts. Furthermore, we were having some trouble describing these technologies in a way that the vendor could discern how they should be modeled. A lot of this could be attributed to discussing abstract concepts that were not realized as physical components in the infrastructure. Grasping abstractions is just naturally harder than grasping boxes and wires.

There was no particular difficulty with the concept of a VLAN, or a service IP or VIP, this is relatively mature technology. There was much more trouble with more nuanced differences between technologies like Solaris Zones versus VMware or Xen type virtualization technologies, and some of the networking concepts like virtual NICs and the impact of real or virtual VLAN tagging on interfaces as they relate to things like link aggregation. I feel like we only scratched the surface insofar as discovering all the modeling challenges.

The problem with this as it is related to CMDB is that many of the core use cases involve understanding the impacts of change and the impacts of component outages on dependent services. If you can’t model relationships correctly, the utility of the CMDB is significantly eroded. Jamming a virtual thing into a CMDB as though it were a real thing probably won’t cut it.

There’s also an irony. The need for CMDB in IT operations is far greater when using virtualization than when you aren’t. As an example of the kinds of issues we face, in my little own three machine lab, I have an explosion of DNS entries related to dozens of virtual machines, and I can no longer remember if these things still exist and where they are or were realized. I have iSCSI LUNs that are used both as direct attach block devices to real machines and others that are used by VMware to provide storage to dozens of machines, and others that are direct attach to virtual machines *within* the VMware infrastructure. The mind boggles.

Discounting the completely unconstrained lab as a good example of our modern, discipled and constrained enterprise architectures (*cough*, *cough*), it seems there is still a vast gapping chasm between what we need in a CMDB and what can currently be readily realized, both in terms of our collective experience and understanding as well as the readily available tools.

Consolidation invariably results in running more workloads on fewer machines. For most customers, this implies going from one workload or major application per machine to many workloads or applications per machine. This may imply more than one business unit or portfolio of applications sharing individual machine hardware in order to obtain the desired, cost-effective compression ratios. This has a number of implications for IT Service Management and operational capability. The technical nature of virtual machine technology as a lever with respect to consolidation nuances these issues in several ways.

General Impacts

Regardless of the technological tools leveraged to enable consolidation, there are certain invariant implications for operational capability with respect to consolidation when transitioning from one service per machine to many services per machine architectures. Current service capabilities must be examined, with particular focus on the following ITIL areas:

• Service Level Management
• Capacity Management
• Availability Management
• Service Desk and Incident Management

Capacity Management

The implications of sharing machine resources on a single machine are the most readily recognized of the potential impacts from consolidation. For most customers, the conversations begin and revolve around questions like “How will consolidation impact the performance of my application? How can you make sure that other applications don’t hog the machine?”

The ability to consolidate workloads depends on two key principle mechanisms:

• The predictable resource requirements of a given set of application workloads.
• The ability to constrain or control resource use by a given application in the workload mix.

In the world before consolidation, isolation of workloads is effectively realized by the machine itself. A single application is on a single machine and can’t, for the most part, impact other applications in the data center on other machines. Of course, any resources that are shared, such as network bandwidth and SAN shared I/O may be impacted across machine boundaries, but even impacts to these resources is effectively capped by an individual application’s available CPU.

In the world after consolidation, this is no longer the case. It is no longer acceptable to allow individual applications to grow to the point where they consume all the resources on a machine over time, since the machine CPU, memory and other resources is now very much shared. Furthermore, there must be coordination of Capacity Management processes for multiple applications that generally is isolated in the systems management staff of individual applications prior to consolidation.

To digress a bit, the acceptability of allowing businesses to overrun “their machines” in pre-consolidation operations is another matter, but the prevailing wisdom in many enterprises is to leave it to individual business units to manage use of “their own” computing resources. Note that this attitude and approach re-enforces the unfortunate perspective that business units “own” the IT resources and machines they use, which makes driving consolidation initiatives from centralized IT organizations all the more difficult.

However, this also suggests that enhancing Capacity Management of existing machines and services prior to consolidation may increase the perception of IT as at least a partner in owning these resources, and thus may consequentially reduce this somewhat irrational barrier to consolidation. If the customer perceives that IT is measuring capacity only in preparation for consolidation, this merely adds fuel to the “leave my machine alone” fire. This may be the case even if IT has proactive monitoring in place if there has been no periodic, acknowledged reporting and interpretation of capacity metrics with the customer. Capacity measurement without a plan or reporting is not Capacity Management.

The practical implications of increased Capacity Management capability will vary, but the key change is more centralized, periodic management and reporting of Business and Service Capacity requirements and use.

Availability Management

Availability Management processes are responsible for technical architecture and the satisfaction of systemic qualities (”fit for service” in ITIL parlance). This covers areas like reliability, maintainability, serviceability and security as well as the more obvious meaning of “availability”.

The process of designing an implementing new services, and improving the systemic qualities of existing services, changes in a consolidated regime, since the prevailing or preferred mechanism for implementing new services involves provisioning virtual machines into existing infrastructure that may or may not involve additional hardware provisioning.

This is in direct contrast to single machine, single service regimes where the service can, and many times is, designed and provisioned, end-to-end with few implementation constraints. The need for documented design constraints for new services conforming to and suitable for provisioning in the consolidated service implies potential changes in the way new services are designed after consolidation, as well as clear communication and documentation circumscribing the correct use of the consolidated services. The resulting expectation is that IT should be involved earlier in the application design and procurement processes than may be the case prior to consolidation.

A more obvious availability implication for consolidated services is the impact of individual component outages in a consolidated environment: more services will be impacted by a component failure when more services depend on fewer components. “If you put all your eggs in one basket, it better be a pretty good basket.” This will generally result in a need or desire for higher availability designs for the consolidated regime versus the actual availability of the individual, stand-alone services prior to the consolidation. This will not only result in technical designs with higher availability, it should also result in enhanced operational capabilities and procedures to reduce the extent and duration of service outages when they do occur. The latter changes will, at minimum, affect Service Desk processes, procedures and operational capability.

Service Desk and Incident Management

Enhanced Availability Management can provide enhanced technical capability for consolidated architectures, but without adequate Service Desk capability, the full benefit of these capabilities will be unrealized. “If a tree falls in the forest and no one hears it, did it make a sound?” Providing the technical capability to ability to recognize component failures with out the timely operational capability to act on the event is useless.

Service impacting events in the consolidated service must be recognized by management and monitoring capabilities. The ability to recognize the events must be backed up in two ways: the ability to exercise Incident Management processes to rapidly mitigate the event or restore service, and the ability to adequately communicate the situation to service customers as required. Implementation of consolidated services will certainly affect Service Desk and Incident Management training and documentation, even if the core processes are sound and capable of handling the service management requirements.

Another pitfall to avoid is trading disjointed, diverse and distributed pre-consolidation Service Desk and Incident Management capability for no capability at all: if a physical machine or service has been colloquially or informally supported by a group separate from centralized IT Service Desk, the support capability must translate to a more centralized implementation in the consolidated regime. This will result in a shift of organizational roles, responsibility and staffing that should be reduced in aggregate over pre-consolidation levels.

Service Level Management

The establishment of a “services not servers” approach is frequently the most disruptive aspect of consolidation. The management of the service as a virtual machine tends to mask some of these implications, but they are not eliminated.

One of the great achievements of virtual machine technology in general is a significant reduction in the requirements for initial consolidation, including tools that can assist with the translation of physical machines into virtual machines in the consolidated environment. This relative transparency extends to the ongoing operation of the individual virtual machines, including such things as isolated, per virtual machine security and configuration.

Nonetheless, much like multi-tenant housing, you can’t operate consolidated infrastructure without a landlord. There must be over-arching IT business management of the consolidated service to coordinate all the other service management processes for the consolidated service, and to proxy the aggregate virtual machine customer demands into a cohesive consolidated service plan. Service Level Management is the interface between the consolidated service IT processes and the consolidated service customers.

The relative impact of this for consolidated services over per-consolidated administration depends greatly on several factors:

• the relative organizational centralization and homogeneity of the pre-consolidation server administration function
• the relative business acumen and capability of this pre-consolidation function

IT organizations that are exclusively focused on the technical aspects of machine administration are very likely to require additional operational capabilities in many IT service areas coordinated with enhanced Service Level Management processes. This can be generally characterized by being able to operate the consolidated service like a “business within a business”, with strong organizational knowledge of IT customer business requirements, and strong capabilities to translate these demands into useful, well managed consolidated service offerings over time.

A key red-flag for trouble to come in the area of IT Service Level Management is any consolidation plan attempting to leverage virtual machine technology as a “silver-bullet” for low utilization rates, without extending and requiring clear, committed and continued involvement and participation by the business units and customers affected by the plan.

Extending the landlord metaphor, a consolidated service without adequate Service Level Management will devolve into the IT equivalent of a slum. Whether or not the point of a consolidation is to refresh and update aging technology, particular care should be taken to refresh and update IT Service Management as a key component of the delivery.

I have added a V60x to my lab and want to jumpstart it rather than futz with DVDs. I wanted to have a jumpstart server on my Mac laptop, in a VMware Fusion guest, for portable use. I wanted my jumpstart images on a ZFS share, both to ease the NFS configuration and to allow me to move the jumpstart bits around my network with the ZFS commands later if I wanted to. To recap, my requirements were to

• Jumpstart from a VMware Fusion guest running Solaris Nevada
• The jumpstart bits need to be in an NFS shared ZFS filesystem
• The setup must use my existing Ubuntu DHCP server
• I don’t want physical DVDs, floppies or CDs in the equation

So, when done, my setup consists of the following machines:

• My Mac laptop with a VMware Fusion guest running a jumpstart server on Solaris Nevada
• My network DHCP server configured with the PXE parameters
• My target V60x, booting the install served by the laptop

I haven’t found any step-by-step examples directly applicable to my setup integrating all this, particularly the bit where I need to use a non-Solaris DHCP server. My DHCP server is on Ubuntu. The instructions are all out there, but getting it all put together was a bit confusing.

I could possibly have set up DHCP on the Nevada guest on my laptop, but I was afraid of some manner of conflict with my existing DHCP server. What happens when you run two DHCP servers on the same network? It can’t be good.

The steps are as follows:

• Set up an "install server" with "setup_install_server" from a Nevada iso image
• Add the parameters for the V60x I want to jumpstart using "add_install_client"
• Modify my DHCP server configuration
• Network boot the V60x

Of course, the first thing to do is download the OpenSolaris DVD iso to the Mac. After downloading, unzipping and concatenating the pieces, I used this image to create a Fusion Nevada guest on my laptop. With build 70, currently the latest, this is pretty straightforward, and the VMware tools install without a hitch. You need to configure the Nevada VM with bridged ethernet and a static IP address.

Once this is done, and the Nevada guest VM is booted, the next step is to make the VM jumpstart server. Before this, though, we should create a ZFS filesystem for the bits. In my case, I added another virtual SCSI disk to the VM and created a zpool. After a manadatory paranoia check using "format" to make sure I’m using the right device:

 zpool create zpool01 /dev/rdsk/c1t1d0 

Then we need to create the zfs file system, mountpoint and go ahead and share it read-only. We are creating a jumpstart hierarchy so the various images can be manages separately.

zfs create zpool01/jumpstart
zfs create zpool01/jumpstart/nv70
zfs set mountpoint=/export/jumpstart
zpool01/jumpstart zfs sharenfs=ro,anon=0 zpool01/jumpstart/nv70 

Now that we have the storage set up, we can run "setup_install_server". After mounting the DVD iso to the VMware Fusion VM, we change to the "Tools" directory and run "setup_install_server".

cd /cdrom/sol_11_x86/Solaris_11/Tools
./setup_install_server /export/jumpstart/nv70

This copies the DVD contents to the jumpstart image directory. Time for a coffee break. After the copy is complete, we run "add_install_client". You need the MAC address of the NIC you will be booting from. Since I already had an OS on the V60x, I ran ipconfig -a to get this. If its a new machine, you need to gt this from the BIOS setup screens on the machine. The Intel NICs display the MAC address of the NIC during boot, so this may work for you also. In my case, the MAC address of the V60x is "0:7:e9:7:a:8e".

./add_install_client -d  -e 0:7:e9:7:a:8e  i86pc

This simple command sets up several files on the jumpstart server and returns information you need for configuring the DHCP server:

If not already configured, enable PXE boot by creating
a macro named 010007E9070A8E with:
Boot server IP (BootSrvA) : 192.168.11.133
Boot file      (BootFile) : 010007E9070A8E

You should recognize the IP address as the one of the machine you’ve been typing these commands on. In this case, this is the IP address of the Nevada VM on my Mac. We are ready to update teh configuration on the Ubuntu DHCP server. These instructions should work for most Linux DHCP servers. although file locations may differ. The dhcpd.conf on my server is in /etc. Edit this file adding a "group" block following your other configuraiton entries like the following.

ddns-update-style interim;
ignore client-updates;

subnet 192.168.0.0 netmask 255.255.0.0 {
option subnet-mask 255.255.0.0;
option routers 192.168.1.1;
range 192.168.1.1 192.168.1.170;
option domain-name-servers 192.168.1.165;
option domain-name "home.louspringer.com";
}

group {
        next-server 192.168.11.133;
        filename "010007E9070A8E";

        host iphigenia {
                hardware ethernet 0:7:e9:7:a:8e;
                fixed-address 192.168.11.15;
                option host-name "iphigenia";
        }
}

The hostname of the machine I’m jumpstarting is "iphigenia", and the filename is what we got from running "add_install_client". Their should be a "host" configuration for each server you would like to jumpstart. So far, I have but one.

After this, "pkill -HUP dhcpd" on the DHCP server, and you should be able to reboot the machine you are jumpstarting and PXE boot it. For the V60x, you press F12 on the keyboard as it’s booting. From that point, its a regular Solaris install. As I get better with this, I’ll be adding configurations to fully automate the install and make it completely scripted.

I found several resources to be of help figuring all this out that you can refer to for more details:

• PXELINUX - SYSLINX for Network Boot
• Solaris 10 Installation Guide: Network Based Installations

In “Nevada 64a Running in VMWare Fusion” I posted a work-around for installing Open Solaris X86 Nevada build 64.

The latest version of Fusion, Version 1.0 (50460), seems to have fixed this issue. Open Solaris X86 64bit installs on this version with a virtual SCSI disk. Installing onto a virtual IDE drive is not required.

Excessive hyperlink WARNING: If you don’t like a lot of hyperlinks in your blog reading, stop now!

I ran across this note from Dirk Grobler on one of the lists I’m on:

“As we all know the performance of S10 on Vmware is not great, specifically the networking seems to be very slow. One reason for this is that the network driver for Solaris 64bit is not replaced by the vmxnet of VMware. In 32 bit mode this actually happens and the performance is much better. Unfortunately 64-bit mode is automatically selected, if the host is supporting it. Forcing 32-bit mode can be done though.

“Check out this article for more info.”

After a little follow-up research I found a Sun Blueprints article, “Sun Virtual Desktop Access Kit for VMware” (March 2007) by Dirk Grobler of Sun Engineering and Warren Ponder of VMware Desktop Technical Marketing. This paper refers to another paper by Warren Ponder, “Sun Desktop Virtualization Solution”

Since I’m posting these, I should also refer to several other related articles I’m aware of. There are some instructions for a Sun Ray VDI solution on the Sun Ray User’s Group Wiki site called the “VDA Cookbook“. The virtual lab I have set up uses a subset of these instructions.

If network performance is a concern, it may be preferable to run the Solaris Sun Ray server VMware guest in 32 bit mode to get the optimized VMware vmxnet driver when deploying a VDI solution. The general recommendation is to run a production Sun Ray VDI deployment with the Sun Ray Server on it’s own host, such as a T2000, rather than as a VMware guest. The heavy networking workload is one of the reasons for this.

One of the recent Nevada builds introduces xorg 7.2 which breaks the VMware tools installation. Use these instructions to work around the issue.

You may want to enable root logins in /etc/ssh/sshd_config (”PermitRootLogin yes”) or create another login via in case you can’t get back in through the graphical console after these steps. You may also wish to tar up /etc/X11 and /usr/X11/lib just in case.

These instructions create a kludge for the VMware tools install:

• Copy and untar the vmware tools onto the root desktop.
• cd to /Desktop/vmware-tools-distrib/lib/configurator/XOrg
• copy “7.0″ to “7.1″ (cp -r 7.0 7.1)
• cd 7.1 (step not required)
• cp /usr/X11/lib/modules/drivers/amd64/vmware_drv.so . (step not required)

Go thorough the normal VMware tools install process:

• cd /Desktop/vmware-tools-distrib
• ./vmware-install.pl
• At the prompt “What is the location of the directory which contains your XOrg modules?” answer /usr/lib/X11/modules

IMPORTANT: Delete or move aside the generated /etc/xorg.conf. YAGNI and it is broken somehow anyway. The tools install will have installed the optimized network adapter and the VMware daemon processes, including the one that should allows your mouse to move off the VM screen w/o the special key sequence.

You need to log out and back in at this point to check you display and mouse configuration.

Yesterday in “Using ZFS and NFS with Textmate and Finder on a Fusion VM” I stated that “SAMBA would be … the only reasonable setup if you are doing something like this with a Windows machine and VMware Workstation.” This was a bit of an overstatement, since you can configure an NFS client on a Windows machine to do this sort of thing. Also, it appears as though Windows Services for UNIX (SFU) is now freely available from Microsoft, apparently under a combination of LGPL, GPL, and a Microsoft EULA.

I didn’t do complete testing of the scenarios we went through yesterday, but did establish that you can use the SFU NFS client to connect to a Solaris VM as root and a regular user. Since I don’t have VMware workstation setup on a Windows machine, this connectivity testing was done between a Windows XP VM on ESX and the Solaris Nevada VM on my Mac running Fusion.

Note that an SFU NFS connection processes all requests as the authenticating user, meaning basically you can’t “su” or log in as another user on the Windows machine and have that user id automagically map to the equivalent id on the Solaris VM.  You would need to create another map and authenticate as that user. This is probably a minor inconvenience for most uses.

I still think that SAMBA/CIFS is probably a better choice for Windows users attempting to fuse the Solaris server and developer workstation filesystems for a typical development environment. I’ll pursue some example configurations along these lines and post my results.