Appliance testing - none of you would do this would you ?

[SimonH2]

Whether 100% of them can ultimately be resolved is one thing, but are you denying that such tools can discover them?

In the case I have in mind, yes I do believe that such tools would not pick up the dependency. OK, IF I tell it enough details about the items in question then it could work it out - but then I've done all the hard work of finding the elements that have the dependencies. That's a far cry from your inference that automation tools will "just sort that out".

So a less than 100% coverage means complete failure, and utter uselessness of the tools and techniques etc, does it, and your example means that nobody, anywhere, can ever get any benefits from them?

For a man that likes to criticise others for putting words in other peoples minds, you do a lot of it. Please show where I have said that such tools do not have any use anywhere ? What I've said is that for our use case, and many others I know of, the tools aren't appropriate (for everything, we do in fact use a number of tools) - I believe I've also said that for others it's a different matter. Even where the tools are appropriate, it's not as simple as you first seemed to be implying - and from where you appear to have backtracked significantly.

Your example means that there are no situations where it becomes easier to start up servers with dependencies if you can have, in effect dozens of discrete servers instead of just a few?

Have I said that, once again you are criticising me for things I haven't said. A common saying involving the words "pot", "kettle", and "black" comes to mind.

Then finally, having stated that automation tools will solve our dependency problem, you add "No tool will do everything" which is effectively all that people had been telling you.

What you said was this:

either that or your identity is revealed as one of those IT tools salesmen who will happily sell your tool as doing all that and more (probably even makes the coffee) but which actually turns out to have a lot of gaps.

Of course no one tool will "do all that and more" as you seem to think I was claiming. But that does not mean that what a particular tool does is of no value. Somewhere in the garage I've got a piston ring compressor. Unbelievably useful when reassembling pistons to insert into a cylinder block, but does the fact that it won't also torque the head bolts mean that it's useless, I shouldn't have it, and that anybody who extolls the benefit of them should be castigated?

No, but you did not try and sell a piston ring compressor for fitting pistons in blocks. You appeared to be suggesting that you had a tool in mind that would automatically align the gaps, insert the piston, fit the bearing cap, and brew up when it's done. I've sat through enough presentations that seem to be selling an IT tool like that - and your comments sounded just like those sales people.

And add "of course you'll need to customise it and quite possibly have to write some scripts" - in other words, we could write some scripts to handle it (and which would be completely unrelated to virtualisation).

I said that the VM manager MAY have automation tools.

That means it MAY NOT.

So does that mean that if a virtualisation product has no such feature that it's no good?

So now you've turned round from "virtualisation WILL do all this for you" to "some virtualisation tools, if you have the right setup, and you put work into customising them, might be able to do some tasks".

Well "Durrr", yes we could, but as I pointed out, if it only takes a few minutes to manually deal with it once in a blue moon, why spend a lot of time automating it ?

No reason at all.

My apologies - I guess I just hadn't realised that every single IT shop in the world was exactly like yours, and that because it's not a problem for you then it's not a problem for anybody, anywhere, and that therefore nobody can benefit from automation and all vendors of such tools are charlatans.

Thank you for clarifying that.

Anf thank you for proving beyond all doubt what others have already pointed out - you are trolling. Given that I have expressly pointed out that different outfits have different needs, your comment is just so wrong on so many counts. Once again, you've made up a POV that differs from reality and then criticise me for it.

And now, barely 1/2 way down page two we get "I thought I could take it as read that without all server resources virtualised and without a common storage and network infrastructure shared by source and target then live migration won't work."
Guess what, I know far more virtualisation installs that do NOT have all that expensive overhead than do.

And can those people move live VMs from one server to another?

Please list those virtualisation products that CAN do a live migration without shared storage separate to the servers. You now seem to be backtracking from "I assumed everyone else would assume that this was in place" to "can be done without so it's irrelevant".

So now an admission that "Just virtualise it" now means "double your server capacity, add backend storage that probably costs more than the servers, and the infrastructure to link them, and the software to glue it all together".

But double your server capacity? You might like to do some reading up on statistical multiplexing and the central limit theory, and how they apply to virtualised servers.

I don't need to look up any of that. You have a quart pot containing a quart of <something>. You want to be able to empty that quart pot temporarily - that means having at least another quart pot of storage. In the same way, if you have a single server, and want to empty it for maintenance by migrating the VMs to another server, then you need another server with enough capacity to hold and run all the VMs. Unless the first machine was somewhat over-specced, then the second one will need to be fairly similar in capacity to hold and run all the VMs you've migrated. Or do you have in mind some magical virtualisation technology that bypasses such inconveniences ?

perhaps now you can address this:

Can't be a**ed - you didn't listen earlier, and I don't expect you will now.

 

[ban-all-sheds]

In the case I have in mind, yes I do believe that such tools would not pick up the dependency.

In the case you have in mind.... In the case you have in mind.... In the case you have in mind....

Tell me - is the case you have in mind perfectly representative of every singe case in the world?

Are you claiming that there are no dependency discovery tools which will ever find any dependencies anywhere?

For a man that likes to criticise others for putting words in other peoples minds, you do a lot of it. Please show where I have said that such tools do not have any use anywhere ?

You haven't, which is why it was a question, because all the way through this, you have done virtually nothing except attack my suggestion, and say I don't know what I'm talking about because in some cases problems are too intractable to be easily addressed by automation.

Even where the tools are appropriate, it's not as simple as you first seemed to be implying - and from where you appear to have backtracked significantly.

Not backtracked. Just qualified what I said as it dawned on me that you were reacting as if you thought I believed that you could stick in a DVD, click an install button, go off for lunch and cone back to find everything sorted for you.

That would be such a facile suggestion that it beggars belief that you'd interpret what I wrote in that way, but that does seem to be the case.

Your example means that there are no situations where it becomes easier to start up servers with dependencies if you can have, in effect dozens of discrete servers instead of just a few?

Have I said that, once again you are criticising me for things I haven't said.

No, I'm asking a question.

Once again you are having problems reading.

This : ? means I'm asking you a question, not making an assertion.

No, but you did not try and sell a piston ring compressor for fitting pistons in blocks. You appeared to be suggesting that you had a tool in mind that would automatically align the gaps, insert the piston, fit the bearing cap, and brew up when it's done.

I do appear to have seriously overestimated your intelligence.

That anybody could possibly think I was being that facile does, as I said, beggar belief.

I've sat through enough presentations that seem to be selling an IT tool like that - and your comments sounded just like those sales people.

You need to change your IT suppliers.

So now you've turned round from "virtualisation WILL do all this for you"

I never said that.

It's just your febrile imagination leading you to think to that I did.

Anf thank you for proving beyond all doubt what others have already pointed out - you are trolling. Given that I have expressly pointed out that different outfits have different needs, your comment is just so wrong on so many counts. Once again, you've made up a POV that differs from reality and then criticise me for it.

The reality is that right from the outset you have said that I was wrong to suggest virtualisation as a way to avoid the impact of planned server shutdowns.

Not wrong in some cases, not wrong for you, just plain, flat out wrong, and not only wrong, but ignorant.

Ditto dependency discovery tools.

Ditto automation.

And now, barely 1/2 way down page two we get "I thought I could take it as read that without all server resources virtualised and without a common storage and network infrastructure shared by source and target then live migration won't work."
Guess what, I know far more virtualisation installs that do NOT have all that expensive overhead than do.

And can those people move live VMs from one server to another?

Please list those virtualisation products that CAN do a live migration without shared storage separate to the servers.

I'm not aware of any.

Which was precisely my point. When I suggested live migration of virtual machines, it was just as stupid for you to criticise it on the grounds that it can't be done without shared external storage as it would be for you to criticise a suggestion to use a toaster for making toast on the grounds that it won't work without electricity.

now seem to be backtracking from "I assumed everyone else would assume that this was in place" to "can be done without so it's irrelevant".

Are you being deliberately obtuse?

I don't need to look up any of that.

Actually you do, you really really do, because they are fundamental to why virtualisation tends to mean fewer resources needed, not more.

You have a quart pot containing a quart of <something>. You want to be able to empty that quart pot temporarily - that means having at least another quart pot of storage. In the same way, if you have a single server, and want to empty it for maintenance by migrating the VMs to another server, then you need another server with enough capacity to hold and run all the VMs. Unless the first machine was somewhat over-specced, then the second one will need to be fairly similar in capacity to hold and run all the VMs you've migrated. Or do you have in mind some magical virtualisation technology that bypasses such inconveniences ?

No - I have in mind the situation where instead of having lots and lots of quart pots which actually each contain only a teacup-full of <something> you have a smaller number of quart (and possibly gallon- or half-gallon pots) each of which contains many different teacup-fulls of <somethings>, and where you have enough spare capacity to be able to redistribute the teacups from one pot, possibly by removing ones of less importance from some of the other pots, possibly by making people manage with coffee cups for a while. But certainly not an environment where you need to double up on everything.

Can't be a**ed - you didn't listen earlier, and I don't expect you will now.

It's not a question of not listening - you really have not shown where I said I wanted to do what you said I did.

 

[SimonH2]

In the case I have in mind, yes I do believe that such tools would not pick up the dependency.

In the case you have in mind.... In the case you have in mind.... In the case you have in mind....

Tell me - is the case you have in mind perfectly representative of every singe case in the world?

No, I have never suggested such a thing, so why do you keep asking it as though I had ?

Are you claiming that there are no dependency discovery tools which will ever find any dependencies anywhere?

No, I have never suggested such a thing, so why do you keep asking it as though I had ?

For a man that likes to criticise others for putting words in other peoples minds, you do a lot of it. Please show where I have said that such tools do not have any use anywhere ?

You haven't, which is why it was a question, because all the way through this, you have done virtually nothing except attack my suggestion, and say I don't know what I'm talking about because in some cases problems are too intractable to be easily addressed by automation.No, I have never suggested such a thing, so why do you keep asking it as though I had ?

I attacked your inference that every problem can be easily and best solved by automation tools, in just the same way that I attacked your inference that all server shutdown issues can be easily and best solved just by virtualisation. So here we are again, you attack me for picking up on your incorrect inferences - which you have later backtracked on.

Even where the tools are appropriate, it's not as simple as you first seemed to be implying - and from where you appear to have backtracked significantly.

Not backtracked. Just qualified what I said as it dawned on me that you were reacting as if you thought I believed that you could stick in a DVD, click an install button, go off for lunch and cone back to find everything sorted for you.

That would be such a facile suggestion that it beggars belief that you'd interpret what I wrote in that way, but that does seem to be the case.

Had I believed such a thing then you would be correct. That fact that I questioned your assertions should show that.

Your example means that there are no situations where it becomes easier to start up servers with dependencies if you can have, in effect dozens of discrete servers instead of just a few?

Have I said that, once again you are criticising me for things I haven't said.

No, I'm asking a question.

Once again you are having problems reading.

This : ? means I'm asking you a question, not making an assertion.

Yes, I know what a question mark means - it usually comes at the end of a question. Your question also makes a statement - the basis of your question relies on a statement of fact which attribute to me, but which I have not made.

No, but you did not try and sell a piston ring compressor for fitting pistons in blocks. You appeared to be suggesting that you had a tool in mind that would automatically align the gaps, insert the piston, fit the bearing cap, and brew up when it's done.

I do appear to have seriously overestimated your intelligence.

That anybody could possibly think I was being that facile does, as I said, beggar belief.

That someone could consider your statements that facile says a lot about your statements. But, I go by what you write - and the very clear inference from your line of reasoning is that automation tools are a lot easier to use and more capable than I believe is the case.

I've sat through enough presentations that seem to be selling an IT tool like that - and your comments sounded just like those sales people.

You need to change your IT suppliers.

You think I buy as a result of such presentations ?

So now you've turned round from "virtualisation WILL do all this for you"

I never said that.

It's just your febrile imagination leading you to think to that I did.

Apparently I'm not alone in that interpretation of what your wrote.

Anf thank you for proving beyond all doubt what others have already pointed out - you are trolling. Given that I have expressly pointed out that different outfits have different needs, your comment is just so wrong on so many counts. Once again, you've made up a POV that differs from reality and then criticise me for it.

The reality is that right from the outset you have said that I was wrong to suggest virtualisation as a way to avoid the impact of planned server shutdowns.

Not wrong in some cases, not wrong for you, just plain, flat out wrong, and not only wrong, but ignorant.

No, here we go again. I did not say that - you are doing exactly what you keep criticising others for.

Ditto dependency discovery tools.

Ditto. No I didn't.

Ditto automation.

Ditto again.

Show me where I have said that virtualisation and automation tools have no use, anywhere, to anyone ?

Please list those virtualisation products that CAN do a live migration without shared storage separate to the servers.

I'm not aware of any.

So now we go from "just virtualise it" to "just virtualise it - but it'll only work if you add a shedload of infrastructure".

Which was precisely my point. When I suggested live migration of virtual machines, it was just as stupid for you to criticise it on the grounds that it can't be done without shared external storage as it would be for you to criticise a suggestion to use a toaster for making toast on the grounds that it won't work without electricity.

And what about the toasters that do work without electricity ?

Virtualisation is not a single tool - it's a range of tools, all with different characteristics and different strengths and weaknesses. Just saying virtulisation without any qualifiers is just plain dumb - do you mean the most basic (such as Xen or Hyper-V without any shared storage), or the other extreme (such as full VMWare stack with all the bells and whistles), or something in between. You seem to have this idea that virtualisation is only the latter - and appear to have taken offence to having the existence of the other options being pointed out.

now seem to be backtracking from "I assumed everyone else would assume that this was in place" to "can be done without so it's irrelevant".

Are you being deliberately obtuse?

No, just stating an observation.

I don't need to look up any of that.

Actually you do, you really really do, because they are fundamental to why virtualisation tends to mean fewer resources needed, not more.

I'm fully aware of that aspect of virtualisation. Yes, I really am.

You have a quart pot containing a quart of <something>. You want to be able to empty that quart pot temporarily - that means having at least another quart pot of storage. In the same way, if you have a single server, and want to empty it for maintenance by migrating the VMs to another server, then you need another server with enough capacity to hold and run all the VMs. Unless the first machine was somewhat over-specced, then the second one will need to be fairly similar in capacity to hold and run all the VMs you've migrated. Or do you have in mind some magical virtualisation technology that bypasses such inconveniences ?

No - I have in mind the situation where instead of having lots and lots of quart pots which actually each contain only a teacup-full of <something> you have a smaller number of quart (and possibly gallon- or half-gallon pots) each of which contains many different teacup-fulls of <somethings>, and where you have enough spare capacity to be able to redistribute the teacups from one pot, possibly by removing ones of less importance from some of the other pots, possibly by making people manage with coffee cups for a while. But certainly not an environment where you need to double up on everything.

And for the situation where there really is only one quart pot, which does contain a quart of <something> ? Or are you incapable of reading what I wrote ?
I might add, that in terms of numbers, the vast majority of installations really are (I believe) just one or two single servers. Larger installations with multiple servers and shared storage really constitute a much. much smaller proportion of installations.

Can't be a**ed - you didn't listen earlier, and I don't expect you will now.

It's not a question of not listening - you really have not shown where I said I wanted to do what you said I did.

You just haven't read it.

 

[ban-all-sheds]

No, I have never suggested such a thing, so why do you keep asking it as though I had ?

No, I have never suggested such a thing, so why do you keep asking it as though I had ?

Because of your consistent unqualified criticism.

So virtualise them all, then you can move the VMs and empty the physical server.

Says the man demonstrating a politicians level of knowledge of technical matters

Sorry BAS, there is a saying that when you are in a hole, stop digging. You clearly know the buzzwords, but also clearly don't have practical experience - either that or your identity is revealed as one of those IT tools salesmen who will happily sell your tool as doing all that and more (probably even makes the coffee) but which actually turns out to have a lot of gaps.

Those are NOT qualified assessments of what I said - they are blanket rejections.

Yes, automation tools can help, but mostly (for the general case) they are all custom - our setup isn't the same as other people's, the next guys's setup is different, and so on, so there is no such thing as an off the shelf tool that will do it.

That IS you assuming that I would be so facile as to claim that you can bang in a tool and expect it to work out of the box with no customisation, no integration, no scripting etc.

I am 100% correct that if you virtualise your servers you can move VMs around if you need to empty a server but keep the services running. Along with increased server utilisation the ability to relocate VMs is a major benefit of virtualisation.

Someone has been reading the glossy handouts.
Yes, virtualisation may allow VMs to be moved around. It depends on which virtualisation technology and what your infrastructure is. It's not as simple as "click here, and your VM magically moves" though.

That IS you assuming that I was being so facile as to claim that moving a VM is that simple. (Although it shoudln't be exactly difficult).

Firstly you have to have space for it on the destination - which means having excess capacity which is what virtualisation is (in part) intended to avoid.

That IS you assuming that I don't understand something so blindingly obvious. So blindingly obvious in fact that it no more needs to be stated than saying "of course you'll need somewhere to park the car when you get there".

In the case of the original situation I posted about, this was a standalone server, specifically located in a separate building to their main servers - and used in a manner where it would not have been a problem to shut it down.

That IS you attempting to twist my reply to this:

Asking people to log off to be able to test is common and with servers finding windows to do work again common. But switching off is still a problem.

into something which becomes an inappropriate suggestion for one specific server of yours.

In other words, build the tools needed

That IS you assuming I was suggesting you can bang in a tool and expect it to work out of the box with no customisation, no integration, no scripting etc.

There are also a shedload of other systems, from disparate vendors, running a variety of operating systems and virtualisation technologies

That IS you assuming that I'm unaware of the challenges associated with management of heterogeneous environments.

Having discussed it with others in similar situations, it's clear that there isn't a simple answer - and definitely not one off the shelf.

That IS you assuming I was suggesting you can bang in a tool and expect it to work out of the box with no customisation, no integration, no scripting etc.

It builds on rapid provisioning and policy/time-based automation of VM relocation.

No, I change my mind. You're not an IT salesman, it's far far worse than that - you speak like a ... and I feel a bit dirty even using the words ... a management consultant

That is NOT a qualified assessment of what I said - it is a blanket and disparaging rejection.

It IS a complete rejection of the idea that virtualisation can enable rapid provisioning.

It IS a complete rejection of the idea that there is such a thing as policy/time-based automation of VM relocation.


I'm not going to go over every one of your posts - throughout this thread you have consistently acted as if you thought I was unaware of things so fundamental, so blindingly obvious as to genuinely be analogous to needing roads to drive a car on, or electricity to power a toaster.

You have consistently criticised what I say because you have chosen to interpret it as me claiming that <whatever> is universally applicable to all situations and can be done with the click of a button.

And whenever I've said, in effect, "well, durr - of course you need <some blindingly obvious prerequisite>", or "of course you need to do <some blindingly obvious tailoring/scripting/integration work>" you have consistently described that as "backtracking". Presumably from an incredibly facile position which I never took, but which you incorrectly inferred.

I attacked your inference that every problem can be easily and best solved by automation tools, in just the same way that I attacked your inference that all server shutdown issues can be easily and best solved just by virtualisation. So here we are again, you attack me for picking up on your incorrect inferences - which you have later backtracked on.

An inference is something you draw, not something I make.

And yours are deeply flawed.

But, I go by what you write - and the very clear inference from your line of reasoning is that automation tools are a lot easier to use and more capable than I believe is the case.

No - that's you incorrectly assuming that because I didn't keep stating the blindingly obvious I'm unaware of it.

The reality is that right from the outset you have said that I was wrong to suggest virtualisation as a way to avoid the impact of planned server shutdowns.

Not wrong in some cases, not wrong for you, just plain, flat out wrong, and not only wrong, but ignorant.

No, here we go again. I did not say that - you are doing exactly what you keep criticising others for.

So virtualise them all, then you can move the VMs and empty the physical server.

Says the man demonstrating a politicians level of knowledge of technical matters

Please list those virtualisation products that CAN do a live migration without shared storage separate to the servers.

I'm not aware of any.

So now we go from "just virtualise it" to "just virtualise it - but it'll only work if you add a shedload of infrastructure".

No - we don't go from anything to anything.

We start with a situation with such blindingly f*****g obvious prerequisites that for you to infer that me not stating them equates to me not being aware of them is at best stupid and at worst maliciously offensive.

And what about the toasters that do work without electricity ?

Toaster.

Not gas grill. Not wood fired oven. Not blowtorch. Toaster.

Virtualisation is not a single tool - it's a range of tools, all with different characteristics and different strengths and weaknesses. Just saying virtulisation without any qualifiers is just plain dumb - do you mean the most basic (such as Xen or Hyper-V without any shared storage), or the other extreme (such as full VMWare stack with all the bells and whistles), or something in between.

I mean the one(s) which provide the features you want.

You seem to have this idea that virtualisation is only the latter - and appear to have taken offence to having the existence of the other options being pointed out.

You seem to have this idea that so I am completely unaware of things so blindingly f*****g obvious for that idea to be at best stupid and at worst maliciously offensive.

I'm fully aware of that aspect of virtualisation. Yes, I really am.

So why write this:

No mention at this point that "Just virtualise it" doesn't mention the trebling (or more) of the cost of the hardware,...."Just virtualise it" now means "double your server capacity...

Can't be a**ed - you didn't listen earlier, and I don't expect you will now.

It's not a question of not listening - you really have not shown where I said I wanted to do what you said I did.

You just haven't read it.

Well let me try reading it all again.

I'll start with this:

Who on earth (apart from BAS) wants to put their BACKUP data on the same storage as their live data, and be able to switch the VM of the backup to the same box as their live server ?

And the first time I asked you about it.

And I've suggested those things where, exactly?

Your reply was:

Where you wrote :

Asking people to log off to be able to test is common and with servers finding windows to do work again common. But switching off is still a problem.

So virtualise them all, then you can move the VMs and empty the physical server.

So I have read that reply, and it does NOT answer my question, i.e. it does NOT show where I've suggested the things you say I have.

Nor does it show where it could be inferred, even by your lamentable standards.

And the next times I asked you:

So I'll ask you again:

Where have I suggested putting backup data on the same storage as the live data, and where have I suggested moving the VM of the backup to the same box as the live one?

Anyway - glad you're back, perhaps now you can address this:

Who on earth (apart from BAS) wants to put their BACKUP data on the same storage as their live data, and be able to switch the VM of the backup to the same box as their live server ?

I said that where, exactly?

Your answer:

Can't be a**ed - you didn't listen earlier, and I don't expect you will now.

But as I pointed out:

It's not a question of not listening - you really have not shown where I said I wanted to do what you said I did.

You really haven't.

The only time you gave an answer other than "can't be a**sed", or "you just haven't read it" was the first time, and your answer was

Where you wrote :

Asking people to log off to be able to test is common and with servers finding windows to do work again common. But switching off is still a problem.

So virtualise them all, then you can move the VMs and empty the physical server.

 

[SimonH2]

I'm not going to do a point by point analysis - it won't make any difference to the man who can't/won't accept that possibly something he wrote might actually be validly construed to mean something that someone else disagrees with. I'll just leave others to make their own minds up.

And "all toasters need electricity"

 

[ban-all-sheds]

There's a big difference from validly construing what someone says and making assumptions that that someone is facile, and ignorant of blindingly obvious things, and which are at best stupid and at worst maliciously offensive.


Toasters:

 

[SimonH2]

... at worst maliciously offensive.

Yes, you have been, apology accepted.

Toasters:

Oh very pretty

 

[ban-all-sheds]

... at worst maliciously offensive.

Yes, you have been, apology accepted.

 

[bernardgreen]

No electricty here

 

[SimonH2]

No electricty here

You can also get various gas-powered toasters as well. Hmm, and looking at that, I'm suddenly hungry again

Context is everything. BAS is correct that pretty well most of the time you could say "toaster" and it would be reasonable to assume that everyone is thinking about something that runs off lecky. But, if the discussion were in the context of cooking while camping then that would not be a reasonable assumption - since when camping it is more likely to be a non-electrical toaster. You would need to be especially careful in a thread that (say) started talking about cooking al-fresco but has drifted to (say) cooking in a caravan. Then there is now scope for confusion as one group are still thinking "al-fresco, no lecky" while others are now thinking "lecky" - and accuse others of being obtuse for picking them up on a term that was ambiguous in the context it was used and leaving statements made incorrect for some valid interpretations of what was said.

Likewise, when using terms like "virtualisation" then context is important. IF the context is clearly one where only full virtualisation, with shared backend storage, and all the management tools to support live migration etc - then, and only then, would it be reasonable to assume that "virtualisation" didn't mean anything other than that.
There was no such context here, so virtualisation could quite reasonably be considered to be anything from that at the top end, down to the most basic (no shared storage, no management tools, etc) at the lower end.
A big difference is that with the term "toaster", the contexts where an assumption of electric isn't valid are fairly narrow in scope. That's very much not the case with a term like "virtualisation".

 

[ban-all-sheds]

IF the context is clearly one where only full virtualisation, with shared backend storage, and all the management tools to support live migration etc ....
There was no such context here

Asking people to log off to be able to test is common and with servers finding windows to do work again common. But switching off is still a problem.

So virtualise them all, then you can move the VMs and empty the physical server.

 

[SimonH2]

OK BAS, please highlight where it's really clear and unambiguous that the only reasonable interpretation of that bit you've just quoted cannot possibly mean anything other than "the full monty" virtualisation.

Please explain, in the context of the thread, why virtualisation cannot be reasonably interpreted to mean "low end" stuff without all the shared storage and management etc. It will be interesting to see how you twist that one around. Note - in the context of the thread, there's no context that says that only "big installations" are being discussed.

As I've already said :
IF the context was such that the full monty was an obvious interpretation to make, then you'd be correct. It wasn't, and you aren't.
IF you'd qualified that statement along the lines of "So virtualise them all, then you can move the VMs and empty the physical server - if you have an infrastructure that supports that" you'd be correct. But you didn't, and you aren't.

Given that you made an inaccurate statement then it's only logical that someone point that out. It was such a bold and unfounded statement to make, that it really did look like a lot of those spouted out by politicians who really haven't a clue what they are talking about.

 

[ban-all-sheds]

OK BAS, please highlight where it's really clear and unambiguous that the only reasonable interpretation of that bit you've just quoted cannot possibly mean anything other than "the full monty" virtualisation.

Could you accomplish what I suggested, i.e. proactive migration of live VMs without "the full monty"?

If no, then why did you choose to ignore the only reasonable interpretation and start assuming that I didn't know what I was talking about?

Please explain, in the context of the thread, why virtualisation cannot be reasonably interpreted to mean "low end" stuff without all the shared storage and management etc.

Oh - let's see.

Tell you what - how about the fact that I replied to a particular post, and didn't make a general comment about the topic as a whole?

This is the only context of the thread I can determine:

Overheard the helldesk guys the other day. One of our customers had some one in testing the appliances, and in the corner of one office is a backup server (which looks rather like a PC).
It disappeared off the network when it had it's power cord yanked to do the testing....

and I was not responding to that. I was not suggesting any form of virtualisation as being of value in that situation. (Although it can be.)


What I was responding to was Eric's post about switching off servers being a problem.

The clue there is in the fact that I quoted Eric's post.

It will be interesting to see how you twist that one around. Note - in the context of the thread, there's no context that says that only "big installations" are being discussed.

There's no context that says only small ones are being discussed either.

Not that that's relevant, given that I was only replying to Eric's post.

As I've already said :
IF the context was such that the full monty was an obvious interpretation to make, then you'd be correct. It wasn't, and you aren't.

I see.

It seems to me that what you are saying there is that given a suggestion to use live VM migration as a proactive measure to avoid the problems associated with shutting down a server with users on it, it is not obvious to assume that you would have to have a "full monty" virtualisation environment in order for that to work.

Is that right?

If not, then what do you mean? Why, in the context of such a suggestion is an interpretation that you'd have an environment to make the suggestion work not an obvious one?

IF you'd qualified that statement along the lines of "So virtualise them all, then you can move the VMs and empty the physical server - if you have an infrastructure that supports that" you'd be correct. But you didn't, and you aren't.

No, I didn't, because it would be more than a tad perverse to suggest a solution to a problem assuming that it would be implemented in a way which did not work.

It was not my statement which was wrong, it was your decision to draw an incorrect inference which was at best stupid and at worst maliciously offensive that was wrong.

 

[SimonH2]

Could you accomplish what I suggested, i.e. proactive migration of live VMs without "the full monty"?

If no, then why did you choose to ignore the only reasonable interpretation and start assuming that I didn't know what I was talking about?

Which encapsulates the entire "discussion".

You are incapable of seeing just how absurd your statements are. If "the full monty" version was by far the most common installation, such that it was as ubiquitous as toasters being electric, then and only then would your argument be valid. Since that is not the case, by a long way, then your argument is bogus.

Since you appear incapable of accepting that, then it does call into question whether you really do have a clue what you are talking about.

 

[ban-all-sheds]

Which encapsulates the entire "discussion".

The bit about your faulty assumptions certainly does.

You are incapable of seeing just how absurd your statements are.

You are incapable of seeing how absurd your statements are.

If "the full monty" version was by far the most common installation, such that it was as ubiquitous as toasters being electric, then and only then would your argument be valid.

Simple question.

Never mind the ifs, buts and maybes about skills, hardware costs, software costs, infrastructure designs, choice of virtualisation technology etc:

Can it be possible, in a virtualised environment, to proactively move live VMs from one server to another so that the original server can be taken down without having to shut down the services running on it?

Yes or no?