Booting a ESXi VM from a .iso in a NFS share

First time I created a VM in Vmware's ESXi, I placed the .iso containing the install image of the operating system in the host I run vsphere client from. And then told the VM where to get that. Some info on this procedure can be fount at http://community.spiceworks.com/topic/332810-create-vm-from-iso-without-uploading-to-datastore. At first glance, it seemed to be quick and easy; I would even add for a small deployment it is quite convenient. However, but it was just cumbersome (too many hoops to make that work) and slow (it expects the vsphere box to be in a fast and reliable connection to the ESXi one, which might not be the case). It really makes sense to have the images either in the server itself or mounted on the server (fileshare). I was not looking forward to having the images in the server itself because:

• It would probably require me to download them somewhere else and then upload to the server. That does not sound like a dealbreaker to most since if I can ssh into my ESXi, which I do, I can scp the files into it. Well, I do not believe on having a single device/program/app/thingie that does it all; you see, I do like the Rule of Simplicity from the Unix Philosophy. And that dovetails to the next item:
  
• I have a perfectly good fileserver (ok, a Synology NAS box) thank you verymuch. Many of my VMs already NFS mount shares from it, or just have their entire disk in an iSCSI LUN from said NAS.
  
• I might want to use those images with my other vm host, which runs KVM.
  

What I want is maybe a NFS share that can be mounted somewhere where I can download the .iso files to and then have it available read-only to the vm hosts (ESXi, KVM/libvirt, Vbox). Let's see if we can make that happen, shall we?

Setup

We first need to begin with the fileshare itself. It is being exported read-only as a NFSv4 fileshare from the NAS; we won't go over how to do that in this discussion. Since I could not find showmount or even mount in ESXi, let's assume I know what I am doing and believe the share I want is fileserver.example.com:/public (I cheated and verified in a Linux box). We can add that to vmhost2 using the vsphere client:

Using the ISO

So now we did all this boring work, let's see if we can boot using a, well, boot .iso from the NFS share. So, On the vsphere client

• Select the vmhost. In my case that is vmhost2.
  
  1. Select Configuration->Storage in the Hardware panel.
     
  2. Click Datastores and click Add Storage.
     
     
  3. Select Network File System and click Next.
     
     
     

  4. Enter
     
     

     • server name: fileserver.example.com
       
     • mount point folder name: /export/public (yep NFS3)
       
     • [x] Mount NFS read only
       
     • datastore name: public
       

  And that should result in a new datastore entry called public.
• Select the vm client, which is called devcentos.
  
  1. select the vm in question, devcentos:
     
  2. Edit virtual machine properties->CD/DVD->Device Type->Datastore ISO File
     
  3. Hit Browse
     
  4. Datastores->public->ISOs->CentOS.iso
     
  5. Boot to BIOS. For some reason I have to manually select which device to boot. Even though most of the time the virtual hard drive is completely virgin, the bios does not failover to the ISO, Maybe that has been solved by now, but just learn this step... just in case.
     
  6. Turn CD player on on boot
     

References

https://communities.vmware.com/thread/456682

What that orange alarm LED light in a Juniper SRX router is trying to tell me?

If you have a Juniper SRX router thingie, you might have noticed the orange light glowing on it:

It is the alarm light, and could have been triggered by many reasons, like the one mentioned in http://unixwars.blogspot.com/2015/08/juniper-srx-router-booted-from-backup.html>later post. On its defense, it is nice to know the silly router is upset about something. And, it sure beats a blinking 200W light or a blaring air raid siren. Still, it is staring at me with its deep unmoving orange eyes demanding attention. So, let's do some probulating, shall we?

When I asked it what's up, this is what it told me:

root@uranus> show system alarms 
2 alarms currently active
Alarm time               Class  Description
2014-03-23 10:42:35 EDT  Minor  Autorecovery information needs to be saved
2014-03-23 10:42:33 EDT  Minor  Rescue configuration is not set

root@uranus>

After I saw that, it hit me like a, er, something heavy (please come up with something more original than the usual ton of bricks. I have never been hit by one and plan on staying that way) and unyielding: about that time I did a full wipe and reinstall! So, since it is being so nice to tell us what it wants, let's see about pleasing it. If we look at this thread in the juniper forums, we see the command to save the rescue configuration is:

root@uranus> request system configuration rescue save 

root@uranus> show system alarms                          
1 alarms currently active
Alarm time               Class  Description
2014-03-23 10:42:35 EDT  Minor  Autorecovery information needs to be saved

root@uranus>

One down, one to go. Now, how to save the autorecovery info? I am going to punt and assume the command should be very similar to the one we used to save the rescue info. Like Cisco's IOS, you can use ? to see which arguments a give command take. So, we try

root@uranus> request system configuration ?    
Possible completions:
  rescue               Request operation on system rescue configuration
root@uranus> request system ?                 
Possible completions:
  autorecovery         Manage autorecovery information
  certificate          Manage X509 certificates
  configuration        Request operation on system configuration
  download             Manage downloads
  firmware             Upgrade or downgrade firmware
  halt                 Halt the system
  license              Manage feature licenses
  logout               Forcibly end user's CLI login session
  power-off            Power off the system
  reboot               Reboot the system
  scripts              Manage scripts (commit, op, event)
  services             Request service applications information
  set-encryption-key   Set EEPROM stored encryption key
  snapshot             Archive data and executable areas
  software             Perform system software extension or upgrade
  storage              Request operation on system storage
  zeroize              Erase all data, including configuration and log files
root@uranus> request system ?

Aha, we found autorecovery. Which arguments does request system autorecovery take?

root@uranus> request system autorecovery ?  
Possible completions:
  state                Manage autorecovery state information
root@uranus> request system autorecovery state ?
Possible completions:
  clear                Delete previously saved autorecovery state
  recover              Check for problems and recover state if needed
  save                 Save autorecovery state
root@uranus> request system autorecovery state ?

So it seems that request system autorecovery state save will do the trick. Let's try it then:

root@uranus> request system autorecovery state save 
Saving config recovery information
Saving license recovery information
Saving BSD label recovery information

root@uranus>

and the orange light's gone! Another mystery solved...