Author Archive for Jim Porell

z86VM Update

z86VM update.
It’s been a year since our last public blog post. We’d like to provide you all with an update. Net – we found code problems, dramatically improved performance, have terrific beta customers and have more work to do to get Beta 4 out.
With Beta 3, we learned that this was really an Alpha level of code. While it was interesting for simple demo’s of the desktop and server side, it had a latent issue that turned out to be massive under the covers. We could do some interesting “party tricks” like run games on the desktop and some simple web serving.  It really couldn’t be used to solve any customer problems. We discovered that we hadn’t adequately tested nor properly developed a large component of the x86 architecture. This affected close to 900 instructions. It was back to the drawing boards for us. During the first quarter of 2015, we completed that development effort and started testing to the point we felt pretty comfortable about our code again. On the positive side, we did learn that deployment and customization of both z/VM and z86VM weren’t that difficult and a system could be running in less than a day.

In parallel to this, we’ve been working on our performance paths so that we can get as near native to x86 hardware  performance and support as many users per core as possible. We got an opportunity to stress test our code on IBM’s new z13 server, with and without the new multi threaded cores. The results were pretty amazing. We found the z13 to provide results that were 15x faster than our little z114, based on raw chip speed. We’ve done multiple tests in that environment and improved performance a couple of times since then. We are quite proud of the results.  We think our guest to core ratio can be very competitive with x86 price performance. Since we aren’t done improving the code, we’ll describe that more at a later date when we are ready to actually sell our product.

We continue to be amazed at IBM’s z/VM hypervisor and it’s capability to support 1000’s of virtual guests. Just for fun, we did a benchmark with 1000 guests per core over 4 and 8 cores. That is probably several orders of magnitude beyond what an x86 server could do. Alas, it was just for amusement and not for production. While the system didn’t fail (very impressive), the end user performance was terrible. So as we go forward toward a sellable product, we’ll provide guidance as to a proper guest to core ratio based on a couple of different workload mixes.

We believe the next beta should actually deliver code that can solve problems for customers, so we get a true value for the customer and our own development experience. With that goal, we attempted to install the latest Ubuntu release that would enable commercial off the shelf middleware to be installed on top of it. We found another series of instruction bugs. When it comes to instruction addressing, there is a base register and code will run as a displacement off of that base. It seems we did all kinds of testing for positive displacements and totally missed negative displacements. So back to coding the fixes for that. That’s where we are today.

The important thing is, we continue to learn and improve our code. Our test suite covers many millions of variations across the x86 instruction set. We run those on x86 and compare the results on z86VM on System z. When we find differences, we diagnose and fix. The bugs we find highlight errors in our code and in our test coverage. We’ve been methodically updating the code and test suite, as a result.

Let me extend a gracious thank you to our current beta customers. There are presently 17 of them across 4 continents and a variety of industries. We’ve got another 25 interested parties that are either waiting for a hardware upgrade or our next beta delivery. We appreciate your interest and are committed to making a positive difference in your choice of IT deployment.

We’ve also established some new ISV partnerships that we hope can deliver value to you. While we’ve been focused on server consolidation and virtual desktop infrastructure, we are exploring some virtual mobile capabilities for Android applications. There seems to be no end to the possibilities as to the problems we should collectively be able to solve.

It’s been a long time bringing this dream of ours to reality. It’s taken a lot of energy and patience on our part to get this far. We feel very close to delivering on the next beta, but we are cognizant and appreciative of your time and energy too. We don’t want to waste either by delivering something we know won’t help you solve problems of your own. The best statement of our product goal is: Help businesses dramatically reduce IT expenses while improving the security and resilience of their workloads.

Stay tuned!

Beta Update for June 18

A number of changes today. An accumulation from a couple of days.

1. Updated the Operations Manual. It now includes change bars from the prior update. https://www.mantissa.com/dotcom2020/wp-content/uploads/2014/06/z86VM-Concepts.Beta3_.v061814.pdf

2. New problem found – not yet fixed – Under DEMODSL, when you have the desktop running and open a window, if you resize the window, there is a good chance that your system will appear to freeze. It actually goes in a loop. The problem is known, but it will take a bit to get the fix out.

3. A new hardware restriction was identified. The z86MNT 191 cms disk must be large enough to contain the downloaded VMARC file and some workspace. We’ve learned that a 3390-3 is too small to meet that need. The storage device can be reconfigured to grow the space. Some technical solutions may be possible, but may not be ready until General Availability or later. This is a good reason for running the Beta…to find this kind of problems.

4. If you want to use multiple 3390-3 devices to meet the IO server needs, the documentation describing the set up is now included in the Ops Manual.

5. Several new troubleshooting guides were provided, including VNC usage and z/VM paging set up recommendations.

6. We do not have a Software License agreement or NDA in place for Beta participants. We have found all to be mainframe enthusiasts, much like ourselves. There is a trust inherent in this beta. To that end, the Beta description now includes a comment about the spirit of this beta. We hope that each of our participants will maintain that spirit. The text added is as follows:

We’ve released the beta because we wanted to learn from you, the customer, what is good and bad and also to check our documentation, identify any restrictions in the code and capture new product requirements. We have found it is capable of doing some very interesting demos as to possibilities for how it can be used in the future.  We are concerned about expectations for our product. We know we have performance and quality work to do before it becomes generally available. We ask that you understand that.

We would like to make the beta a good experience for you. We may ship additional beta’s with new functions, fixes and performance enhancements. If you want to show someone a demo because you think it is “cool”, “exciting”, “the future”, or any other kind words, that would be wonderful.   We ask that you not show nor publish any performance data associated with your experience in the beta, without permission from Mantissa. We are not done developing the product yet and we hope to further improve the experience. That’s also why we have no published nor target general availability date yet. We will not release the code until it meets our own expectations.

All of us at Mantissa appreciate the time being spent by each of you participating in the beta. We have one customer that has completed all the pre-defined exercises and is looking for more. We have several other customers in a variety of spots within the operations manual testing their install. Thank you all for your interest.

And we continue to be interested in your feedback. Don’t hesitate to comment here or send an email to z86vm@mantissa.com

 

 

Beta Update for June 17

New Hardware Restrictions Identified: We are trying to reduce or avoid hardware restrictions for z86VM. We’ve documented our server restriction that z86VM will only run on z114 or z196 processors and above. That is because z86VM takes advantage of dozens of z hardware instructions that were originally released in the z196 server. IBM chose not to make them available in earlier hardware releases.

Today, we must inform you of storage restrictions. While FBA and FCP attached storage devices are supported by z/VM, these are not presently supported by z86VM. There are also minimum storage capacity needs for z86VM to be successful.  There are two parts of storage needs: 1. The z86VM IO server file system and 2. The z86MNT 191 CMS Disk that is used to stage the product and copy it into the IO server.

With the z86VM IO server, we can support any ECKD storage device sizes. Multiple disks can be strung together to create a single larger file system. x86 operating systems that are larger than a single ECKD device can logically span multiple devices in the IO file server. If someone would like to use 3390-3 devices for the IO Server, we can provide documentation as to how to do that.

The issue or restriction is a small z86MNT 191 disk cannot host the original files shipped from Mantissa to customers. We have looked at several technical solutions from Mantissa, but none are currently in our Beta release plans. The alternative for a customer is to acquire a larger storage device or reconfigure an existing storage subsystem to meet the capacity requirements for the z86MNT 191 disk needs.

If there are existing beta customers that are experiencing this constraint, please send a note to z86vm@mantissa.com with z86VM Beta in the subject line so we can better understand your requirements.

Beta Update for June 11

As mentioned yesterday, the network conflict problem was solved. Beta customers that joined today, have no changes to make. Unfortunately, everyone else should make a change if you want multiple systems to run simultaneously.

Changes for sites that have previously downloaded

1. Download z86.exec from mantissa ftp site (binary fixed lrecl 80) to replace previous Z86 EXEC A.

2. Update the z/VM Directory to add the Additional Record  (in bold) and perform a DIRECTXA USER DIRECT

USER Z86IO   Z86IO   9G  20G  G
 INCLUDE Z86PROF
 OPTION MAXCONN 2000
 NICDEF 0100 TYPE QDIO LAN SYSTEM VSW86 MACID FFFF02
 NICDEF 0110 TYPE QDIO LAN SYSTEM VSW86 MACID FFF202
 MDISK  0195 3390 <start_cyl> 00010 <volid> MR Z86IO Z86IO Z86IO
 MDISK  0200 3390 <start_cyl> 05000 <volid> MR Z86IO Z86IO Z86IO

3. Update PROFILE Z86 on Z86MNT ID with the 2 Additional Records  (in bold)

/* */
 zio_start = Z86IO
 vnicadr =  0100
 vswitch =  VSW86
 x86hd =    0200
 zio_end =   Z86IO
z86_start =  DEMODSL
 io_server=  Z86IO
 module =  V0R3C4M  MODULE   A
 vncport =  2001
 vnicadr =  0110     /* Add this record */
 pcimage =  dsl.img
 VMIMAGE = DSL0602  IMG      A
 z86_end =  DEMODSL
z86_start =  SME8
 io_server=  Z86IO
 module =  V0R3C4M  MODULE   A
 vncport =  1999
 vnicadr =  0100     /* Add this record */
 pcimage =  sme.img
 vmimage =  SME8    IMG   A
z86_end =  SME8

4. In the original post, we neglected to inform you that you must issue z86 (DEFINE=ALL in order for these changes to take effect. You could also issue z86 (INSTALL, but that command will take more time to execute.

5. Now you can issue z86 (START=ALL and the network conflict should be resolved.

z86VM Beta 3 Update for June 10

First, I want to congratulate Ed S. for being the first customer to send us a picture of the VNC console. Unfortunately, it was for diagnostic purposes, but he got the DSL system booting up. Thanks Ed for the valuable feedback that you’ve given us. We appreciate it. We’d love to see status and updates from anyone else too.

On June 4, we told you about a problem in item #3 about the mutually exclusive nature of SME and DSL. We’ve solved the problem, but haven’t finished documenting it yet. There are two set up changes to make. There were no code errors and the net effect is the system is easier to manage with the changes. We hope to have them documented by tomorrow.

However, in the mean time, there is a simple work around. Instead of issuing z86 (start=all  – which creates the problem, change it to z86 (start=demodsl  and just boot up the dsl image.

You could also do z86 (start=1  and it will boot up which ever image is first in your PROFILE Z86. BTW, if you were ever wondering why we’d have a command like that – start the first xxx number in the profile, it is for benchmark purposes. We have several hundred users defined in our PROFILE, all clones of each other. Given the hardware that we are running on at the time, we can start a given number to do the benchmark. The alternative would be to issue the command naming every user….it wasn’t worth doing 🙂

There’s a few other things that will be forthcoming. We presented at the Marist College hosted Enterprise Computing Conference yesterday. We did a 15 minute presentation followed by a 15 minute demo. It was a terrific audience response. But more importantly, we got asked a lot of tactical and strategic questions. We’re going to add those to the FAQ section over the next couple of days. When we’re done, we’ll post the update here. But who knows, we may add a few now, some later, etc. Check back if you’d like.

Personally, I’m going to this blog a lot to update it, but we didn’t include a link to the blog on the home page, so it’s either a bookmark or a double click. That’s on my list to fix.

Finally, we got some comments about the Operations Manual. Some questions about examples that describe z860001 userid, when you readers were looking for DEMODSL or SME8. Sorry about that. That’s a little bit of internal Mantissa stuff getting through. We have a collection of operating systems at various software levels that we boot. Changing your zVM userid is a pain. So we’ve been using a naming convention of z86001, z86002…..Someone else has z86D01, D02, etc. I have four z/VM userid’s but about 15 OS’s defined in my PROFILE Z86. Rather than delete a profile entry, I comment it out. So today, D01 could be SME and tomorrow, it’s DSL and the next day, it’s SME with WordPress. It all depends on what we are testing that day.

So anyway, we’ll correct the manual toward what we shipped in the Beta code. However, like any z/VM userid, you can name them anything you want. But if you do change them in z/VM, don’t forget to update your PROFILE Z86 file.

 

 

Customizing SME server to operate WordPress

Customizing SME server to operate WordPress. When Beta 3 shipped, the SME 8.1 server included the LAMP Stack: Linux, Apache, MySQL and PHP. It also included a pre-configured WordPress with a sample web page. By this time, we expect you’ve modified your IP address to start your SME system and have it network connected. Unfortunately, the WordPress options have a copy of the Mantissa based IP address. Follow the directions on this short document to update and display WordPress on your Beta copy. https://www.mantissa.com/dotcom2020/wp-content/uploads/2014/06/Wordpress.Sample.pdf

z86VM Beta 3 Update for June 5, 2014

z86VM Beta 3 Update for June 5, 2014.

1. Yesterday, we spoke of a problem with the mutually exclusive nature between SME and DSL. Our crackerjack staff solved that, but there are some installation changes to be made. In particular, the USER DIRECT definition of the IO server z/VM guest needs some modification and a new variable needs to be added or used for a z86VM user definition in PROFILE Z86. The Operations Manual has been updated in both sections 3. Define z86VM userids on page 29 of the current manual and in Appendix C in the Troubleshooting Guide.

2. Two other areas of potential concern were added to Appendix C – Troubleshooting Guide. If you see a lot of NIC related messages on any z/VM guest, they were put there to assist the z86VM developers. While they may appear to be ominous, have no fear, they are just making your screen beep when it scrolls to the next page. In the other area, the first time you operate SME Server-Manager from a web browser, you may be presented with an even scarier message that this system may not be trusted. Again, that’s because the beta code was built on a Mantissa machine and a digital certificate was grabbed from there. Now that it’s on your system, the digital certificate doesn’t match. Add the exception for now, as this is only Beta. For a real production environment, you’d want to make sure this was your digital certificate mapped to this particular system image. We’ll update how to to that as we approach General Availability.

3. Thanks to those that provided some nice feedback on the Beta so far. For those others attempting to install, again, any problems, don’t hesitate to ask via comment here or email us at support@mantissa.com.

 

Beta 3 update – June 4, 2014

Beta 3 update – June 4, 2014. We’ve got a couple of changes to tell you about that occurred after Beta 3 shipped.

1. Original email message suggested that you download via FTP the following file: z86VM.direct.txt   That was incorrect. It should be z86vmb3.direct.txt.

2. During the FTP process, the simplest means would be to run the FTP client directly from a z/VM session. However, we’ve found that doesn’t work. We aren’t sure if it is the FTP client on z/VM (which is our suspicion) or our FTP server. However, our FTP server does work from Windows and MacOS based systems. So what you’ll need to do is FTP from your desktop and then once downloaded there, upload them via FTP PUT commands to your z/VM system.

Each of the above have been updated in our opening email, the web site and the Operations manual available on the web site.

3. There seems to be a problem when attempting to run both the DSL and SME images on different virtual machines with the same IO server. SME requires a “hardened” mac address and the trouble shooting guide in the Appendix  C describes how to modify the system to do that. However, we didn’t realize the mutually exclusive nature of the two different Linux OS’s. This is not a proper behavior. We are looking into the solution for that now.

4. In the known problems area, we told you that Firefox that ships with DSL hasn’t been working for us. What we neglected to tell you is that Opera does work. On the DSL Desktop, you’ll see an O icon on the lower left side of the collection of desktop icons. Click on that to enjoy the Opera Browser.

5. Some customers have asked for some capacity planning and set up guidance for the different z/VM images used. Here’s how we’ve set up our images at Mantissa:

Page 29 of the Operations doc recommends 20,000 3390 cyls.

We have the following VM definitions for Beta 3:

Each x86 ID is defined with 6 Gig memory and a 10 cyl boot drive. (The 194 drive)

The I/O ID is defined with 9 Gig memory and a 10 cyl boot drive. (The 195 drive)  The x86 hard drive space (UDM) is defined on the I/O ID.  Beta 3 defines it as 10k Cyls.

The maint ID is defined with 1 Gig memory and a 10k Cyl A-disk.

We’ll update our online doc with this information within 24 hours.

z86VM Customers – Please subscribe to the z86VM category

z86VM Customers – Please subscribe to the z86VM category. With any Beta, changes will occur. We’ve already encountered a few gotchas with Beta 3 that you should be aware of when installing and operating your systems. The z86VM category will be used to communicate any latest news to the Beta customers. We will not be posting those updates to the home page.

z86VM Beta 3 Shipping now

z86VM Beta 3 is shipping now. Come and get it. Go to our order page and get your copy….But we aren’t done either. Performance improvements, Capacity planning guidance, Benchmarking activities and more code exploitation examples are just some of the things we are working on toward making this a successful and viable product. We need your feedback to help us prioritize those activities. We are dedicated to helping you successfully get through installation and attempt to do proof of concepts of your own.