Posts Tagged hwVPS
Finally, A Real Hosting Account
Posted by Jonathan Kinney in Routers, Server Administration, Technology, Virtualization, Website Software on June 17, 2011
I am so happy to finally get my wife’s sites (kdesign007.com and others) off of the Godaddy.com hosting account! It really didn’t seem all that bad, I mean, it did its job, but it sucked how they charged for everything, even having an email account looked to be billable. I guess it is good to be able to quantify a service into an actual billable value, but it gets really annoying to have to worry about if you will have to pay extra for something as simple as an email account.
Her hosting was on a Linux system, and that was neat, but it was lacking a bit. PHP was shown as version 4.x, though I am sure you could have had that changed to a version 5.x support, it said so in the help. I had to enable SSH for her account so I could transfer them over here easily, and that for some reason required them to transfer the site to a different server. What ever, I can live with that. But they had to call me and give me a pin number to do it, and it can take up to 24 hours, this time it took only around an hour (guessing). The server I found it on was running at a load of 5 at the time, and though responsive, it was a little sluggish when responding to any sort of IO request, and the transfer speed from this server to my hwVPS 2009 account was quite sad, it looked to be around 60 to 70 kilobits a second, and I do hope that was a specific bandwidth limit Godaddy.com hosting set for SSH data, because for a website loading speed, that would just suck.
Thanks to BlueOnyx, setting up the accounts and users took a minimal amount of time, and I love our DNS management system. By the end of the night yesterday, I had all but 3 domains fully setup with live websites and DNS settings for the new location. I am moving away from anything using FTP, so I have SSH enabled which allows SFTP access, which seems to even be supported by Dreamweaver! I simply used SCP to transfer all the site’s files to their respective places, and it went through perfectly!
With some custom hacks, I have IPv6 enabled for some of the sites on my VPS, and am going to setup a script that will automate that for me. At the moment I have IPv6 connectivity through a tunnelbroker.net / he.net account, which allows me to run a IPv6 6in4 static tunnel. I also modified dovecot, sendmail, and the rest of the software to run full dual stack. It is not really needed yet, but it is neat seeing all of my server backups and connectivity showing up on the six0 interface graph on my Asus RT-N16 router (I love that thing!, with it running Toastman’s build of TomatoUSB).
Now she gets to deal with me for support, muahahahaha! It is just really good to have the sites on a system and network I know I can trust! I also have the comfort of knowing that she will not be charged for simple things like email accounts, and she will be getting good support from someone who knows what they are talking about.
Updated PHP For BlueOnyx Totally Doable!
Posted by Jonathan Kinney in Development, Server Administration on August 31, 2009
Is doable really a word? I guess so, I don’t see it popping up as a misspelled word. Anyway, I have been doing some development for some clients who had a desire for more functionality with the PHP install that BlueOnyx uses. Well that is a complicated bag of monkeys, can of worms, box of cats?, or what ever, because BlueOnyx uses the installed version of PHP for the control panel, and it has modules that it needs to use that were specifically compiled against the CentOS 5.3 included PHP 5.1.6. This makes things unusual when it comes to wanting to install a newer version of PHP. These clients also wanted zip functionality, and they were specifically pointing to having it built with zip functionality, rather than the PECL based install, which was too foreign to me at the time to actually consider and present as an option. PHP 5.1.6 or 5.1.x in general did not have built in zip functionality, as it seems that there was a bit of a drop out with the maintenance of the library it depended on during that PHP version’s time, so that made things even more complicated. Staying in the PHP 5.1.x range might have been close enough for me to build as a drop in replacement without breaking the BlueOnyx control panel requirements. Another thing to consider was that a drop in replacement might run into issues with a yum update overwriting it if done wrong.
So, this left me with few options. One of the clear needs was to be able to have a different PHP install that did not disrupt the PHP version that comes with CentOS 5.3. As I saw it, I had 2 options, build a custom PHP RPM install, or build PHP from source to be placed in a different location. Building PHP from source is not as clean and easily controllable as I would prefer, but as long as good backups were made, it was worth a try. One thing I have not mentioned yet is that we have ruled out PHP 5.3, as the changes seemed to be fairly extreme from the PHP 5.1.6 install, and the changes could be much more of a headache to work through than our client or many clients would like to have to deal with just yet, so we are focusing on PHP 5.2.10.
My first attempt was to built PHP 5.2.10 from source, but specifically building it to run from a different location, which I setup in a directory on the server as “/alt/”. First thing first, due to the fact that in the source build and install step of “make install” does not really fully take into consideration any concept of installing in a different location, I needed to back up all of the RPM installed PHP related files. To do this I ran the following:
for X in `rpm -qa|grep php-`;do tar cpjf $X.backup.tar.bz2 `rpm -ql $X`;done
This will iterate through the RPM packages that are installed that contain “php-” in their package name, and then backup all files listed in that package into a tar.bz2 archive, so that if anything gets overwritten or messed with that I did not want, I could simply restore by going to the root directory and then run “tar xpjf /root/php-*.backup.tar.bz2” (or wherever the backups are stored) and I would have all the related files restored.
Now that we have the backup made, I needed a good build environment, and with our base install of BlueOnyx, there are no development packages installed, or even a compiler (a BlueOnyx security decision). So here is a list of packages that were installed to get things going, but first I would suggest doing a full yum update and reboot:
apr-devel-1.2.7-11.el5_3.1.i386
apr-util-devel-1.2.7-7.el5_3.2.i386
aspell-devel-0.60.3-7.1.i386
at-spi-1.7.11-3.el5.i386
audiofile-0.2.6-5.i386
autoconf-2.59-12.noarch
automake14-1.4p6-13.noarch
automake15-1.5-16.noarch
automake16-1.6.3-8.noarch
automake17-1.7.9-7.noarch
automake-1.9.6-2.1.noarch
avahi-0.6.16-1.el5_2.1.i386
avahi-glib-0.6.16-1.el5_2.1.i386
beecrypt-devel-4.1.2-10.1.1.i386
bison-2.3-2.1.i386
boost-1.33.1-10.el5.i386
boost-devel-1.33.1-10.el5.i386
byacc-1.9-29.2.2.i386
bzip2-devel-1.0.3-4.el5_2.i386
ccid-1.3.8-1.el5.i386
coolkey-1.1.0-6.el5.i386
coolkey-devel-1.1.0-6.el5.i386
cpp-4.1.2-44.el5.i386
cscope-15.5-15.1.el5_3.1.i386
ctags-5.6-1.1.i386
curl-devel-7.15.5-2.1.el5_3.5.i386
cvs-1.11.22-5.el5.i386
cyrus-sasl-devel-2.1.22-4.i386
db4-devel-4.3.29-9.fc6.i386
dbus-devel-1.1.2-12.el5.i386
dbus-python-0.70-7.el5.i386
desktop-file-utils-0.10-7.i386
dev86-0.16.17-2.2.i386
diffstat-1.41-1.2.3.el5.i386
dogtail-0.6.1-2.el5.noarch
doxygen-1.4.7-1.1.i386
e2fsprogs-devel-1.39-20.el5.i386
elfutils-devel-0.137-3.el5.i386
elfutils-devel-static-0.137-3.el5.i386
elfutils-libelf-devel-0.137-3.el5.i386
elfutils-libelf-devel-static-0.137-3.el5.i386
esound-0.2.36-3.i386
expat-devel-1.95.8-8.2.1.i386
flex-2.5.4a-41.fc6.i386
fontconfig-devel-2.4.1-7.el5.i386
freetype-devel-2.2.1-21.el5_3.i386
gail-1.9.2-1.fc6.i386
gamin-0.1.7-8.el5.i386
gcc-4.1.2-44.el5.i386
gcc-c++-4.1.2-44.el5.i386
gcc-gfortran-4.1.2-44.el5.i386
GConf2-2.14.0-9.el5.i386
gdb-6.8-27.el5.i386
gdbm-devel-1.8.0-26.2.1.i386
gd-devel-2.0.33-9.4.el5_1.1.i386
gettext-0.14.6-4.el5.i386
glib2-devel-2.12.3-4.el5_3.1.i386
glibc-devel-2.5-34.el5_3.1.i386
glibc-headers-2.5-34.el5_3.1.i386
gmp-devel-4.1.4-10.el5.i386
gnome-keyring-0.6.0-1.fc6.i386
gnome-mime-data-2.4.2-3.1.i386
gnome-mount-0.5-3.el5.i386
gnome-python2-2.16.0-1.fc6.i386
gnome-python2-bonobo-2.16.0-1.fc6.i386
gnome-python2-gconf-2.16.0-1.fc6.i386
gnome-python2-gnomevfs-2.16.0-1.fc6.i386
gnome-vfs2-2.16.2-4.el5.i386
gpm-devel-1.20.1-74.1.i386
hesiod-devel-3.1.0-8.i386
httpd-devel-2.2.3-22.el5.centos.2.i386
ifd-egate-0.05-15.i386
imake-1.0.2-3.i386
indent-2.2.9-14.fc6.i386
kernel-headers-2.6.18-128.4.1.el5.i386
keyutils-libs-devel-1.2-1.el5.i386
krb5-devel-1.6.1-31.el5_3.3.i386
kudzu-devel-1.2.57.1.21-1.el5.centos.i386
libacl-devel-2.2.39-3.el5.i386
libattr-devel-2.4.32-1.1.i386
libbonobo-2.16.0-1.fc6.i386
libbonoboui-2.16.0-1.fc6.i386
libcap-devel-1.10-26.i386
libc-client-devel-2004g-2.2.1.i386
libdaemon-0.10-5.el5.i386
libdrm-2.0.2-1.1.i386
libgcrypt-devel-1.2.4-1.el5.i386
libgfortran-4.1.2-44.el5.i386
libglade2-2.6.0-2.i386
libgnome-2.16.0-6.el5.i386
libgnomecanvas-2.14.0-4.1.i386
libgnomeui-2.16.0-5.el5.i386
libgomp-4.3.2-7.el5.i386
libgpg-error-devel-1.4-2.i386
libicu-3.6-5.11.4.i386
libIDL-0.8.7-1.fc6.i386
libidn-devel-0.6.5-1.1.i386
libjpeg-devel-6b-37.i386
libmcrypt-devel-2.5.8-4.el5.centos.i386
libmhash-0.9.9-SOL2.i386
libnotify-0.4.2-6.el5.i386
libogg-1.1.3-3.el5.i386
libogg-devel-1.1.3-3.el5.i386
libpfm-3.2-0.060926.4.el5.i386
libpng-devel-1.2.10-7.1.el5_3.2.i386
libselinux-devel-1.33.4-5.1.el5.i386
libsepol-devel-1.15.2-1.el5.i386
libstdc++-devel-4.1.2-44.el5.i386
libtermcap-devel-2.0.8-46.1.i386
libtool-1.5.22-6.1.i386
libusb-devel-0.1.12-5.1.i386
libuser-devel-0.54.7-2.el5.5.i386
libvorbis-1.1.2-3.el5_3.3.i386
libvorbis-devel-1.1.2-3.el5_3.3.i386
libwnck-2.16.0-4.fc6.i386
libX11-devel-1.0.3-9.el5.i386
libXau-devel-1.0.1-3.1.i386
libXaw-1.0.2-8.1.i386
libXdmcp-devel-1.0.1-2.1.i386
libXevie-1.0.1-3.1.i386
libXfontcache-1.0.2-3.1.i386
libxml2-devel-2.6.26-2.1.2.8.i386
libXmu-1.0.2-5.i386
libXpm-devel-3.5.5-3.i386
libXres-1.0.1-3.1.i386
libxslt-devel-1.1.17-2.el5_2.2.i386
libXt-1.0.2-3.1.fc6.i386
libXTrap-1.0.0-3.1.i386
libXxf86misc-1.0.1-3.1.i386
libXxf86vm-1.0.1-3.1.i386
lockdev-1.0.1-10.i386
lockdev-devel-1.0.1-10.i386
ltrace-0.5-7.45svn.el5.i386
mcrypt-2.6.7-SOL2.i386
mesa-libGL-6.5.1-7.7.el5.i386
mesa-libGL-devel-6.5.1-7.7.el5.i386
mysql-devel-5.0.45-7.el5.i386
ncurses-devel-5.5-24.20060715.i386
neon-0.25.5-10.el5.i386
net-snmp-devel-5.3.2.2-5.el5_3.2.i386
newt-devel-0.52.2-12.el5.i386
notification-daemon-0.3.5-9.el5.i386
nspr-devel-4.7.4-1.el5_3.1.i386
nss-devel-3.12.3.99.3-1.el5.centos.2.i386
openldap-devel-2.3.43-3.el5.i386
openssl-devel-0.9.8e-7.el5.i386
oprofile-0.9.3-18.el5.i386
ORBit2-2.14.3-5.el5.i386
pam-devel-0.99.6.2-5BX01.centos5.i386
patch-2.5.4-29.2.3.el5.i386
patchutils-0.2.31-2.2.2.i386
pciutils-devel-2.2.3-5.i386
pcre-devel-6.6-2.el5_1.7.i386
pcsc-lite-1.4.4-0.1.el5.i386
pcsc-lite-devel-1.4.4-0.1.el5.i386
pcsc-lite-libs-1.4.4-0.1.el5.i386
pfmon-3.2-0.060926.5.el5.i386
postgresql-devel-8.1.11-1.el5_1.1.i386
pstack-1.2-7.2.2.i386
pycairo-1.2.0-1.1.i386
pygobject2-2.12.1-5.el5.i386
pygtk2-2.10.1-12.el5.i386
pyorbit-2.14.1-1.1.i386
pyspi-0.6.1-1.el5.i386
python-devel-2.4.3-24.el5_3.6.i386
python-ldap-2.2.0-2.1.i386
python-numeric-23.7-2.2.2.i386
rcs-5.7-30.1.i386
readline-devel-5.1-1.1.i386
redhat-rpm-config-8.0.45-29.el5.noarch
rpm-build-4.4.2.3-9.el5.i386
rpm-devel-4.4.2.3-9.el5.i386
shared-mime-info-0.19-5.el5.i386
slang-devel-2.0.6-4.el5.i386
splint-3.1.1-16.el5.i386
sqlite-devel-3.3.6-2.i386
startup-notification-0.8-4.1.i386
strace-4.5.18-2.el5_3.3.i386
subversion-1.4.2-4.el5_3.1.i386
swig-1.3.29-2.el5.i386
systemtap-0.7.2-3.el5_3.i386
systemtap-runtime-0.7.2-3.el5_3.i386
texinfo-4.8-14.el5.i386
valgrind-3.2.1-6.el5.i386
xmlsec1-devel-1.2.9-8.1.i386
xorg-x11-fonts-base-7.1-2.1.el5.noarch
xorg-x11-proto-devel-7.1-9.el5.centos.i386
xorg-x11-server-utils-7.1-4.fc6.i386
xorg-x11-server-Xvfb-1.1.1-48.52.el5.i386
xorg-x11-xauth-1.0.1-2.1.i386
xorg-x11-xinit-1.0.2-15.el5.i386
xulrunner-1.9.0.12-1.el5.i386
xulrunner-devel-1.9.0.12-1.el5.i386
zlib-devel-1.2.3-3.i386
I know that is a lot of packages, but its better to have everything you might need there, just in case, and you can always grab the section from your “/var/log/yum.log” where you installed these, put it in a file called, for example “/tmp/devel-yum-packages.txt”, and then do an “rpm -e `awk ‘{ print $5 }’ /tmp/devel-yum-packages.txt`” to remove them all when you are done with them. Next I downloaded the latest .tar.bz source archive of php-5.2.10 to “/usr/src/redhat/SOURCES/” and extracted them to “/usr/src/redhat/BUILD/” and configured it with this set of configuration directives:
‘./configure’ \
‘–host=i686-pc-linux-gnu’ \
‘–build=i686-pc-linux-gnu’ \
‘–target=i386-redhat-linux-gnu’ \
‘–program-prefix=’ \
‘–prefix=/alt/usr’ \
‘–exec-prefix=/alt/usr’ \
‘–bindir=/alt/usr/bin’ \
‘–sbindir=/alt/usr/sbin’ \
‘–sysconfdir=/alt/etc’ \
‘–datadir=/alt/usr/share’ \
‘–includedir=/alt/usr/include’ \
‘–libdir=/alt/usr/lib’ \
‘–libexecdir=/alt/usr/libexec’ \
‘–localstatedir=/alt/var’ \
‘–sharedstatedir=/alt/usr/com’ \
‘–mandir=/alt/usr/share/man’ \
‘–infodir=/alt/usr/share/info’ \
‘–cache-file=config.cache’ \
‘–with-config-file-path=/etc’ \
‘–with-config-file-scan-dir=/alt/etc/php.d’ \
‘–enable-force-cgi-redirect’ \
‘–disable-debug’ \
‘–disable-rpath’ \
‘–enable-inline-optimization’ \
‘–with-bz2’ \
‘–with-db4=/usr’ \
‘–with-curl’ \
‘–with-exec-dir=/usr/bin’ \
‘–with-freetype-dir=/usr’ \
‘–with-gd’ \
‘–enable-gd-native-ttf’ \
‘–without-gdbm’ \
‘–with-gettext’ \
‘–with-ncurses’ \
‘–with-gmp’ \
‘–with-iconv’ \
‘–with-jpeg-dir=/usr’ \
‘–with-openssl’ \
‘–with-pspell’ \
‘–with-regex=system’ \
‘–with-xmlrpc=shared’ \
‘–with-pcre-regex’ \
‘–with-zlib’ \
‘–with-layout=GNU’ \
‘–enable-zip’ \
‘–enable-bcmath’ \
‘–enable-exif’ \
‘–enable-ftp’ \
‘–enable-magic-quotes’ \
‘–enable-sockets’ \
‘–enable-sysvsem’ \
‘–enable-sysvshm’ \
‘–enable-discard-path’ \
‘–enable-wddx’ \
‘–without-oci8’ \
‘–with-pear=/alt/usr/share/pear’ \
‘–with-imap=shared’ \
‘–with-imap-ssl’ \
‘–with-kerberos’ \
‘–with-ldap=shared’ \
‘–with-mysql=shared,/usr’ \
‘–with-snmp=shared,/usr’ \
‘–with-snmp=shared’ \
‘–enable-ucd-snmp-hack’ \
‘–enable-bcmath’ \
‘–enable-shmop’ \
‘–enable-calendar’ \
‘–enable-mbstring=shared’ \
‘–enable-mbregex’ \
‘–with-pic’ \
‘–with-apxs2=/usr/sbin/apxs’ \
‘–with-mysqli’ \
‘–with-mcrypt’ \
Then I just ran a “make all” and then a “make install” which got most of the files installed the way I wanted them to be, but not all of them, so I quickly restored the backups I had just created, as it replaced the old “/etc/httpd/libexec/modules/libphp5.so” and messed with the PEAR install. It also messed with the original httpd.conf, so to undo that, I ran “cat /etc/httpd/conf/httpd.conf.bak > /etc/httpd/conf/httpd.conf” to get it back, it created the .bak with the “make install” command. All in all, this process worked, but it was dirty, and I felt dirty for doing it.
After a quick shower, so I felt a little cleaner after such a dirty install method, I looked at it again. There had to be a better way. I had tested and shown that there is potential in taking some updated RPM files I found on “http://dev.centos.org/centos/5/testing/i386/” and installing them in “/alt/” with the use of rpm2cpio, and then modifying the httpd startup script so that it set the “PHPRC=” environment variable so that PHP would look for the php.ini file in a different location. But there were complications with that which I had not fully overcame. The BlueOnyx control panel uses the same apache binary and PHP binary and modules, but it uses its own apache configuration file, php.ini file, and its own init script to start it up and set specific environment variables such as “PHPRC=/etc/admserv”. It however still uses the “/etc/php.d/” directory to setup its included modules, and that was a complication I needed to avoid. So, the only cleaner choice was to find a source RPM that I can extract and modify a bit, and then build a custom set of RPM files that I can use to rpm2cpio to the “/alt/” directory.
The closest starting point to building my own RPM files seemed to be here “http://dev.centos.org/centos/5/testing/SRPMS/php-5.2.9-2.el5.centos.src.rpm”. It was only slightly off from what I was looking for, I was so happy to find that to work with. I have not worked much with building my own RPMs before, so in my time frame, I could not really toss a spec file and patches together from the ground up to build my own custom RPMs. So to get this going, I installed the source RPM file, and opened up the php.spec to see what I had to work with. It seemed fairly strait forward. All I had to do was download the newer .tar.bz2 source, and change a few version strings, and then find and modify where PHP will look for the php.d directory. So up near the top, I changed the PHP version of 5.2.9 to 5.2.10, then searched for “–with-config-file-scan-dir=” and changed that to the hard coded “/alt/etc/php.d” location that it needed to be. Then for completeness sake, I added information to the changelog:
* Thu Aug 28 2009 Jonathan Kinney <jonathankinneydss@google.com> 5.2.10-1.el5
– update to 5.2.10
– add mcrypt
Then to build it, while in the “/usr/src/redhat” directory, I ran “rpmbuild -bb SPECS/php-BlueOnyx.spec”. Oh, yeah, and to make sure that I made it unique enough, I change the “Release:” to be “BlueOnyx%{?dist}” and then I renamed the spec file. I wanted to keep it simple enough that I could also build updated RPMs for a plain old install of CentOS 5.3 without BlueOnyx installed.
One thing I am not going to explain the details about here is the adding of mcrypt, it took a lot of hacking to get in there, basing it off of the format of the other modules already built, and taking examples from the source RPM of the 5.1.6 PHP extras, which included mcrypt. It was requested enough by clients that I wanted to take the extra time and make sure I got that in there.
The only steps left after the successful building of all those RPM files was to install it. I just copied a, similar to what is already installed, set of the newly built RPM files to “/root/RPMS/” and then I went to the “/alt/” directory and ran the following command to get the files extracted:
for X in `ls /root/RPMS/`;do rpm2cpio /root/RPMS/$X | cpio -idmv;done
Then in the “/etc/php.ini” file, I changed the “extension_dir = ” to the new location of “/alt/usr/lib/php/modules/”. The only configuration change left to do is to edit “/etc/httpd/conf.d/php.conf” and change the “LoadModule php5_module” to point to “/alt/usr/lib/httpd/modules/libphp5.so”. After restarting httpd, I was up and running with a fully featured installation of PHP 5.2.10, without a single related error logged. It is fully connected to the PHP settings that are set from the BlueOnyx control panel as it uses “/etc/php.ini”, but it gets its module includes loaded from “/alt/etc/php.d/” and the modules themselves loaded from “/alt/usr/lib/php/modules/”. I have been running things on this very server that you are pulling this website up from, for nearing a week, without problems.
Once again, I have to plug my hwVPS account running BlueOnyx, which is the only VPS account that I have used that is so seamless, I have yet to run into any issues that would bring me to want more than this type of Xen VPS.
Loving My New hwVPS Account
Posted by Jonathan Kinney in Server Administration, Virtualization on August 7, 2009
I am settling in quite well with this hwVPS account I am using for hosting this very blog. I have set it up with BlueOnyx on CentOS 5.3, and it is simply delightful. As an employee, I could have picked any account size I wanted, but I stuck with the 512 MiB version with 1 3Ghz CPU, because I have no desire to waste resources, and I believe that will be more than adequate for my purposes, if not I can upgrade, too many people don’t get that . It is a paravirtualized Xen domU running on some truly state of the art hardware, and setup in a state of the art way. I am not saying it is not possible to be done by others, but I am saying that very few have the skill to get the performance out of the hardware like it is done here. As it stands we are riding the edge of what Linux and Xen can do, and gleefully looking forward to patches and updates as the Linux kernel writers put them in the mainstream. We are not bold enough to toss in untested code, stability is a priority. So far, stability has been perfect for my installation. Not a hiccup to mention so far, and it is at least nearing a month (July 14th) of existence.
I love Xen as a virtualization software. It is as cut and dry as it gets, so in some aspects, and some applications, it may not have as big of an advantage as perhaps the software engineering marvel that was once called Virtuozzo, which has been taken over by an evil empire, which now call themselves Parallels. I do not know its state now, but I did know at least some of the engineers involved in the creation, and they were a good passion full bunch of people driven to excellence, and now they, if they even exist today, are being cut short and corrupted by the lust for money and corporate power. Their software started gleaming with passion, and excellence, but has been declining not too long after they started. But anyway, back to my point. In the beginning when Virtuozzo was in good hands, it allowed each VPS to use a templated operating system, that actually shared the same files in such a way that Linux could simply cache that one file set, and have it be used for all of the VPS instances, talk about totally nerd cool! And another cool aspect of that setup, all of the VPS instances could mainly run off of one file set, that’s right, one 600 or so megabyte set of files for as many VPS instances as you could fit in your ram, which was in our case, back in the day, several hundred. So in some aspects, that works well, people can have their own environment to muck up and destroy, or actually use, no one can crash the hardware, only their environment. The downsides were the fine tuning of many complex memory types and resources, which could not always be used across the board with the broad uses customers had in mind for their VPS instances. The other downside was that the instance would run many modified operating system files and packages, so that it could function correctly, so a yum update to the latest version of OS was not part of the deal, and keeping up to date with yum or the like was not possible for the end user. If it were one piece of hardware, under the control of one person for a specific organized use, then that person would be able to do wonderful things, but in the real world of a hosting company, that is not the case. That is where Xen comes in. Even though the concepts are a little hard to grasp at times, and it is weird having the virtual environments so totally separate so you can not as easily spy on what they are doing or help them when something goes wrong, once you get the hang of it and enact some good policies so that you gain access to the domUs (the name of Xen’s virtual environments) if and when you need to, it works quite well. The division of the hardware’s resources is much more solid, no sharing of memory as if they all ran off the same kernel and filesystem. This solidity leads to predictability, which is a must have in planning the use of the resources. It also seems that, for example, there are not any CPU over usage issues that can effect another domU in Xen. With Xen, you can run a fully virtualized with the emulation of various devices, with various minimal hits in performance, or you can run at near 100% hardware performance with a paravirtualized OS by using various Xen specific drivers. Most mainstream Linux distributions come with these Xen specific drivers, I believe even Windows has some drivers, even though they are considered unstable.
All the technical differences aside, it is just like I am using my own hosted hardware, with the added ability to restart or reboot my hwVPS, and watch the console if it ever has an issue. I can update like any plain old Linux install should be able to do. The big difference is that I have some major high end hardware backing my system, even a high end network attached storage system that allows my hwVPS to be transferred between 2 different pieces of hardware. How much would I be paying a month? In this case, it would be 45 dollars, which is really nothing compared to the actual costs associated with having that kind of hardware at your hands. I think I will rant about the misperceptions of the general public later, along with their lofty expectations with hosting that are not actually covered by how much they pay, but they feel they are entitled to more because they are comparing with larger companies who are undercutting to gain a larger footing in the hosting industry and to stamp out other competition.