Wednesday, April 25, 2007, 09:18 PM
Well, after the 3.2 update, just about all of our problems were fixed. We applied it within the first week of April. But I think it may have introduced a new issue. We have a Windows Small Business Server 2003 Std R2 server that we use for VPN connections. It is a virtual machine on our XenExpress server. Ever since the update, we can no longer connect to other VMs on our XenExpress server over the VPN. We can connect to other systems in the office over the VPN, but not any other VMs on the XenExpress server. The VMs can communicate with eachother fine via IP. It just seems to be the VPN connections that are unable to communicate with the XenExpress VMs. I have looked at the firewalls and I don't think it is a firewall issue.
Again, it seems that it was clearly introduced at the time that we upgraded from 3.1 to 3.2.
We are VERY pleased with the XenExpress server overall, but this little issue would increase our productivity, and allow us to NOT move backward from the solutions and technology we've been using. XenSource is of course a big leap forward in other ways. Did I mention that we like it?? :-)
[ 1 comment ] ( 16 views ) | permalink |
( 3.3 / 12 )Monday, March 26, 2007, 05:28 PM
We are really enjoying using XenExpress on our new Dell PowerEdge 1950 Quad-core Xeon. It's extremely fast now with 4 virtual servers running on our Xen server. I am ready to plop down the $700.00 to purchase the XenEnterprise version, which will allow us to have unlimited VMs, but before I do, I need answeres to few problems we've experienced.
1.) Xen Virtual Machine crash - We have 2 linux VMs running Debian Sarge, and 2 Windows VMs, one running Windows Small Business Server 2003 Premium R2, and the other running Server 2003 R2. I use a Mac, and so I connect to the Server 2003 R2 VM via RDP to do a lot of Windows work. One of the things that I do there is administer the Xen server. We have the Xen Administration program loaded onto that VM. It generally works fine administering the VMs that way. However, about an hour ago I was logged onto our Server 2003 R2 machine and running the Xen Administration program, when suddenly my RDP session stopped working. I reconnected about a minute later, only to find that the VM had rebooted. Just a moment later, a colleauge mentioned that the other Windows VM had just restarted unexpectedly. Upon logging back into both, we were prompted with Microsoft's window which asks why the computer was unexpectedly shut down. I then logged into the linux VMs, and ran the uptime command to find that one reported being up for over 4 days, and the other over 5 days. So only the Windows servers were rebooted. I SSH'd into the Xen Server & checked out the /var/log/messages & /var/log/xen/xend.log log files, as well as others that I thought may give helpful information. Those two were the only ones that really seemed to tell much about the unexpected Xen problem. I have a pretty good hunch as to what caused the problem with the server I was using (Server 2003 Standard R2), but I have no idea why it took the 2nd Windows server down with it. (By the way, the VMs are running fine now).
Here's exactly what I was doing at the time of the VM crashes:
I was connected to the Windows Server 2003 Standard R2 via RDP on the console connection. And I think the console fact is the important one here. The reason being is because the last thing I did before the servers crashed was open the Xen Administration program, select the Server 2003 Std R2 VM from the list in the upper-pane, then click on the "Graphical Console" tab down below. I am thinking that because I was remotely connected to the server's graphical console via RDP, the Xen Administration program didn't like the idea of me viewing the graphical console from it, from within the graphical console. I've had similar issues w/ VNC connecting to the local host, only to get an endless loop of embedded screens. Hmmm. This is absolutely the only reason why I can imagine that this happened.
So, perhaps for now, a lesson learned is to be more careful with that. But perhaps in the meantime, XenSource can implement an if-then statement in their software to check before hand as to whether allowing their software to do something (try to do, anyway) is going to cause problems.
I think the big problem here however, is that my 2nd Windows VM was taken down with the other. I think this is totally unacceptable. Just a passing detail that may help in solving this problem is that one or two other times, I have had problems connecting to the Xen server from the Xen Administration program, so I SSH'd into the Xen server & restarted the XenAgentD process (service xenagentd restart), only to find that it also killed & restarted my Windows VMs unexpectedly, while leaving the linux VMs unscathed.
As previously stated, I am ready to pay the $700.00 for XenEnterprise, but not until I get a good answer to what caused this, and get a permanent fix.
As far as I am concerned, I am very excited about Xen. I love to see Open Source software actually make some money and develop into a strong competing business to proprietary software companies. That is why I chose Xen over VMWare for virualization.
I don't think that most people using Xen have problems like this. The very fact that Xen is marketed & often reviewed as a strong competitor to VMWare all the more confirms to me that this is probably not a common problem. Also, the founder of XenSource (Ian Pratt), stated in July 2006 that there were very few outstanding bugs in Xen at that time (this was in a PDF titled "The Xen Roadmap"). And I'm thinking that coming from this guy being a very experienced professional programmer, this probably refers to issues that are so small that I probably wouldn't even notice them (although I may be overzealous here).
Also, HP and I think IBM are strongly backing Xen, and sell servers preloaded with it. HP has published whitepapers in conjunction with XenSource stating how great Xen is and posting benchmarks running on their systems. I really don't think they would do this, if my problems were commonly experienced.
So what I'm trying to say is that I don't think that Xen is a buggy solution that shouldn't be used on production servers. We've actually been very, very impressed with it overall. But there is obviously something wrong here, and I need to be reassured that we're making the right decision by virtualizing with Xen, before I commit to invest in it. And once that we really are convinced that it is the right way to go, we will continue to invest in it, and work to steer our clients the same way. Once that we commit ourselves, then we want them to be successful, and so will gladly pay them in doing our part to help them have the financial resources needed to continue to improve & be successful.
As for now, I am posting this with a request for help. I have placed the relevant portions of the log files here: http://www.kgotsi.com/static.php?page=s ... s-20070326
Please provide assistance, and also contact someone in the Xen sales division and let them know that you are sending them another buyer, whose problems you just fixed.
Thanks a lot!
--
Doug Mortensen
Network Consultant
Impala Networks Inc.
doug----at----impalanetworks----dot----com
CCNA, MCP, A+, Linux+, MS Small Business Specialist
[ add comment ] | permalink |
( 2.8 / 69 )Sunday, February 25, 2007, 03:33 PM
I always like it when I get to hang out with my really cool wife.[ add comment ] | permalink |
( 3.2 / 31 )Saturday, January 27, 2007, 01:16 PM
I haven't had any bad experiences with BestBuy. But it seems that others have. I have read through the following post (what I deemed to be the "meat" of each of the 25 pages). Needless to say, others have had some pretty painful experiences with BestBuy. And I doubt that BB is the only company that has complaints & "horror-stories" like this one. I actually appreciate BestBuy in a way, because being a network consultant, sometimes I need a part/software fast, and they have a pretty decent stock. I must say that I think that their Dynex & GeekSquad lines of hardware are junk (I did get the run-around on a $55 external HD enclosure, which I finally just gave up on, even though it was still under the manufacturer's [Dynex/BestBuy] warranty). I've had far better results dealing with warranty claims with brand-name products. WalMart's array of stocked computer/soho network merchandise continues to grow, and I appreciate this good & sometimes cheaper alternative to BestBuy. Anyway, I'm not anit-BestBuy, but this person's experience has definitely caused me to have some serious second thoughts about buying their extended warranties (PSP's).
Check out the link:
http://www.redflagdeals.com/forums/showthread.php?t=393838
[ add comment ] ( 34 views ) | permalink | related link |
( 3 / 64 )Friday, January 26, 2007, 01:30 AM
When building (compiling) PHP4 (actually 4.4.4), you may run into a few caveats, like I did. I was able to overcome them, and hopefully these notes will help anyone else with the same problem, or perhaps myself, if I need to do this again in the future.
I am running an Apple iMac 350Mhz G3 with YellowDog Linux (YDL) 4. By the way, I would NEVER use YDL again. They don't keep up with package updates nearly as much as the more common distros (Fedora/Red Hat, Ubuntu, etc). This is what got me into this whole mess, and has again and again. The only way I have been able to successfully stay on top of the latest security patches, bug fixes, feature enhancements, bug releases, etc, is to get the sources and compile them myself. This is not my desired method of system maintenance & software upgrades. But until I migrate to a new server, I'm basically stuck with this.
Anyway, here was my sequence of events, including the problems I found, and how I fixed them:
1.) Downloaded PHP4.4.4 from http://www.php.net
2.) Unpacked the tarball & attempted to ./configure, make, then make install
3.) The process never failed, but gave some errors about needing a newer version of PEAR/XML_RPC
4.) At this point I restarted httpd anyway to see whether this fixed the PHP problems I'd been having with an older & buggy PHP. NO DICE!
5.) I decided to try to fix this PEAR/XML_RPC issue. I googled it, and found a download from the official PEAR site for the latest version. It was just a few .php files inside a tarball. I couldn't really find any info to help me install them, but researching, I was able to find that other people installed it using the pear package manager with the command "pear install XML_RPC" (omit the quotation marks). That sounded simple enough, so I decided it was worth a try.
6.) I used the official pear package manager install method: lynx -source http://go-pear.org/ | php. The installation seemed to complete, but it also gave me messages about not having a new enough version of XML_RPC (I found this to be a bit odd, since I felt like the dependency relationship should have probably been the other way around).
7.) I tried to rebuild PHP at this point, but got the same results.
8.) I then ran an updatedb, and after a few minutes, searched for the same XML_RPC files that I had unpacked. The previous versions were located in my system at: /usr/local/lib/php/test/XML_RPC. Since I couldn't easily locate any instructions for manual installation, I just backed up the current files, and then replaced them with my updated versions (same relative path + since the folder structure wasn't identical between the old & new versions, I copied the files to both directory locations (not a big deal for 2 files). (I'm pretty sure that they only need to be in one of the 2 places, but at this point I don't really care enough to take the time to figure it out [since I eventually did get it working]).
9.) I then re-ran the pear package manager installer. This time, no errors about XML_RPC needing updated ;-)
10.) Then I ran the command pear install XML_RPC, and it said the package was already installed, so I instead ran pear upgrade XML_RPC, and it successfully completed the process (so maybe the XML_RPC files have changed wince step 8 (all the reason more for me to not worry about it now ;-)
11.) I then attempted to recompile PHP. It seemed to do so successfully (no more errors about PEAR/XML_RPC), but after it compiled, I couldn't find the libphp4.so that needed to go in my apache2/modules directory. And after restarting httpd, PHP still seemed to be the old "buggy" version.
12.) I googled something like "libphp4.so" and the first 2-3 results contained the info that I needed (you have to tell the ./configure where your current apache2 apxs executible is.. like this: (./configure --with-apxs2=/usr/local/apache2/bin/apxs" (again, omit the quotes). I actually had to do this a few times, because I had some typos. I also had a truncated file after these typos, and the configure wouldn't run correctly until I deleted the source code altogether, then unpacked it again from the original tarball.
13.) This time took WAY longer than the previous runs... but it worked!!
One other problem I believe is that the 'make install' wants to put the libphp4.so in the correct place (which it did do), however if this file already exists, it doesn't seem to overwrite it, or create one by a different name. So as a precaution, it is probably a good idea to move the current one before running the 'make install'. Then again, I'm not sure than any of the compiling attempts except the last time actually did everything that they were supposed to, so maybe it just wasn't made in any of the compiling attempts prior to the final/successful one. I figure this, because the last build probably took 20 minutes, whereas the previous ones would take 3-5.
Anyway, as previously stated, I hope this helps somebody. The only problem I have with using this GREAT free software (linux, apache, PHP, etc) is that when you get it for free, you may not always get the support/documentation needed.
Cheers.
[ add comment ] | permalink |
( 4 / 1 )Back Next
