Re: HAL type for Win2003 Server on recent KVM versions?

[Cole Robinson <crobinso@redhat.com>]

On 11/18/2010 09:05 AM, Kenni Lund wrote:
> 2010/11/18 Avi Kivity <avi@redhat.com>:
>> On 11/18/2010 12:58 AM, Kenni Lund wrote:
>>>
>>> Hi
>>>
>>> I'm about to move a couple of virtual machines from a Fedora 11 system
>>> to a new server with a more recent operating system and newer version
>>> of KVM, etc.
>>>
>>> One of the guests is a Windows Server 2003 Standard SP2, which is
>>> currently running with the "ACPI Multiprocessor PC" HAL.
>>>
>>> Considering moving to RHEL, I've been reading the virtualization
>>> documentation for RHEL 6.0, which says that I need to set HAL to
>>> "Standard PC" when installing a new Win2003 guest.
>>>
>>> Since my current guest has been running perfectly fine for a long time
>>> with its current HAL, I was wondering if the system will become
>>> unstable, unbootable or what the disadvantage will be, if I move the
>>> guest to for example RHEL 6.0, without reinstalling or upgrading the
>>> guest to select another HAL mode?
>>>
>>> On the other hand, it seems like I can "upgrade" from the current
>>> "ACPI Multiprocessor PC" into "Standard PC", but I'm not sure if I'll
>>> gain anything by trying this.
>>>
>>
>> I suggest using the default HAL, whatever it is.  That's what everyone else
>> is using so you get the best tested configuration.
> 
> Thanks Avi, "ACPI Multiprocessor PC" was/is the default HAL, I didn't
> change anything when the system was originally installed.
> 
> I'm curious why the RHEL 6 documentation claims that you actively need
> to select the "Standard PC" HAL on installation, if it's not even the
> recommended/preferred HAL...(?):
> "Windows 2003 requires a specific computer type in order to install
> properly on a fully-virtualized guest. This needs to be specified at
> the beginning of the installation process."[1]
> 
> [1] http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization/sect-Virtualization_Windows2003.html
> 

I'm pretty sure that was incorrectly copied over from the RHEL5 xen
documentation. The docs people have been informed so it should be fixed
soon-ish.

- Cole