Brian Madden made an interesting post today, predicting the end for Citrix XenServer as we know it.
I'm not so sure about the disappearance of Xen from the landscape altogether, but on the disappearance of Citrix XenServer I agree 100%.
I think there's one more aspect worth mentioning that he doesn't touch on... the fact that 99.999% of Citrix admins are Windows admins. Windows admins are about as likely to deploy Linux based solutions as Linux admins are to deploy Windows solutions. Given that the vast majority if x86 virtualisation going on right now involves Windows guests, and there is so much feature parity between XenServer and Hyper-V that it ain't funny, I know which one I'd go with if ESX wasn't an option.
As Brian points out in his post, the value for Citrix in any market has little to do with what's underneath - it's about what they can offer on top. In the virtualisation game, the money for Citrix is in the XenDesktop broker (although currently it's a bit more like a broken than a broker IMHO) - not a Linux based hypervisor.
Citrix knows where their bread is buttered - their position in the market today is based on embracing and extending Microsoft technologies (XenApp for Unix anyone? No, didn't think so). I'm sure it won't take long for Citrix execs to see a gap in the deployment of the XenDesktop broker on ESX / Hyper-V versus the deployment of it on XenServer and wonder why the hell they are even bothering.
[UPDATE] Brian has posted a clarification - turns out I've misinterpreted his original post. Which means I'm going it alone with the prediction of Citrix XenServer's demise (_not_ the demise of the Xen hypervisor), and can claim full credit when it happens :-D
Monday 30 June 2008
Manually Remove Datastores from VirtualCenter 2.0.x Database
Removing invalid datastores from the VirtualCenter database (in 2.0.x at least) is a bit of a pain... y'know, the ones that don't actually surface in the UI but you know are there because you get a "duplicate name" style error when adding a new datastore.
Manually editing the VirtualCenter database should never be taken lightly, and if there's a stored procedure or something that actually does this then someone please let me know. Otherwise, do the following:
1) Stop the VirtualCenter service and BACKUP THE VIRTUALCENTER DATABASE
2) Fire up whatever database management tool you like and connect to the VirtualCenter database.
3) Fire off the following query:
4) Find the offending datastore in the returned results, and make a note of the ID number (the first column)
5) Fire off another query:
6) Delete all rows returned from this query - all the values should be NULL (except the DS_ID column of course)
7) Go back to the VPX_DATASTORE table and delete the row with the non-existent datastore in it
In the case where you have a number of hosts that show as "inaccessible" as a result, you could put together a few more queries to handle that too... or even better do it in PowerShell! Hmmm, will have a look at that a bit later.
Manually editing the VirtualCenter database should never be taken lightly, and if there's a stored procedure or something that actually does this then someone please let me know. Otherwise, do the following:
1) Stop the VirtualCenter service and BACKUP THE VIRTUALCENTER DATABASE
2) Fire up whatever database management tool you like and connect to the VirtualCenter database.
3) Fire off the following query:
select * from VPX_DATASTORE
4) Find the offending datastore in the returned results, and make a note of the ID number (the first column)
5) Fire off another query:
select * from VPX_DS_ASSIGNMENT where DS_ID = id of datatstore to delete from previous query
6) Delete all rows returned from this query - all the values should be NULL (except the DS_ID column of course)
7) Go back to the VPX_DATASTORE table and delete the row with the non-existent datastore in it
In the case where you have a number of hosts that show as "inaccessible" as a result, you could put together a few more queries to handle that too... or even better do it in PowerShell! Hmmm, will have a look at that a bit later.
Sunday 29 June 2008
Hyper-V on Every Box in the Enterprise
Yes, it's more Sunday evening than afternoon but I'm gonna squeeze this one in under the guise of another installment of Sunday Afternoon Architecture And Philosophy.
With the release of Hyper-V 1.0, I got to thinking... why wouldn't you put it on every x64 physical box in the enterprise? Theoretically, the parent partition should incur no virtualisation overhead - it has physical hardware access and doesn't need to worry about managing VM's if it's running on it's own. It doesn't cost anything more for software assurance customers, and let's face it - if you're running a physical box today (and according to IDC and the like, 80-90% of servers are still physical) then almost all the reasons for choosing ESX over Hyper-V simply don't apply as you don't get any of those features with physical boxes anyway. So if that phsyical box is running at 5% resource utilisation and the owner has a need for another environment (be it for dev, UAT, tiering an app, whatever), if we have Hyper-V installed already then we have the potential to exceed expectation by quickly provisioning a box for them that doesn't require the (usually) lengthy process of ordering and racking. If we think of virtualisation purely in terms of maximising hardware utilisation, then as far as I'm concerned there's no argument to be had - I'd rather have one less physical box by running it on Hyper-V than not having Hyper-V at all.
Of course we all know there are so many other benefits to be had by virtualising on VI3, but as I said if only 10% of boxes are virtual currently then we're missing something. Maybe your business is still uncomfortable with virtualisation. Maybe your chargeback model is so close to the cost of physical boxes that your business doesn't care to virtualise (naively ignoring the cost of rack space, power, cooling and having to build a new datacenter when you run out of those). I'm sure there are a myriad of reasons, and even more certain that none of them are technical. But if we can leverage Hyper-V by putting it on every box and giving our business customers a taste of virtualisation, then maybe we can effect a change in attitude. And maybe next time they go to buy that physical box, they'll ask around as to how that virtual box has been running and reconsider. We've tried the 'boil the ocean' approach with virtualisation over the past few years, and it clearly hasn't worked if only 10% of servers are virtual. It's time for baby steps.
So to wrap it up, let me be absolutely clear - I'm not suggesting we start migrating our virtual infrastructures to Hyper-V now or in the forseeable future. What I am suggesting is that we don't write off Hyper-V by comparing it with VI3 and closing the door on it immediately. A slightly unconventional use case it may be, but it could be the most valuable tool we have had so far in assisting with the virtualisation of that other 80% of the enterprise. And I certainly hope that VMware will imminently release an update to Converter to provide full support for V2V from Hyper-V ;-)
With the release of Hyper-V 1.0, I got to thinking... why wouldn't you put it on every x64 physical box in the enterprise? Theoretically, the parent partition should incur no virtualisation overhead - it has physical hardware access and doesn't need to worry about managing VM's if it's running on it's own. It doesn't cost anything more for software assurance customers, and let's face it - if you're running a physical box today (and according to IDC and the like, 80-90% of servers are still physical) then almost all the reasons for choosing ESX over Hyper-V simply don't apply as you don't get any of those features with physical boxes anyway. So if that phsyical box is running at 5% resource utilisation and the owner has a need for another environment (be it for dev, UAT, tiering an app, whatever), if we have Hyper-V installed already then we have the potential to exceed expectation by quickly provisioning a box for them that doesn't require the (usually) lengthy process of ordering and racking. If we think of virtualisation purely in terms of maximising hardware utilisation, then as far as I'm concerned there's no argument to be had - I'd rather have one less physical box by running it on Hyper-V than not having Hyper-V at all.
Of course we all know there are so many other benefits to be had by virtualising on VI3, but as I said if only 10% of boxes are virtual currently then we're missing something. Maybe your business is still uncomfortable with virtualisation. Maybe your chargeback model is so close to the cost of physical boxes that your business doesn't care to virtualise (naively ignoring the cost of rack space, power, cooling and having to build a new datacenter when you run out of those). I'm sure there are a myriad of reasons, and even more certain that none of them are technical. But if we can leverage Hyper-V by putting it on every box and giving our business customers a taste of virtualisation, then maybe we can effect a change in attitude. And maybe next time they go to buy that physical box, they'll ask around as to how that virtual box has been running and reconsider. We've tried the 'boil the ocean' approach with virtualisation over the past few years, and it clearly hasn't worked if only 10% of servers are virtual. It's time for baby steps.
So to wrap it up, let me be absolutely clear - I'm not suggesting we start migrating our virtual infrastructures to Hyper-V now or in the forseeable future. What I am suggesting is that we don't write off Hyper-V by comparing it with VI3 and closing the door on it immediately. A slightly unconventional use case it may be, but it could be the most valuable tool we have had so far in assisting with the virtualisation of that other 80% of the enterprise. And I certainly hope that VMware will imminently release an update to Converter to provide full support for V2V from Hyper-V ;-)
Thursday 26 June 2008
Hyper-V 1.0 released - let the Hyper-bole begin!
Well it's all over the web, and I generally try not to report on stuff that everyone else does but I'm making an exception this time... more so I can remember the date than anything else ;-)
Download here now!
Download here now!
Wednesday 25 June 2008
Citrix Connection Broker Sends Support 6 Years Backwards?
To be fair to Citrix, I'll start by saying that this appears to be a Microsoft bug. But that doesn't change the magnitude of what can only be described as a monumental clusterfuck - it doesn't matter who's at fault, the problem exists today and will exist in the forseeable future unless we as Citrix and Microsoft customers put the hard word on both companies, now. And that is the absolute intention of this post - not to rubbish Citrix or Microsoft, but to get a strong message out that this needs to be fixed yesterday.
As far as I'm concerned, if you're a big Citrix shop then there is no other choice for a broker - the integration with XenApp's Web Interface, the soon-to-be single client, and the power of ICA on the desktop... it's pretty much a no brainer if you have a lot of this technology in your estate already. And even more of a no brainer if your VDI users are on the end of a >100ms latency.
Except that it could cripple your support organisation.
There is a bug that manifests when an RDP connection is made to Session0 (ie, the console session) which effectively renders the PortICA stack inoperable after that connection is terminated. That is to say, when someone uses Remote Assistance to get support, they will not be able to reconnect to that desktop via ICA after the session is terminated without a reboot of the box. So what do Citrix recommend you do to avoid this problem? Disable RDP of course!
[EDIT] I didn't explain it very well above... connecting via RDP to the console of a machine running XenDesktop 2.0 results in (a) the ICA session terminating immediately and (b) the box rebooting automatically after the RDP session is terminated.
But since XenDesktop actually remotes the physical display of the machine, the console is completely black when viewed via the VI client or VI Web Access so you can't use that for remote support. And you can't shadow PortICA sessions like you can with server-side ICA sessions either. But you don't need remote assistance... do you?
Almost every large enterprise I have worked has a remote first line of support. And almost as common is the outsourcing of the 2nd line desktop support, ie the ppl who perpetuate sneakernet. And most of those large enterprises stopped paying for 3rd party remote support solutions long ago (a substantial saving for places with over 50K desktops). Remote Assistance is a critical tool, both for speedy case resolution and for keeping support costs down (those physcial bodies are way more expensive than the ones on the end of the phone), both of which make for happy users and a happy business. Well, happier users and business at least. And it all comes free with Windows XP.
Hence the Citrix recommended workaround for this problem of disabling RDP if you install XenDesktop is utterly ridiculous and untenable IMHO. After spending years worth of time and who knows how much money on training your users to use Remote Assistance, you now have to switch it off and find some other way to get the functionality? Might that be buying GoToAssist by any chance? If Citrix have any hope of a quick resolution to this problem, they had better start bundling that with the XenDesktop standard edition license. Or get the session shadowing capabilities that have been available in Presentation Server for many years into XenDesktop ASAP.
So getting back to where this post started, XenDesktop 2.0 in its current state may send you right back to the pre-XP days, where a physical body had to go to a users desk in order to observe, understand and resolve a problem. Or you had to pay through the nose for a 3rd party remote support tool.
I don't know which is sadder - the fact that a phsyical person may need to go to a physical desk to fix a problem on a machine that isn't physically there, or the irony that a company who prides themselves of providing remote access solutions could put us in this position.
As far as I'm concerned, if you're a big Citrix shop then there is no other choice for a broker - the integration with XenApp's Web Interface, the soon-to-be single client, and the power of ICA on the desktop... it's pretty much a no brainer if you have a lot of this technology in your estate already. And even more of a no brainer if your VDI users are on the end of a >100ms latency.
Except that it could cripple your support organisation.
There is a bug that manifests when an RDP connection is made to Session0 (ie, the console session) which effectively renders the PortICA stack inoperable after that connection is terminated. That is to say, when someone uses Remote Assistance to get support, they will not be able to reconnect to that desktop via ICA after the session is terminated without a reboot of the box. So what do Citrix recommend you do to avoid this problem? Disable RDP of course!
[EDIT] I didn't explain it very well above... connecting via RDP to the console of a machine running XenDesktop 2.0 results in (a) the ICA session terminating immediately and (b) the box rebooting automatically after the RDP session is terminated.
But since XenDesktop actually remotes the physical display of the machine, the console is completely black when viewed via the VI client or VI Web Access so you can't use that for remote support. And you can't shadow PortICA sessions like you can with server-side ICA sessions either. But you don't need remote assistance... do you?
Almost every large enterprise I have worked has a remote first line of support. And almost as common is the outsourcing of the 2nd line desktop support, ie the ppl who perpetuate sneakernet. And most of those large enterprises stopped paying for 3rd party remote support solutions long ago (a substantial saving for places with over 50K desktops). Remote Assistance is a critical tool, both for speedy case resolution and for keeping support costs down (those physcial bodies are way more expensive than the ones on the end of the phone), both of which make for happy users and a happy business. Well, happier users and business at least. And it all comes free with Windows XP.
Hence the Citrix recommended workaround for this problem of disabling RDP if you install XenDesktop is utterly ridiculous and untenable IMHO. After spending years worth of time and who knows how much money on training your users to use Remote Assistance, you now have to switch it off and find some other way to get the functionality? Might that be buying GoToAssist by any chance? If Citrix have any hope of a quick resolution to this problem, they had better start bundling that with the XenDesktop standard edition license. Or get the session shadowing capabilities that have been available in Presentation Server for many years into XenDesktop ASAP.
So getting back to where this post started, XenDesktop 2.0 in its current state may send you right back to the pre-XP days, where a physical body had to go to a users desk in order to observe, understand and resolve a problem. Or you had to pay through the nose for a 3rd party remote support tool.
I don't know which is sadder - the fact that a phsyical person may need to go to a physical desk to fix a problem on a machine that isn't physically there, or the irony that a company who prides themselves of providing remote access solutions could put us in this position.
Tuesday 17 June 2008
New(ish) blog by Chad Sakac - bookmark / add feed NOW!
Quite a few things of note happened while I was away, but one thing that didn't seem to be widely reported was the launch of Chad Sakac's blog. Chad has bolted from the gate with some great posts which I won't bother linking because you should just hit his blog and read everything.
I also owe him a public apology - a while back I posted about storage stuff and made a flippant remark about "some marketing guy" in an EMC video on You Tube, which was Chad. We've had a fair bit of correspondence since then, and he is obviously about as far from a marketer as you can get. Sorry about that mate, and welcome to the blogosphere :-)
I also owe him a public apology - a while back I posted about storage stuff and made a flippant remark about "some marketing guy" in an EMC video on You Tube, which was Chad. We've had a fair bit of correspondence since then, and he is obviously about as far from a marketer as you can get. Sorry about that mate, and welcome to the blogosphere :-)
Subscribe to:
Posts (Atom)