xenserver update v08.27.08.txt
Ok, after giving it as much hopeful effort as possible, I have decided that it isn't worth the effort at this point to try and fit XenServer into our enterprise environment. I had my concerns with no support for FC and the lack of NIC bonding since 4.0 with Xensource. I patiently awaited 4.1 and have recently finished testing the latest beta to host the new XenApp 4.5 farm.
Problems:
It takes way to long to load an initial Windows 2003 OS without the PV drivers in order to make the first template.
NIC Bonding and Trunking.. seriously, I would think this is equivalent to "anti-virus" for any product with the word "Enterprise" in the name. So why is it so difficult? VMware has a very easy to use section during the gui install that clearly lets you define the VLAN that the management interface will reside on. This indicates that they already assume you will be trunking (802.1q) if you enter something here.
In XenServer world, this is all after the fact.. it is a pain tweaking switch settings while simultaneously modifying configurations within XenCenter in order for the connection not to timeout when going from "switchport mode access" to "switchport mode trunk".. likewise when you enable channel-groups.
So, after getting somewhat of a process down to get a bond0+1 with the management interface in the proper vlan, I decide to bring up host two and create a resource pool.. oh no, that isn't possible if the management nic is in a bond or vlan.. ok, undo everything I just did and setup the master of the resource pool... Good, now redo the bonding and vlans, great.. add the second server.. nope.. looses connectivity because it inherits the bonds and vlans.. so I guess I'd need to be making those switch changes at the same time, but bottom line is that it was more than I cared to document for anyone else to try and follow.. Getting past EtherChannel and dot1q is enough for anyone to tackle without all of the added headaches.. and btw, it just works under VMware and there is no special technote article telling you to match up UUID's that are much longer than WWNs anyday :)
Also, the ISO issue was a pain.. I didn't want to setup a CIFS or NFS store, I just wanted to boot from a Windows 2003 Ent Svr R2 iso and get my os installed.. in VMware land that is just "connect/disconnect".. so I setup a local iso repository using the iso-mount folder, found a few document inconsistencies and got through it. Still.. more trouble than it is worth.
All in all, I would say that Xen will contribute greatly to the fall of VMware over time, but in the mean time, I have a XenApp farm that wants to come to life! Thank you VMware for releasing the free ESXi.. I have no problems managing each host individually with the VI client.. afterall, the real management of the farm will be within the Citrix Access Management Console and if the servers are dense enough I wouldn't really be interested in a VMotion or XenMotion..
Oh yeah, and the LVM stuff is still concerning me.. I'd still like to understand why a filesystem that is documented many times on the net as not being cluster aware is being used by XenServer? Not that big of a deal, but not sure why GFS or something made for that purpose wasn't used instead of somehow making LVM work in a clustered environment. If it wasn't that big of a deal, I'd like to see active contributions back to the open source community for LVM to help advertise it as cluster aware.. seeing as how Citrix didn't license RHEL and chose to use CentOS for their "service console" I don't think they should have a problem saying you don't need GFS for an enterprise cluster-aware filesystem. Now, VMware gets all of the marketing flack about VMFS3 as it is "proprietary"... I think those folks need to look back at NTFS from Microsoft and realize a proprietary filesystem right in front of them. It's still not too easy to get a read/write driver for Linux for NTFS!
Problems:
It takes way to long to load an initial Windows 2003 OS without the PV drivers in order to make the first template.
NIC Bonding and Trunking.. seriously, I would think this is equivalent to "anti-virus" for any product with the word "Enterprise" in the name. So why is it so difficult? VMware has a very easy to use section during the gui install that clearly lets you define the VLAN that the management interface will reside on. This indicates that they already assume you will be trunking (802.1q) if you enter something here.
In XenServer world, this is all after the fact.. it is a pain tweaking switch settings while simultaneously modifying configurations within XenCenter in order for the connection not to timeout when going from "switchport mode access" to "switchport mode trunk".. likewise when you enable channel-groups.
So, after getting somewhat of a process down to get a bond0+1 with the management interface in the proper vlan, I decide to bring up host two and create a resource pool.. oh no, that isn't possible if the management nic is in a bond or vlan.. ok, undo everything I just did and setup the master of the resource pool... Good, now redo the bonding and vlans, great.. add the second server.. nope.. looses connectivity because it inherits the bonds and vlans.. so I guess I'd need to be making those switch changes at the same time, but bottom line is that it was more than I cared to document for anyone else to try and follow.. Getting past EtherChannel and dot1q is enough for anyone to tackle without all of the added headaches.. and btw, it just works under VMware and there is no special technote article telling you to match up UUID's that are much longer than WWNs anyday :)
Also, the ISO issue was a pain.. I didn't want to setup a CIFS or NFS store, I just wanted to boot from a Windows 2003 Ent Svr R2 iso and get my os installed.. in VMware land that is just "connect/disconnect".. so I setup a local iso repository using the iso-mount folder, found a few document inconsistencies and got through it. Still.. more trouble than it is worth.
All in all, I would say that Xen will contribute greatly to the fall of VMware over time, but in the mean time, I have a XenApp farm that wants to come to life! Thank you VMware for releasing the free ESXi.. I have no problems managing each host individually with the VI client.. afterall, the real management of the farm will be within the Citrix Access Management Console and if the servers are dense enough I wouldn't really be interested in a VMotion or XenMotion..
Oh yeah, and the LVM stuff is still concerning me.. I'd still like to understand why a filesystem that is documented many times on the net as not being cluster aware is being used by XenServer? Not that big of a deal, but not sure why GFS or something made for that purpose wasn't used instead of somehow making LVM work in a clustered environment. If it wasn't that big of a deal, I'd like to see active contributions back to the open source community for LVM to help advertise it as cluster aware.. seeing as how Citrix didn't license RHEL and chose to use CentOS for their "service console" I don't think they should have a problem saying you don't need GFS for an enterprise cluster-aware filesystem. Now, VMware gets all of the marketing flack about VMFS3 as it is "proprietary"... I think those folks need to look back at NTFS from Microsoft and realize a proprietary filesystem right in front of them. It's still not too easy to get a read/write driver for Linux for NTFS!
Comments