On 11/18/2010 09:05 AM, Kenni Lund wrote: > 2010/11/18 Avi Kivity <avi@xxxxxxxxxx>: >> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
