Virtualization - Apr 2007 - Use case on "Hotplug for Virtualization"

The latest draft of the Use Case on Hotplug for Virtualization is posted
at:
http://www.developer.osdl.org/maryedie/HOTPLUG/docs/Hotplug_virtual_use_
case.txt

It can also be accessed from the hotplug use cases page:
http://developer.osdl.org/dev/usecases/hotplug.shtml

Please remember to share your comments/errata/suggestions.

Thanks - Martine

On Mon, Aug 29, 2005 at 02:47:18PM -0400, Silbermann, Martine
wrote:
> 
> 
> The latest draft of the Use Case on Hotplug for Virtualization is posted
> at:
> http://www.developer.osdl.org/maryedie/HOTPLUG/docs/Hotplug_virtual_use_
> case.txt
> 
> It can also be accessed from the hotplug use cases page:
> http://developer.osdl.org/dev/usecases/hotplug.shtml
> 
> Please remember to share your comments/errata/suggestions.
I've read through it; it looks good.  I thought it addressed the first
goal (the role of hotplug in virtualization) quite well.  The second
goal (identify requirements to support various hotplug operations) seems
to be addressed ok by the workflow section, although maybe the specific
requirements could be identified a little more explicitly.

Bryce

Silbermann, Martine wrote:
>The latest draft of the Use Case on Hotplug for Virtualization is posted
>at:
>http://www.developer.osdl.org/maryedie/HOTPLUG/docs/Hotplug_virtual_use_
>case.txt
>
>It can also be accessed from the hotplug use cases page:
>http://developer.osdl.org/dev/usecases/hotplug.shtml
>
>Please remember to share your comments/errata/suggestions.
>
>Thanks - Martine
>
>  
>
>-------------------------
>1.Serviceability (hotplug at physical layer)
>-------------------------
>In this sub-case the System Administrator needs the ability to 
>remove/replace failing components. 
>Unfortunately, CPU failures  tend to be fatal and usually don't give 
>any warning. Fortunately, they're also very infrequent. Because they
>are usually fatal, it's likely that you won't be looking at a 
>hot-remove scenario.(Though, if you have a processor failure and 
>remove it while the system is down, the System Administrator needs 
>the option to reboot immediately and hot-add the replacement). In 
>contrast, memory and I/O often give adequate warning, via single-bit 
>or parity errors, that they're failing; thus providing an opportunity 
>to have them replaced before they cause a system failure.

I'm not sure I totally agree with this.  I like the capacity, migration, 
and virtualization motivations a lot.  First, CPU failures are not 
always fatal; in a NUMA, blade or block systems, CPU failures could 
potentially be tolerated for single nodes without disrupting the entire 
system.  Second, I'm not 100% convinced that memory failures are any 
more predictable based on parity errors than CPU failures - it could 
simply be solar radiation.  I'm also less convinced that memory is more 
easily replaced in a hotplug fashion than CPUs - you have similar 
migration issues, plus a lot of nasty global TLB issues (not to mention 
electrical problems!).  I confess to be not thoroughly studied on very 
recent systems in these respects.  Nevertheless, your point is valid; I 
simply think it could use more convincing arguments.

That said, I think everyone on these lists probably agrees with the 
usage cases. :)

Zach

On Mon, 29 Aug 2005, Silbermann, Martine wrote:
> The latest draft of the Use Case on Hotplug for Virtualization is posted
> at:
>
http://www.developer.osdl.org/maryedie/HOTPLUG/docs/Hotplug_virtual_use_case.txt
Ugh.

Does this mean developers should stop using this list?

-- 
All Rights Reversed