XenServer Hotfix XS65ESP1035 Released

icon_download
Standard

News Flash: XenServer Hotfix XS65ESP1035 Released

Indeed, I was alerted early this morning (06:00 EST) via email that Citrix has released hotfix XS65ESP1035 for XenServer 6.5 SP1.  The official release and content is filed under CTX216249, which can be found here: http://support.citrix.com/article/CTX216249

As of the writing of this article, this hotfix has not yet been added to CTX138115 (entitled “Recommended Updates for XenServer Hotfixes“) or, as we like to call it “The Fastest Way to Patch A Vanilla XenServer With One or Two Reboots!”  I imagine that resource will be updated to reflect XS65ESP1035 soon.

Personally/Professionally, I will be installing this hotfix as, per CTX216249, I am excited to read what is addressed/fixed:

  • Duplicate entry for XS65ESP1021 was created when both XS65ESP1021 and XS65ESP1029 were applied.
  • When BATMAP (Block Allocation Map) in Xapi database contains erroneous data, the parent VHD (Virtual Hard Disk) does not get inflated causing coalesce failures and ENOSPC errors.
  • After deleting a snapshot on a pool member that is not the pool master, a coalesce operation may not succeed. In such cases, the coalesce process can constantly retry to complete the operation, resulting in the creation of multiple RefCounts that can consume a lot of space on the pool member.

In addition, this hotfix contains the following improvement:

  • This fix lets users set a custom retrans value for their NFS SRs thereby giving them more fine-grained control over how they want NFS mounts to behave in their environment.

Source http://support.citrix.com/article/CTX216249

So….

This is storage based hotfix and while we can create VMs all day, we rely on the storage substrate to hold our precious VHDs, so plan accordingly to deploy it!

Applying The Patch Manually

As a disclaimer of sorts, always plan your patching during a maintenance window to prevent any production outages.  For me, I am currently up-to-date and will be rebooting my XenServer host(s) in a few hours, so I manually applied this patch.

Why?  If you look in XenCenter for updates, you won’t see this hotfix listed (yet).  If it was available in XenCenter, checks and balances would inform me I need to suspend, migrate, or shutdown VMs.  For a standalone host, I really can’t do that.  In my pool, I can’t reboot for a few hours, but I need this patch installed, so I simply do the following on my XenServer stand-alone server OR XenServer primary/master server:

Using the command line in XenCenter, I make a directory in /root/ called “ups” and then descend into that directory because I plan to use wget (Web Get) to download the patch via its link in http://support.citrix.com/article/CTX216249:

[root@colossus ~]# mkdir ups
[root@colossus ~]# cd ups

Now, using wget I specify what to download over port 80 and to save it as “hf35.zip”:

[root@colossus ups]# wget http://support.citrix.com/supportkc/filedownload?uri=/filedownload/CTX216249/XS65ESP1035.zip -O hf35.zip

We then see the usual wget progress bar and once it is complete, I can unzip the file “hf35.zip”:

HTTP request sent, awaiting response... 200 OK
Length: 110966324 (106M) [application/zip]
Saving to: `hf35.zip'

100%[======================================>] 110,966,324 1.89M/s   in 56s     
2016-08-25 11:06:32 (1.90 MB/s) - `hf35.zip' saved [110966324/110966324]
[root@colossus ups]# unzip hf35.zip 
Archive:  hf35.zip
  inflating: XS65ESP1035.xsupdate    
  inflating: XS65ESP1035-src-pkgs.tar.bz2

I’m a big fan of using shortcuts – especially where UUIDs are involved.  Now that I have the patch ready to expand onto my XenServer master/stand-alone server, I want to create some kind of variable so I don’t have to remember my host’s UUID or the patch’s UUID.

For the host, I can simply source in a file that contains the XenServer primary/master server’s INSTALLATION_UUID (better known as the host’s UUID):

[root@colossus ups]# source /etc/xensource-inventory 
[root@colossus ups]# echo $INSTALLATION_UUID 
207cd7c1-da20-479b-98bc-e84cac64d0c0

With the variable $INSTALLATION_UUID set, I can now expand the patch and capture it’s own UUID:

[root@colossus ups]# patchUUID=`xe patch-upload file-name=XS65ESP1035.xsupdate`
[root@colossus ups]# echo $patchUUID
cdf9eb54-c3da-423d-88ca-841b864f926b

NOW, I apply the patch to the host (yes, it still needs to be rebooted, but within a few hours) using both variables in the following command:

[root@colossus ups]# xe patch-apply uuid=$patchUUID host-uuid=$INSTALLATION_UUID
    
Preparing...                ##################################################
kernel                      ##################################################
unable to stat /sys/class/block//var/swap/swap.001: No such file or directory
Preparing...                ##################################################
sm                          ##################################################
Preparing...                ##################################################
blktap                      ##################################################
Preparing...                ##################################################
kpartx                      ##################################################
Preparing...                ##################################################
device-mapper-multipath-libs##################################################
Preparing...                ##################################################
device-mapper-multipath     ##################################################

At this point, I can back out of the “ups” directory and remove it.  Likewise, I can also check to see if the patch UUID is listed in the XAPI database:

[root@colossus ups]# cd ..
[root@colossus ~]# rm -rf ups/
[root@colossus ~]# ls
support.tar.bz2
[root@colossus ~]# xe patch-list uuid=$patchUUID
uuid ( RO)                    : cdf9eb54-c3da-423d-88ca-841b864f926b
              name-label ( RO): XS65ESP1035
        name-description ( RO): Public Availability: fixes to Storage
                    size ( RO): 21958176
                   hosts (SRO): 207cd7c1-da20-479b-98bc-e84cac64d0c0
    after-apply-guidance (SRO): restartHost

So, nothing really special — just a quick way to apply patches to a XenServer primary/master server.  In the same manner, you can substitute the $INSTALLATION_UUID with other host UUIDs in a pool configuration, etc.

Well, off to reboot and thanks for reading!

 

-jkbs | @xenfomationMy Citrix Blog | XenServer.org

To receive updates about the latest XenServer Software Releases, login or sign-up to pick and choose the content you need from http://support.citrix.com/customerservice/

 


Sources

Citrix Support Knowledge Center: http://support.citrix.com/article/CTX216249

Citrix Support Knowledge Center: http://support.citrix.com/customerservice/

Citrix Profile/RSS Feeds: http://support.citrix.com/profile/watches/

Original Image Source: http://www.gimphoto.com/p/download-win-zip.html

Command Line… Gibberish?

bashoutput
Standard

UPDATE — Thanks to Val for informing me I had typed my own gibberish during my haste to write this quick article.  Another beer owed.

There you are.  Typing away and the 1990’s BBS-Style character set explodes all over your screen.  Absolute.  Complete.  Gibberish.

garbled

The answer to resolving this situation is short and sweet.  More importantly, it isn’t XenServer specific, but applicable to all Linux/*NIX operating systems.


The Solution

Though you won’t be able to see the “English” equivalent, press ENTER a few times.  Really get in there and pound that key.

Then, stare at the keyboard as to type the following command (and then pounding that ENTER key):

reset

This will do just that — “reset” BASH, or in general, console you are working from.  An example of myself typing “reset” blindly appeared as this:

garbled2

After I typed (what I hoped) was “reset” (followed by the enter/return key), presto — probability restored:

garblednomore

 

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

CIS and Your Data

gardner
Standard

*** Image from www.cs.uiowa.edu


While this quick blog is not meant to detract from my current blog work for XenServer 7.0 nor focus on Burroughs, it is a pleasant reminder of how I ended up within this hobby-turned-career industry.

Long live MCP.

End of line.


No Big Data Cliché

Speaking for myself…

XenServer is my principle product, but I am involved in so many great teams, projects, and other works my colleagues and I (even in open source) simply call “Reality of Logic, Tangible Solutions”.

One such project, known by many names before, is that of CIS.  You know: the place CDF Traces, Server Status Reports, Wireshark/PCAP files, and other forms of product/environmental data are uploaded to for analysis.

https://cis.citrix.com

I raise attention to it as, thanks to everyone from Citrix employees to the Good Samaritans on the Social Spheres or mailing lists, one problem can become a readily identifiable issue for hundreds of other end users.

That is an amazing thing if you think about.  Seriously, put aside a frustrating case that through data, securely uploaded to CIS, was determined to be caused after manual investigation of your logs.

This information feeds back into CIS as so others with the same issue can get optimum, world-class support to ensuread the next client gets back into their job and off the phone.

The inverse scenario I am setting up is that myself, clients, or other resources may have leveraged CIS at some point and a detection tool was written: one which solved your issue quickly.

With each release of Citrix products, more and more work is being done to not make a user experience a reactive one, but a proactive one…

As a member of the CIS team who writes code late at night to ensure not one more client encounters a small or complicated issue, I have state that:

“We want to solve your issue. WE WANT DATA.  We want want the customer experience to be as epic as possible so you prosper.”

In the case of XenServer 7.0, enabling or enrolling through the Health Check feature is just one example, for one product, that can make all the difference.

The data is kept securely, it is archived out every 17-25 days (depending on the product), but we thank you for that information and ask you keep the data streams coming in.

You don’t even have to be a customer to upload manual log files — I know as I have my own account that ties into my home lab. This allows me to separate consulting issues from my own personal testing and findings as to contribute new plug-ins for  CIS and enriching the Citrix Support Experience.

Thanks to the millions who have already contributed to their success and to ours by simply opting into the customer experience programs or ensure we, as a team, have the data in qualified hands to streamline products to keeping you informed in a technological landscape that is the next state of distributed computing.

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

Dundee is now XenServer 7.0!

zillion
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

 

 

Mageia and XenServer Tools?

mageia4
Standard

** The header image is borrowed from Mageia 4’s desktop theme


Requests are so much more interesting…

I certainly have an agenda of sorts, but thanks to both Joel Escande & Tim Mackey, I am always glad to stop with my own projects.  The questions raised by the XenServer community are quite often far superior, necessary, and much more useful than my own tinkering!

If anyone has been anywhere on the Internet, you’ll notice from various resources (distrowatch being one of my favourites), that various distros and spins are gaining more and more popularity than their direct parents, etc.  Mint Linux is a good example, but also SolydXK, Korora, and today’s focus: Mageia.


How can one install XenTools in Mageia?

That is the question being asked and before I begin to illustrate, keep the following in mind:

  1. I have tested Mageia 3.x – 5.x across XenServer 6.1, 6.2, and 6.5
  2. Mageia 4.x (and older) are EOL — please use Mageia 5.x where applicable
  3. This OS does not fall under Citrix Support, long-term testing, etc
  4. I am assuming that you have installed Mageia 4.x or 5.x and just want the details on how to install XenTools

So, to begin – we need to mount the xs-tools.iso from XenCenter:

mageia4-0

With the ISO mounted, we will want to gain access within Mageia’s terminal as to mount the ISO as a loop device:

su - root
mkdir iso
mount -o loop /dev/cdrom iso/

We can the descend into the iso/Linux/ directory, however the installer will not be used as the release name of the OS is not supported.  If you try to use the installer, it will error out as follows:

mageia4-3

Following the instructions given to us, we will instead manually install the guest tools, but which ones?

This depends on two factors:

  • What is the architecture of your VM?
  • Is it related to Debian or Linux/RedHat?

These facts will determine if “i386” or “x86_64” packages will be used, as well as if rpm or deb packages will be used to install “xe-guest-utilities” and “xe-guest-utilities-xenstore”.

As this is Mageia, we know it will be using the rpm files.  From my Mageia 4.x and 5.x VMs, I am utilizing the 64-bit releases, so I would manually install the XenServer guest tools by executing:

rpm -ivh xe-guest-utilities-6.5.0-1436.x86_64.rpm xe-guest-utilities-xenstore-6.5.0-1436.x86_64.rpm

The following output should appear and a reboot should be carried out:

mageia4-4

And, after rebooting, XenCenter will now display the IP information and this should be the confirmation you need to ensure that the XenServer Guest Utilities are installed!

mageia5-5


In Conclusion…

This is a topic I will be following up with more often – specifically for modern OSes like Mageia – but in the meantime, I hope this overcome the XenServer Guest Tools installation for those with bleeding edge needs, custom solutions, or … even just trying to test something out.

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

 

 

 

Virtualizing: Because I CAN…

why
Standard

Wait… ABEND!  ABEND!

To all of you who read the first of this series, Virtualizing: Because I CAN…, thank you very much for the feedback and shares.  During a weekend filled with family, I rushed to pump out a quick article that truly goes far back in my work with Tim & Trolle.  After a bit of a challenge of Twitter, I rushed into it.

I wanted to take a second to be a bit more clear about what I’ve done, what I do, and why I do it.  First, the ground rules:

  1. I get the stuff working as far as I can…
  2. I explain why I did it and how…
  3. Just because I do it doesn’t mean you should in production…
  4. Yes, where the environments I am dealing can be shared, I will setup XVA exports to share, share, share

The whole principle of this is to take work I’ve done (and still do) for utility operating systems and share how I got it running in XenServer… along with the outcome.  This includes fresh distros, as well, but for the next week, I’ll be focusing in on a true “ERA” (of sorts).

Lastly, as I’ve said…

Just because I do it doesn’t mean you should in production and these articles – for clients, partners, colleagues, and the XenServer community – are strictly science experiments.  Don’t ask for support on Xenix, etc.  That’s all I’m asking.

Oh, and I PROMISE, if you read all the way through you’ll find something that every XenServer user has seen after upgrading tools…

Alright.  I feel better.  Time for coffee and more writing.  #BritsAreAwesome #CambridgeMadeXen #UnionJack #GiveMeAnAmstrad


PCs, Clones, and Ports: Part 1

Depending on your level of disdain, love, or preference of utility – as we are returning to an age where two technological giants divorced and left us as the kids in the middle… with Personal Computers and software you didn’t have to rewind.

Ladies and Gentlemen, I present to you Mr. and Mrs. Ex….

ibm-old-logomicrosoft

Ah, yes.  The tragic lovers who completely continued their honeymoon so distastefully in and through poor Gary Kildall’s death, began the suffocation of CP/M and what CP/M could have become, but always kept the doors open to show us the fisticuffs.

Looking back now, I often wonder which one of them spot the setup?  I know it wasn’t Apple (despite the commonality betwixt these THREE companies being Mr. Bill Gates).

My bet is on Microsoft and for nothing more than the same reason they were able to date Apple…

“The hardware exists and we already have the ability to code on it… and code on the competition’s platform… and the compatibles… and we build a dynsasty of software every architecture must have for the consumer….”  Oh, the places you went, returned to, and tried to go into.


Fast Forward: XenServer, DOS, and … Amstrad?

I’m not heading in any chronological order due to the nature of IBM, IBM compatibles, and the reams of software that is avaialable.  Let’s take this quick example:

pcbasic

And if you hit F2, we get…

pcbasic2

… and no one could remeber to exit PC-BASIC by typing “system”.  And wouldn’t you know it?  Like fine wine, it has aged and can be used on Mac, Windows, and Linux.  Take a peek at https://sourceforge.net/projects/pcbasic/ or, start your own software archive like me by  visiting http://deger.republika.pl/Download_MS_Basic_versions.htm.

Not familiar enough?  What about this?

qb45

Well, even if you still don’t recognize these items, I welcome you to the world of IBM/PC/MS-DOS… from XenServer.  Yup, I dug out an old VM export for a “DOS Collection” project where my kids, friends, and especially ME could immerse ourselves in the glorious environment that is generally called “DOS”: code page 437, FAT, basic, and where many people first absorbed that which was Personal Computing.


The Environment Details…

With respect to XenServer, I’ve had this VM since the 6.0 days.  With each revision, it just runs more and more smoothly and while it looks and feels like MS-DOS 7.1, it existed first as MS-DOS 5.x.  During the XenServer 6.2 days, I did some finess work with the installer and it’s a hybrid MS-DOS 5/6/7 release with plenty of opensource utilities stacked on it.

The reasons I took such odd approach was based on four key reasons:

  1. Jim Hall’s FreeDos, which I spent a short time testing and contributing to (those guys are beyond intelligent, trust me)
  2. These later versions could handle my favorite games, still compile code in primitive forms of my favorite languages, BUT drivers… DRIVERS… were becoming more cohesive
  3. DOSBox exists, but is limited as an emulator/almost type-2 hypervisor
  4. I PAID FOR ALL THIS STUFF AND GREEDY PEOPLE ON EBAY TAUNT ME WITH BARE METAL MACHINES

Using the “Other” template, I set aside 1 vCPU and 256MB of RAM.  Considering the software I had, I looked back over pre-GUI OS/2, older versions of MS-DOS (pre 4.x) and IBM/PC-DOS that existed from the long lived IBM/Microsoft relationship and came to a single conclusion to work around my virtual hard disk needs:

I needed to master three ISOs.  One with MS-DOS 7.1.  One with MS-DOS 5 and 6.  And a final disk with a host of extender utilities, FAT improvement, code-fixed DOS utilities (format, fdisk, etc).  After all, this is a virtual machine and I don’t have to torture myself with the days before drivers became a bit more standardized, memory management wasn’t as manually intensive (ie, gaming versus word processing), and so forth.

After I mastered the ISOs and slapped them onto my local SR, I booted off of MS-DOS 7.1 and “broke” out of the installer.  That gave me the prompt I needed – with CD-ROM/Mouse support – do mount the utility ISO and it was there I was able to use updated versions of fdisk/format to achieve this:

partition

After the disk was formatted, I basically had all the individual compents I could have authored into my own installation ISO, but instead I hand picked the core of MS-DOS, installed DOS extenders, helper utilities, multiple device drivers (including many variants of mice, long/short filename, linkers, basic VGA drivers, etc).

I crossed my fingers, rebooted the VM, and oh me oh my.  I was in heaven as a packet driver could be installed later (or even Windows 3.x, 95, or 98), but I went about my DOS business… which included running AN AMSTRAD CPC EMULATOR WITHIN DOS WITHIN XENSERVER!

Yes, I need to get Wattcom installed, but for now — enjoy these shots from XenServer and if you have an Amstrad, feel free to let me know as in the states… SLIM.  EXPENSIVE.  NOT GUARANTEED TO WORK.  PICKINGS.


True Emulation in Virtualization…

Since I couldn’t get an Amstrad, let alone two, for my father and I to have our old school code battles on, I found NO$CPC — it does not disappoint, I promise.  The game/code you are seeing is my own improvements onto Conway’s Game of Life.

8

9

Indeed, I WAS READY…

12

And off we go despite not having time to add code for more than 10 generations…

conway

So, I took a few minutes to play a game.  Battle Chess, oh yes.  This thing won’t run for 10 minutes in DOSBox without crashing – which I can understand – but in XenServer… no issues!  I LOST!

bchess1

bchess2

Of course I went on and on to play Mechwarrior, Indianapolis 500, but then I decided to hack out a version of something we all see when tools are successfully installed and a VM is rebooted.  The IDE/Language was 80/20 Software’s “ASIC” (almost basic).  Powerful – especially with extended libraries for INT21 ops, Chipset Access, etc.  However… this is for all true XenServer fans…

xstools

Look familiar?

xstools1


Conclusion of Part 1

Yup, this was quite a long piece, but the fact I was running a mixed DOS environment, writing and compiling code, emulating a completely different architecture within the virtualized environment… well, I had to share.

Next up?  OS/2, PC-DOS?  eComStation and some Windows 3.11?  We shall see!

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

Another Gem from Rachel Berry!

Standard

This blog only applies to M60 / M6 (Maxwell generation) GRID cards. It is not relevant to GRID 1.0 (K1/K2 cards). Try this first! If you are experiencing issues with a new M60 / M6 card, please run this command: lspci –n | grep 10de You should get something that looks like: [root@SAGRID-ESXi5:~] lspci –n […]

via NVIDIA M60 / M6 Problems – check your card in “graphics” mode! — Virtually Visual