Everyone, please welcome my daughter Diana into the world.

She arrived at 7:26am today!

This guide assumes you already have a running Ubuntu 15.10 system on which you want to configure Xen Orchestra, everything else is documented below.

TL;DR: Run this command as root on Ubuntu 15.10...

sudo curl https://raw.githubusercontent.com/scottalanmiller/xenorchestra_installer/master/xo_install.sh | bash

---

During the installation of your OS, you'll want to create a user outside of root, I made my user account xoadmin

How to Install Xen Orchestra Source on Ubuntu 15.10 (self compiled) AKA MANUAL installation

sudo apt-get install --yes nfs-common
curl -sL https://deb.nodesource.com/setup_5.x | sudo -E bash -
sudo apt-get install --yes nodejs
curl -o /usr/local/bin/n https://raw.githubusercontent.com/visionmedia/n/master/bin/n
chmod +x /usr/local/bin/n
n stable
node -v
npm -v
sudo apt-get install --yes build-essential redis-server libpng-dev git python-minimal
git clone -b stable https://github.com/vatesfr/xo-server
git clone -b stable https://github.com/vatesfr/xo-web
cd xo-server
sudo npm install && npm run build
cp sample.config.yaml .xo-server.yaml
nano .xo-server.yaml

#Edit and uncomment it to have the right path to XO-Web, because XO-Server embeds an HTTP server (we assume that XO-Server and XO-Web are on the same directory). It's near the end of the file:
#  mounts: '/': '../home/xoadmin/xo-web/dist/
#  save and exit

cd ~
cd ../xo-web
sudo npm i [email protected]
sudo npm install
sudo npm run build
cd ../xo-server
sudo npm start

The scripted installation thanks to @scottalanmiller

Github Repo

Below is the preferred Installation method. It includes the systemctl xo-server.service written by @Danp

sudo bash
<password>
sudo curl https://raw.githubusercontent.com/scottalanmiller/xenorchestra_installer/master/xo_install.sh | bash
<password>

In your favorite web-browser go to this VM's IP Address, login with the default user: [email protected] and "admin" for the password. Update your Login Details!!

Add your Xen Server(s) and go to town.

Automatically Start XO at Boot - See this Post by @Danp Also copied below.

Create a file in /etc/systemd/system/xo-server.service and enter the below into it.

# systemd service for XO-Server.

 [Unit]
 Description= XO Server
 After=network-online.target

 [Service]
 WorkingDirectory=/opt/xo-server/
 ExecStart=/usr/local/bin/node ./bin/xo-server
 Restart=always
 SyslogIdentifier=xo-server

 [Install]
 WantedBy=multi-user.target

Save the file, and then run to enable the service at start up.

sudo systemctl enable xo-server.service

To monitor the service you can then run

journalctl -u xo-server -f -n 50

For everyone on the newer releases of the "stable build" at least as of April-8-2016 there appears to be a bug when attempting to mount an NFS share; to resolve this follow the short process below

• Login to your XO web console
• Go to Backup
• Select Remote Stores
• Add your NFS Share, it'll likely fail out(unless it's been fixed since this posting)
• Back on your XO console go to /tmp/xo-server/mounts
• Run "ls" to see what mount is listed on your server
• Next run "mount -t nfs nfs-server-ip-address:/path/to-share remote-#"

Replacing nfs-server-ip-address with the actual IP of the remote server and the remote-# with whatever is listed on your console.

Register for today's live demo April 6, 11 am PT / 2 pm ET.

Host: Alex Bykovskyi, Solutions Architect, StarWind

New StarWind Virtual SAN Free comes completely unrestricted delivering all the features you get in the commercial version. Unlike the previous free version, new VSAN Free delivers unlimited node count, features, and capacity served. It can now be used in any deployment scenario, be it Hyper-Converged, “Compute and Storage Separated”, or even a combination of both. Thanks to multiprotocol support, featuring iSCSI, SMB3, and NFS, including RDMA-capable iSER, NVMf, and SMB Direct, StarWind VSAN easily integrates into any infrastructure, be it virtualized or not. In addition, support for VVOLs, SCVMM, and ready-to-use PowerShell scripts help users to speed up and simplify automated deployment, management, and monitoring of their Virtual SAN infrastructure.

Join our Live Demo to learn how to build a completely free multi-node hyper-converged environment with StarWind and your hypervisor of choice!

*Virtualize responsibly!

Hey all!

On November 11th I'll be gaming for 24 hours straight to raise money for Golisano Children's Hospital,please hit my page up here and donate to help raise funds.

Thanks,

DustinB

@nerdydad said in Fake Wall or Wall Closet?:

Any suggestions?

Tell your CFO to stop giving tours of your server room and focus on saving money for more important things.

Messing with @Minion-Queen

I'm wondering why I don't have a tank!

Since Scott is our resident expert on said topic, I figure here would be as good a place as any to post SW articles regarding IT people who are in a position where they are unknowingly building an IPOD.

@BradfromxByte thank you for dealing with all of the back and forth and kick ass servers.

Sounds like you're using this in production, correct?

@pete-s a mix, where I currently work we ha e our own Colo and in office servers. A large number of our customers require on premise hardware for their offices, cloud servi es make sense for a lot, but not everything. Even colod workloads make little sense to a lot of our customers.

While it makes a ton of sense to move to hosted email, or even file shares, there are so many proprietary systems that business uses that aren't cloud ready.

@pete-s said in Goodbye hardware monitoring on HPE Gen10 and newer equipment running ESXi:

@dustinb3403

Unfortunately tech that goes obsolete always causes problems but it's more technically sound to monitor through the OOB management interface.

It's after all independent of the OS running on the hardware, independent of the server's NICs, independent of most hardware failures and can be used for a lot more than just monitoring.

And in any modern installation, the OOB management should have been setup and in use already.

Absolutely I agree with that, except the only OOBM that existed before OneView was Ilo and smtp emailing. Which is hardly reliable.

And I do agree that moving to an OOBM like OneView makes sense, it doesn't make sense for an ITSP to have to use though, as it's setup per customer, and would be running on the same hardware it's monitoring in most cases.

Edits are corrected typos

@scottalanmiller said in Goodbye hardware monitoring on HPE Gen10 and newer equipment running ESXi:

@dustinb3403 said in Goodbye hardware monitoring on HPE Gen10 and newer equipment running ESXi:

@voip_n00b said in Goodbye hardware monitoring on HPE Gen10 and newer equipment running ESXi:

@dustinb3403 Why?

Because you're required to setup and maintain and additional environment for it.

1 customers won't want to spend more money for something they've previously had included (by hpe) and 2 ESXi needs this functioning to report on the underlying health status.

Explain.... "Well, this happened because you are overpaying for something that you don't need and now it costs even more because they know you will pay because you are already paying just for the sake of paying. Instead of paying more, you could pay less."

And they will instantly say "oh heck no way do we want to SAVE money, spend spend spend"

What?

HPE is removing a hardware monitoring provider for VMWare (and presumably everything else). The assumption that anyone who has hardware, must be able to monitor it, ideally through their hypervisor.

Sure shifting to monitoring through the hardware interface, such as ILO or OneView but these approaches add yet another administrative panel that must be used and managed and maintained.

@voip_n00b said in Goodbye hardware monitoring on HPE Gen10 and newer equipment running ESXi:

@dustinb3403 Why?

Because you're required to setup and maintain and additional environment for it.

1 customers won't want to spend more money for something they've previously had included (by hpe) and 2 ESXi needs this functioning to report on the underlying health status.

@voip_n00b said in Goodbye hardware monitoring on HPE Gen10 and newer equipment running ESXi:

@dustinb3403 It’s free and has more functionality.

For a standalone environment, it is not msp/itsp friendly.

@voip_n00b said in Goodbye hardware monitoring on HPE Gen10 and newer equipment running ESXi:

@dustinb3403 who cares. This is what the iLO Amplifier Pack is for. Just use that. It even automatically opens tickets with HPE.

You clearly don't support customers.

"Hey those new servers that were easy to monitor and support, yeah well now all of that is gone. But you can buy this other thing to get a tiny portion of the functionality back."

@scottalanmiller said in Goodbye hardware monitoring on HPE Gen10 and newer equipment running ESXi:

@dustinb3403 said in Goodbye hardware monitoring on HPE Gen10 and newer equipment running ESXi:

@dashrender said in Goodbye hardware monitoring on HPE Gen10 and newer equipment running ESXi:

Good thing no one here runs ESXi..

Sure and none of us support it either.

....

Just like HPE. jajaja

That is actually a good one

@dashrender said in Goodbye hardware monitoring on HPE Gen10 and newer equipment running ESXi:

Good thing no one here runs ESXi..

Sure and none of us support it either.

....

So this will definitely impact some if not all of you, but all Gen 10 and newer HPE Servers with hardware RAID, running ESXi will no longer be able to monitor the drive or array's health. Below I'm quoting Mario Glenwin from L2 Technical Solutions Consultant from HPE.

We received a confirmation from engineering team. Smx-provider package is set to retire and we are recommending customers to remove the same going further.
There is no additional development/research happening on smx-provider.

Engineering team have recommended that we could monitor drives from ILO/AMS and One View if configured.

Support article for the recommended fix: https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00117054en_us

With 3.53 or newer raid controller firmware on Gen10 or newer servers you can expect to see misreported issues like the ones pictured below.

HPE's current officially recommended solution to prevent seeing these errors is to uninstall the SMX-Providers from within ESXi. Unfortunately VMWare and HPE documentation lists the smx-provider as the solely supported way to monitor storage.

https://www.vmware.com/resources/compatibility/pdf/vi_cim_guide.pdf

You could of course move to HPE OneView or potentially use ILO to email alerts out of an individual server but there are far more fault domains then getting directly reported from the tooling on the Hypervisor (in this case VMWare).

I've been in conversations for months now about this with HPE and it appears that this is likely not going to change for the better.