xVM Ops Center Early Adopter Training this week in Santa Clara

We just completed the first round of early adopter training in Santa
Clara this week. Another great job by Steve Stelting who taught the
class. Considering we put this together in just a couple of weeks I was
impressed with what he was able to deliver. I know the other attendees
were as well. Thanks to everyone in SysNet who provided content for us
and participated in the preparation and Q&A sessions.

For this early adopter class we picked some of the best from the field
including SE's from Scott Armour's sales team and David Teszler's
Systems Practice team. We brought in some of our Support (Tier 3) and
Sustaining engineers who currently support Sun Connection and N1SM from
a Solution Center perspective.  Also in attendance were some of our
best Support Services SSE's who do our Sun Connection installs. This
attendees provided a lot of great feedback, questions, etc. which we
will compile over the next couple of days. We will be doing similar
sessions in January in Burlington, MA and in EMEA prior to rolling out
training to a broader audience in February.

I thought I would share a comment from one of the SE's that attended
the training:

xVM Ops Center Cool improvements in OS provisioning vs. N1 SM


Cool "news to me" ...  :-D

In the old N1 SM way, when you did an "n1sh create os {os_name} file
/path/to/solarisdvd.iso" the ISO image was lofi/loop mounted and copied
the contents of the DVD filesystem to /var/js/{distro_number}, when N1
SM started running the "create os" job.

The new xVM Ops Center way simply copies the /path/to/solarisdvd.iso to
... so the operation is basically at "disk speed."   This approach
retains a copy of the original .iso file, which is used to create
"replica" boot servers on downstream "Proxy" servers for JumpStart
purposes...effectively as many Proxy/JS Boot servers as needed to
support a diverse network topology comprised of many subnets.   The
actual steps of mounting the ISO and copying the contents to
/var/js/{distro_id} are deferred until the first OS provisioning job is

This allows for the automatic creation of JumpStart boot servers in
each subnet, which is a huge advantage for a site with many subnets. 
In the N1 SM way we would have needed separate N1 SM servers in each
subnet and we would have had to create the OS and OS profiles on each
of them manually or through custom scripting.  Or we would have needed
to do funny things with DHCP helper and changed the provisioning IP on
the SM server and limited jobs to whichever subnet is currently
undergoing provisioning.  With xVMOC, the use of Proxies that act as JS
boot servers in each subnet ... and the fact that the JS miniroots are
copied to those JS boot servers, automatically is a HUGE improvement
over N1 SM.

There is also a positive side-effect of this design for demonstration
purposes...  It means we can create an OS, and an OS profile very
quickly and there is only a short "disk-speed" delay in copying the
.iso image.   We know that actual OS provisioning takes a while, so the
fact that it takes a bit longer the first time can easily be explained
away.  Also, we can deploy an OS image that has been previously
deployed, so there is no additional delay during the demo for the ISO
mount and copy to /var/js/{distro_number}.

I like it.

Also, JET is being used for the JS boot servers on the proxies.  And it
is possible to import JET modules and existing JET profiles as well as
to override individual JET parameters.   This is well beyond my
expectations.  We've been asking for this for seems like FOREVER.   Now
we have a solution for customers with pre-existing JET
infrastructures.   We can add the JET modules they need and we can
import their existing templates.  Then they can stop using their old
JET servers and rely on xVM OC JET capabilities going forward.    This
is the best we could have hoped for -- would be unrealistic to manage a
pre-existing JET environment in place...but as long as we can capture
the settings, we have a great path to import to xVM OC and then
continue to manage within xVM OC.


Post a Comment:
  • HTML Syntax: NOT allowed



« February 2015