Xen users - Jun 2007 - XEN and Windows Guests in critical environment (hospital)

Hi all,

One friend of mine are thinking about how to implement virtualization in 
their critical job environment (a hospital).
The main "problem" is there are a lot of medical application builded
in
.NET tecnology; so, I view three possible options:

1.  Win server with VMware and win guests (IIS to support .NET).
2.  UNIX/Linux server with XEN (or XenEnterprise) and win guests
3.  UNIX/Linux server with XEN (or XenEnterprise) and UNIX/Linux guests 
(Apache with mod_mono to support .NET)

I think the next about each one option:

1. The current preference because stability and windows compatibility.
2. My personal preference, but I''m not sure about the performance of
win
guests on XEN Unix based system.
3. The "ideal" economical solution, but probably the more insecure in 
terms of stability.

Let me to repeat: it''s a CRITICAL environment and will be not any 
error-edge.

Any argued reasoning will be welcomed.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> Hi all,
> 
> One friend of mine are thinking about how to implement virtualization
in
> their critical job environment (a hospital).
> The main "problem" is there are a lot of medical application
builded
in
> .NET tecnology; so, I view three possible options:
> 
> 1.  Win server with VMware and win guests (IIS to support .NET).
> 2.  UNIX/Linux server with XEN (or XenEnterprise) and win guests
> 3.  UNIX/Linux server with XEN (or XenEnterprise) and UNIX/Linux
guests
> (Apache with mod_mono to support .NET)
> 
> I think the next about each one option:
> 
> 1. The current preference because stability and windows compatibility.
> 2. My personal preference, but I''m not sure about the performance
of
win
> guests on XEN Unix based system.
> 3. The "ideal" economical solution, but probably the more
insecure in
> terms of stability.
> 
> Let me to repeat: it''s a CRITICAL environment and will be not any
> error-edge.
> 
> Any argued reasoning will be welcomed.
In theory, all of the above options you mentioned add a layer of
complexity to the problem and therefore potentially reduce reliability.

I''m guessing, but there is a good chance that the critical applications
you speak of have been designed and tested in an un-virtualised
environment running on a Microsoft operating system. (I''d question
running critical applications in a Microsoft environment at all, but
that''s another argument :)

By taking the applications out of the environment they have been
designed and tested in, you are almost certainly moving into an
environment that the company that designed the software can''t or
won''t
support.

What if you have a problem? Who are you going to call? You need someone
that can drop everything they are doing and work on the problem. If you
are running VMWare+Windows+.NET or Xen+Windows+.NET, and an application
starts crashing, what do you do? The problem could be related to the
hardware, related to the virtualisation layer (VMWare/Xen), related to
windows, related to .NET, related to the actual application, or some
combination of all of them. Your support agent needs to be able to work
on the problem as a whole... I find it hard enough diagnosing obscure
problems when virtualisation isn''t involved, and the last thing you
want
is one of the vendors throwing their hands in the air and saying
''Xen/VMWare''??? We don''t support that!!!

My argument therefore is that if these applications are as critical as
you say they are, give them exactly the environment they were designed
for, or at least get the approval of the software developers and testers
before you do anything. In fact I would have thought that critical
applications like this would be supplied essentially as a ''black
box''
solution, and if anything goes wrong the supplier deals with it...

James


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Sat, Jun 23, 2007 at 10:15:25PM +1000, James Harper
wrote:
> problems when virtualisation isn''t involved, and the last thing
you want
> is one of the vendors throwing their hands in the air and saying
> ''Xen/VMWare''??? We don''t support that!!!
> 
 Why would you want to tell the application software folks that you are running
it inside Xen? How can they even find out? Just let them login to the windows
machine like they normally do, and even if they are experts on virtualization, I
don''t think there is an easy way to determine that. Even the windows os
itself has no idea it is running in a virtualized environment. In fact,
that''s the entire point of virtualization--virtualize nothing or at the
most, the kernel, and the apps all work transparently, since otherwise the
entire thing becomes pointless.

 As for virtualization itself, you need to check the stability of Xen itself,
which has only been tagged stable recently. Virtualization makes it easier to
manage, and overall I would say increases the reliability, simply on account of
being easier to keep track of, and also take backups, migrate in case of
hardware failure etc.

 

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Ligesh wrote:
> On Sat, Jun 23, 2007 at 10:15:25PM +1000, James Harper wrote:
>   
>> problems when virtualisation isn''t involved, and the last
thing you want
>> is one of the vendors throwing their hands in the air and saying
>> ''Xen/VMWare''??? We don''t support that!!!
>>
>>     
>
>  Why would you want to tell the application software folks that you are
running it inside Xen? How can they even find out? Just let them login to the
windows machine like they normally do, and even if they are experts on
virtualization, I don''t think there is an easy way to determine that.
Even the windows os itself has no idea it is running in a virtualized
environment. In fact, that''s the entire point of
virtualization--virtualize nothing or at the most, the kernel, and the apps all
work transparently, since otherwise the entire thing becomes pointless.
>
>  As for virtualization itself, you need to check the stability of Xen
itself, which has only been tagged stable recently. Virtualization makes it
easier to manage, and overall I would say increases the reliability, simply on
account of being easier to keep track of, and also take backups, migrate in case
of hardware failure etc.
>   
Well, sending them a "sysreport" output might be a good hint, because
it
will name the Xen kernel. In fact, why would you want to lie about it? 
Not telling a vendor your actual setup is begging for them to suffer.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Sat, Jun 23, 2007 at 06:36:53PM +0100, Nico Kadel-Garcia
wrote:
> Ligesh wrote:
> > As for virtualization itself, you need to check the stability of Xen 
> > itself, which has only been tagged stable recently. Virtualization
makes
> > it easier to manage, and overall I would say increases the
reliability,
> > simply on account of being easier to keep track of, and also take 
> > backups, migrate in case of hardware failure etc.
> >  
> Well, sending them a "sysreport" output might be a good hint,
because it
> will name the Xen kernel. In fact, why would you want to lie about it? 
> Not telling a vendor your actual setup is begging for them to suffer.
> 
 NO you need not. Do you tell your application vendor what CPU you are running
on? Or what motherboard you are using? Xen is transparent. That''s the
whole point; otherwise I don''t think it is useful. Xen should be
treated as yet another hardware, and I don''t think it is necessary to
tell anyone about it, unless of course, you are running a software that
explicitly deals with hardware, in which situation you should probably not run
Xen, unless you know what you are doing.

 For the app vendor, it is irrelevant if you are running it inside xen or on
baremetal. Even for windows it doesn''t matter, so for something that
sits so high up in the application chain, why would you want to complicate and
confuse the easily confused people by bringing in information about a software
about which they probably haven''t heard about?





_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Ligesh wrote:
> On Sat, Jun 23, 2007 at 06:36:53PM +0100, Nico Kadel-Garcia wrote:
>   
>> Ligesh wrote:
>>     
>>> As for virtualization itself, you need to check the stability of
Xen
>>> itself, which has only been tagged stable recently. Virtualization
makes
>>> it easier to manage, and overall I would say increases the
reliability,
>>> simply on account of being easier to keep track of, and also take 
>>> backups, migrate in case of hardware failure etc.
>>>  
>>>       
>> Well, sending them a "sysreport" output might be a good hint,
because it
>> will name the Xen kernel. In fact, why would you want to lie about it? 
>> Not telling a vendor your actual setup is begging for them to suffer.
>>
>>     
>
>  NO you need not. Do you tell your application vendor what CPU you are
running on? Or what motherboard you are using? Xen is transparent.
That''s the whole point; otherwise I don''t think it is useful.
Xen should be treated as yet another hardware, and I don''t think it is
necessary to tell anyone about it, unless of course, you are running a software
that explicitly deals with hardware, in which situation you should probably not
run Xen, unless you know what you are doing.
>   
If I expect their useful help for deeply system integrated tools like 
Oracle, or graphics device drivers, or even kernel related functionality 
like Wacom graphics tablets and the requisite kernel module, you''re 
damned right I tell them. It''s relevant, and I''ve in fact
helped debug
hardware related issues with all of those professionally.
>  For the app vendor, it is irrelevant if you are running it inside xen or
on baremetal. Even for windows it doesn''t matter, so for something that
sits so high up in the application chain, why would you want to complicate and
confuse the easily confused people by bringing in information about a software
about which they probably haven''t heard about
>   
Nonesense. I''ve *been* the vendor, and it makes a big difference what 
kernel you''re using. Lying to them just confuses the issues, and
I''ve
run into *that*, too.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Sat, Jun 23, 2007 at 10:44:15PM +0100, Nico Kadel-Garcia
wrote:
> Ligesh wrote:
> 
> > For the app vendor, it is irrelevant if you are running it inside xen
or
> > on baremetal. Even for windows it doesn''t matter, so for
something that
> > sits so high up in the application chain, why would you want to 
> > complicate and confuse the easily confused people by bringing in 
> > information about a software about which they probably
haven''t heard about
> >  
> Nonesense. I''ve *been* the vendor, and it makes a big difference
what
> kernel you''re using. Lying to them just confuses the issues, and
I''ve
> run into *that*, too.
> 
 We are talking about application written in dotnet. That''s pretty much
3 layers above the kernel. I had very clearly stated that if you are running
kernel level apps, then it is better you stick with real hardware, or even if
you are migrating, you get the proper experts to do it.

 We are talking about pure user-level applications, like the one in the Original
Post--a dotnet medical app --which would mostly be dealing with accounting and
database. So obviously, it has nothing to do with Xen or the hardware. If you
are running apps that has device drivers, then the situation is completely
different, but that''s obvious.



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Ligesh wrote:
> On Sat, Jun 23, 2007 at 10:44:15PM +0100, Nico Kadel-Garcia wrote:
>   
>> Ligesh wrote:
>>
>>     
>>> For the app vendor, it is irrelevant if you are running it inside
xen or
>>> on baremetal. Even for windows it doesn''t matter, so for
something that
>>> sits so high up in the application chain, why would you want to 
>>> complicate and confuse the easily confused people by bringing in 
>>> information about a software about which they probably
haven''t heard about
>>>  
>>>       
>> Nonesense. I''ve *been* the vendor, and it makes a big
difference what
>> kernel you''re using. Lying to them just confuses the issues,
and I''ve
>> run into *that*, too.
>>
>>     
>
>  We are talking about application written in dotnet. That''s pretty
much 3 layers above the kernel. I had very clearly stated that if you are
running kernel level apps, then it is better you stick with real hardware, or
even if you are migrating, you get the proper experts to do it.
>   
Fair enough. but you''d be *amazed* at some of the fun and games that 
user-level applications do that are seriously affected by kernel 
subtleties. Proxy cache performance, for instance, is massively affected 
by subtleties of the "select" function.
>  We are talking about pure user-level applications, like the one in the
Original Post--a dotnet medical app --which would mostly be dealing with
accounting and database. So obviously, it has nothing to do with Xen or the
hardware. If you are running apps that has device drivers, then the situation is
completely different, but that''s obvious.
>   
OK, be clear about that then. I still think it''s a bad idea to hide
your
full configuration from your vendor. The conflicts can really surprise 
you at odd moments, and I''ve seen them happen.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Sun, Jun 24, 2007 at 02:01:25AM +0100, Nico Kadel-Garcia
wrote:
> Ligesh wrote:
> OK, be clear about that then. I still think it''s a bad idea to
hide your
> full configuration from your vendor. The conflicts can really surprise 
> you at odd moments, and I''ve seen them happen.
> 
 You are talking about practical situations. I am as usual talking about theory.
:-) Theoretically, xen shouldn''t enter the picture, but I can see in
practice, it might be necessary.



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> On Sat, Jun 23, 2007 at 10:44:15PM +0100, Nico Kadel-Garcia wrote:
> > Ligesh wrote:
> >
> > > For the app vendor, it is irrelevant if you are running it inside
xen
> or
> > > on baremetal. Even for windows it doesn''t matter, so for
something
> that
> > > sits so high up in the application chain, why would you want to
> > > complicate and confuse the easily confused people by bringing in
> > > information about a software about which they probably
haven''t
heard
> about
> > >
> > Nonesense. I''ve *been* the vendor, and it makes a big
difference
what
> > kernel you''re using. Lying to them just confuses the issues,
and
I''ve
> > run into *that*, too.
> 
>  We are talking about application written in dotnet. That''s pretty
much 3
> layers above the kernel. I had very clearly stated that if you are
running
> kernel level apps, then it is better you stick with real hardware, or
even
> if you are migrating, you get the proper experts to do it.
> 
>  We are talking about pure user-level applications, like the one in
the
> Original Post--a dotnet medical app --which would mostly be dealing
with
> accounting and database. So obviously, it has nothing to do with Xen
or
> the hardware. If you are running apps that has device drivers, then
the
> situation is completely different, but that''s obvious.
What you are saying is probably correct, assuming as you say that the
applications in question are not data acquisition processes or anything
requiring low level drivers. But the point you aren''t getting is about
support, and what happens when something goes wrong. 

I made the assumption that the word ''critical'' used in the
original post
meant that lives could depend on it, eg if the application in question
is responsible for scheduling medical test and sending results to the
right person. In my experience the platform for ''critical''
applications
like this is that they are sized and specified very tightly by the
vendor, and if you have ever been in the role of support for such a
thing you''ll understand why.

So I agree with you that the application will almost certainly work and
work perfectly, but everyone is very sensitive about legal
responsibilities these days, and if someone died and it was determined
that a computer failure caused the results of a medical test to be lost
or delayed and that that was a contributing factor to their death, and
it turns out that you used an unsupported system configuration to run
the software on, then take a guess what happens next - the fact that it
wasn''t Xen or VMWare''s fault will have nothing to do with the
outcome of
the inquiry...

James


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

James Harper wrote:
>
> So I agree with you that the application will almost certainly work and
> work perfectly, but everyone is very sensitive about legal
> responsibilities these days, and if someone died and it was determined
> that a computer failure caused the results of a medical test to be lost
> or delayed and that that was a contributing factor to their death, and
> it turns out that you used an unsupported system configuration to run
> the software on, then take a guess what happens next - the fact that it
> wasn''t Xen or VMWare''s fault will have nothing to do with
the outcome of
> the inquiry...
>   
Heh. Yeah, been there. I used to design medical electronics for neural 
implants. All the designs had to be very belt-and-suspenders, and there 
was often a trade-off between keeping things the way they were, and 
keeping things supported or robust against the next potential threat. 
Since one of my first systems adminstration tasks was cleaning up after 
the Morris Worm, partly because I had specifically been forbidden from 
implementing the available system security patches to avoid any 
complicatons in a BSD 4.3 controlled neural stimulator, I got to see the 
booby traps of local configuration issues up close and personal.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Jordi Espasa Clofent wrote:
> Hi all,
> 
> One friend of mine are thinking about how to implement virtualization in 
> their critical job environment (a hospital).
> The main "problem" is there are a lot of medical application
builded in
> .NET tecnology; so, I view three possible options:
> 
> 1.  Win server with VMware and win guests (IIS to support .NET).
> 2.  UNIX/Linux server with XEN (or XenEnterprise) and win guests
> 3.  UNIX/Linux server with XEN (or XenEnterprise) and UNIX/Linux guests 
> (Apache with mod_mono to support .NET)
> 
...

I don''t think virtualisation is necessarily going to help reliability 
although it may help in other ways.

If money wasn''t an issue I would go for a redundant/mirrored iSCSI SAN 
with regular snapshots and remote backups and have bare metal Windows 
servers with HBAs booting off the SAN.  Spare servers could be 
configured to take over a non-functioning one very quickly.  You could 
still use virtualisation but you would need to couple it with something 
like heartbeat to make it more reliable than the bare metal servers.

I would imagine if these applications are critical then the applications 
themselves should be written and be able to run in a redundant fashion 
anyway, otherwise the software is not really fit for purpose.

You need to decide what amount of down time is acceptable.  1 second, 1 
minute, 1 hour. 1 day etc..  Each has a technical solution, tending to 
be more expensive the more reliable it is.

Simon

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users