Dundee is now XenServer 7.0!

Standard

The image above – from Sega’s Zillion – shaped mine and my brother’s lives.

I often make reference – internally or externally – to these hosts, but no one has ever asked “Whom do you speak of?”

Now you know.


A big congratulations is in order to XenServer PM, Dev, QA, Tim, and every single one of you who have participated from Dundee’s first Alpha drop to its official release as XenServer 7.0!

I direct much thanks to Tim for various reasons.  Mostly to pick on him as, despite being at Synergy amongst Tobias, David, Carl, and so many other great hooligans, he found a way to yet keep all of us up-to-date via XenServer.org:

It was a little over a year ago when I introduced a project code named Dundee to this community. In the intervening year, we’ve had a number pre-release builds; all introducing ever greater capabilities into what I’m now happy to announce as XenServer 7. As you would expect from a major version number, XenServer 7 makes some rather significant strides forward, and defines a significant new capability.

Tim’s typing marches on with melodic precision and before ending on my favorite part – the download – we get this luscious piece of data to salivate over:

No major release would be complete without a requisite bump in performance, and XenServer 7 is no exception. Host memory limits have been bumped to 5TB per host, with a corresponding bump to 1.5TB per VM; OS willing of course. Host CPU count has been increased to 288 cores, and guest virtual CPU count has increased to 32; again OS willing. Disk scalability has also increased with support for up to 255 virtual block devices per VM and 4096 VBDs per host, all while supporting up to 20,000 VDIs per SR. Since XenServer often is deployed in Microsoft Windows environments, Active Directory support for role based authentication is a key requirement, and with XenServer 7, we’ve improved overall AD performance to support very large AD forests with a resulting improvement in login times.

Naturally, I was eager to quit working with internal builds and bite into the real deal yesterday evening – and that I did and am still going!  Along with run of the mill basic testing, I have already staged up a bit more for subsequent entries.

Still, an engineer is only as good as the documents he can validate to be true, so a special thanks to Mike Meyer (@AspnSys)!  While I was readily able to pull down XenServer 7.0 as any client, partner, or individual would, I could not find the documentation at support.citrix.com!

This is where Mike stepped into a Tweet I had on the wire – to assure me the docs were indeed under docs.citrix.com, albeit it wasn’t where we expected it quite to be.

Lots of moving parts during Synergy, so hey — it saved me from calling people as to prevent my own panic with ensuring each of you has the right resources for this release.  Thanks, Mike!

By now, XenServer 7.0 and components can be downloaded directly from

https://www.citrix.com/downloads/xenserver.html

or

http://xenserver.org/open-source-virtualization-download.html

Such a backstory!

Well, it is finally behind us and already I have began my own local testing:  the usual stuff that consumers (such as myself) would tackle.  Sure, I had a head start with the release materials this morning, but colleagues, partners, and clients come first on a daily basis.

Sleep can be overrated, especially with a release hot of the presses.

Now that I’ve been home since 19:00 EST, I wanted to blog my lesser escapades with XenServer 7.0 and what I’ve done with my trinity of machines known as…

JJ, Apple, and Champ!


Champ Steps It Up…

With Apple on SAN duty to my brother and JJ running my home resources, I picked on good champol’ Champ.  He’s sturdy, a bit bulky, but powerful and with the power at my hand, I literally had to remind myself Golden Rule #2 with XenServer:

Download The Latest XenCenter Before Upgrading ANY XenServer Host(s)

No, seriously.  People think I make this up and understandably so.  It’s a client utility, right?  Yes, it really is for the most part, but it drops slap-dash “client bit” for a more aggressive “go-between” during migrations, server status reports, and most of all…

Upgrades (especially if a Rolling Pool upgrade is performed or if one is migrating VMs back-and-forth among pool members).

“What is Golden Rule #1 regarding XenServer?” you may ask.

Download The Product Documentation & Read It!

Seriously, now.  Don’t get sensitive on me!  I am just as guilty as skimming through instructions, literature, and studying.  I am trying to advise, to help, and to work through this with you.
Now, let’s take a quick recap as to ensure we are ready to approach an existing installation or a fresh, brand new Type 1 Hypervisor Environment:


oldfloppySave the Plastic!  Boot from USB!

Indeed, if you have the opportunity to, use a USB Thumb drive and a free utility – such as Rufus for Windows or UNetbootin (or DD) for Linux – to take the ISO file and explode it onto a USB thumb drive (1GB or larger).

If you don’t know how to use these tools or would like more information, specifically regarding XenServer 7.0 with Rufus, UNetbootin, or DD, please let me know!


Test 1: XenServer Health Check

After downloading the latest XenCenter and subsequently installing it (or upgrading my existing XenCenter), I found all of my XenServer hosts to be clearly visible.  Of course – per documentation – the latest XenCenter is not backwards compatible with pre-6.x versions of XenServer.

Sure, I had to disable (again) the RDP pop-up option that is apparently set back by default, but hey — not really a big deal as this is what made me smile:

enrollnow

As part of a long standing “call home” feature, which is truly for the customer experience, I was happy to see a feature I had tested before present itself in its anticipated glory!  The Health Check utility!

You don’t have to enroll, but if you have support or use https://cis.citrix.com on any basis to check the status of a pool or a stand-alone host, this nifty utility will allow you to schedule automatic uploads of server status reports as so you can gain insight into your XenServer deployment: updates, preventative patches, etc.

The great part of this feature is that while Champ was currently running 6.5 SP1 and JJ is still running 6.2 SP1, I could enroll them both for automatic uploads or I could still run manual server status reports… with a great option to simultaneously send a copy to CIS (along with a Citrix Support case number)… and that makes me – an employee and customer – quite content.

As a quick example of the normal server status report process, all looks the same until the final step where it not only saves the report for myself (locally), but it asks if it should also upload the report to CIS (this test comes from JJ, but is also the same for 6.5 SP1 and 7.0 XenServer hosts):

62healthcheck

I like it.  I’m biased as I contribute as much as I can to the CIS team, so again, great work to everyone involved.


Test 2: The Upgrade

Champ had a few VMs I had been testing with: each VMs virtual disks contained within Local storage for my own nefarious purposes:

champ1

I don’t want to lose these guys, however if you have read the Installation Guide for XenServer 7.0, you will know that one of the new features is GPT partitioning.  It offers a larger capacity for the root installation along with a separate partition for /var/log/.  In short, a better disk layout to prevent system logs and patches from filling up the XenServer root partition.

Per the documentation, if VMs or any VHD/VDI are held on Local storage the upgrade process won’t use GPT partitioning (https://docs.citrix.com/content/dam/docs/en-us/xenserver/xenserver-7-0/downloads/xenserver-7-0-installation-guide.pdf, Page 12):

takewarning

(Now you can see why I am such a fan of documentation!)

Instead of the new 18GB disk layout with /var/log/ (4GB) split into its own partition, I temporarily had an upgraded XenServer 7.0 host ready to rock, however it still had a root partition size of 4GB:

[root@CHAMP ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       3.5G  2.2G  1.1G  67% /
devtmpfs        319M     0  319M   0% /dev
tmpfs           329M   36K  329M   1% /dev/shm
tmpfs           329M  976K  328M   1% /run
tmpfs           329M     0  329M   0% /sys/fs/cgroup
xenstore        329M     0  329M   0% /var/lib/xenstored
/dev/loop0       55M   55M     0 100% /var/xen/xc-install
tmpfs            66M     0   66M   0% /run/user/0

So, in planning for a fresh install, I exported those VMs to USB-based storage and deleted the originals from Champ: freeing local storage of any VDI/VHD files, etc as to ensure that on my next effort – a clean install – I get the benefit of GPT partitions and I can import my VMs back to Local storage.

I get my Xen and my Virtualization, too…


Quick Note!

With the release of XenServer 6.5, on installation the bare metal host’s total RAM is taken into consideration.  The purpose of this is to set – for new installs only – the dom0 memory allocated (instead of the old 752M limit) to a higher value.

The same holds true with XenServer 7.0 on fresh installation.  The breakdown of total host RAM to how much DOM0 memory is allocated on a fresh install is as follows:

Total Host Ram    -->     DOM0 Memory Allocation
24GB (or less)            752M
24 - 47GB                 2048M
48 - 63GB                 3072M
64 - 1024                 4096M

For XenServer deployments running 6.5 or greater, at least 8192M is recommended if the memory caching feature is licensed/enabled.


Test 3: The Fresh Install

After exporting my VMs, I completed a fresh install.  Upon re-connecting, I enrolled Champ into the Health Checker and immediately checked the disk partitioning for XenServer’s root:

[root@CHAMP ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        18G  1.8G   16G  11% /
devtmpfs        319M     0  319M   0% /dev
tmpfs           329M   36K  329M   1% /dev/shm
tmpfs           329M  992K  328M   1% /run
tmpfs           329M     0  329M   0% /sys/fs/cgroup
xenstore        329M     0  329M   0% /var/lib/xenstored
/dev/loop0       55M   55M     0 100% /var/xen/xc-install
/dev/sda5       4.0G  138M  3.7G   4% /var/log
tmpfs            66M     0   66M   0% /run/user/0

And Presto!  I now have a 22GB GPT partition setup: 18GB dedicated to literal /root and 4GB dedicated to /var/log/!

Within XenCenter, one of my favourite features is that of the “Open SSH Console” as Putty comes with XenServer/XenCenter 7.0.  It works for not only the control domain/dom0, but also for Linux guests when an SSH port is detected:

openssh

Much like the “Remote Desktop” button for Windows guest VMs (or Linux VMs with XRDP installed), we simply click it and login:

putty

I did find that in /var/log/, the messages file was at 0 bytes — not growing.  This has been reported, so for me, the work around was simply to add the following to /etc/rsyslog.d/xenserver.conf between local 5 / v6d logging:

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

This was taken from /etc/rsyslog.conf and is something I am actively investigating as once this is added to /etc/rsyslog.d/xenserver.conf, for the changes to take affect we simply can execute:

[root@CHAMP log]# service rsyslog restart
.... and we start to see /var/log/messages growing:
[root@CHAMP log]# ls -la /var/log/messages
-rw-------  1 root root      602 May 25 04:38 messages

Since logrotate is responsible for the rotation, as well as other configurable options to apply to Syslog-based file handling, one may notice that /etc/ has two logrotate configuration files:

[root@CHAMP log]# ls -la /etc/logrotate*conf
-rw-r--r-- 1 root root 591 May 25 04:14 /etc/logrotate.conf
-rw-r--r-- 1 root root 849 May 11 06:05 /etc/logrotate-xenserver.conf

The reason to point this out is that the larger of the two, /etc/logrotate-xenserver.conf, does not have compression or other options enabled.  So, running logrotate from the command line (manually), I have found the former config file to be optimum:

[root@CHAMP log]# logrotate /etc/logrotate.conf

This version of the config /etc/logrotate.conf contains the following options:

# see "man logrotate" for details 
missingok

# The compressed files are deleted by another script, based on total disc use.
# Therefore for logrotate we specify a large number.
rotate 9999

# create new (empty) log files after rotating old ones
create

# Use sharedscripts for efficiency: if we rotate several files that are written
# by the same process, send it SIGHUP just once. For syslogd this causes a
# restart, which the man page says is expensive.
sharedscripts

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
        minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.
[root@CHAMP log]# cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files daily
daily

# keep one months worth of backlogs
rotate 31

# create new (empty) log files after rotating old ones
create

# compress log files
compress
delaycompress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
        minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.

Not only does this have sane options, but the head of the file clearly specifies something I believe many XenServer administrators already know:

# The compressed files are deleted by another script, based on total disc use.
# Therefore for logrotate we specify a large number.
rotate 9999

There are two such background scripts which run – all the time – to prevent Syslog data files from growing out of control.  I don’t mean “check periodically”.  I truly mean we have checks and balances to prevent any sort of flooding as it relates to Syslog data so that, in an odd situation, the files never grow wildly out of control…. especially if logs are being forwarded to another host.

Similar checks have been in place before, but with the 4GB total installation size, these scripts were rather ineffective, but until I do more research into this final implementation of system logging I want to hold off on any speculation.

To me, it simply looks like an appearance of “duplicate” configuration files, where as they probably are more or less for reference.

I will certainly be testing my log generator today as it is quite about time to hit the office, anyway.


Test 4: VMs and Stuff

This will be updated later today as with lsof and other tools being installed within dom0, I am quite certain I can get some nifty “Tobias Style” metrics out of a SOHO XenServer 7.0 system with a few Windows and Linux guest VMs!


Test 5: Miscellaneous

(Updating)

 


In Summary…

XenServer rocks and I thank everyone from my colleagues to YOU for allowing me to work with something so amazing!

 

–jkbs | @xenfomation | XenServer.org | My Blog

 

 

Advertisements

One thought on “Dundee is now XenServer 7.0!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s