>>> On 2010/01/03 at 08:21, richard heade <
richard.heade@xxxxxxxxx> wrote:
> okay, figuring that maybe the problem was with the physical partition I
> built another vm to a "file:", with the following configuration:
> name="winxp2"
> uuid="86764f24-88ae-a66e-44c4-45c10714efed"
> memory=512
> maxmem=1024
> vcpus=1
> >
> >
> >
> localtime=1
> keymap="en-us"
>
> builder="hvm"
> extid=0
> device_model="/usr/lib/xen/bin/qemu-dm"
> kernel="/usr/lib/xen/boot/hvmloader"
> boot="c"
> disk=[ 'file:/var/lib/xen/images/winxp2/disk0,hda,w',
> 'phy:/dev/sr0,hdc:cdrom,r', ]
> vif=[ 'bridge=br0,model=rtl8139', ]
>
> stdvga=0
> vnc=1
> vncunused=1
> apic=1
> acpi=1
> pae=1
>
> usb=1
> usbdevice='tablet'
>
> serial="pty"
>
> Same experience as before, the "create" went okay, the vm console/window
> opened, it brought up the XP install disk, it did the XP install, but when
> it came time to reboot and finish the installation I got "NTLDR is
> missing". If I do a "direct" (non-Xen) XP install, it boots okay, and when
> I had it set up for a dual-boot it boots okay. What is the Xen XP
> installation missing? Is there an extra step, that everyone forgot to
> mention, where you install NTLDR or some alternate boot loader (like grub)
> to boot XP?
>
>
> On Sat, Jan 2, 2010 at 8:38 AM, richard heade <
richard.heade@xxxxxxxxx>wrote:
>
>> okay, I accept that I'm not going to be able to use the same "image" for
>> Xen, and to boot directly. I've rebuilt my system, so that it now only
>> boots to linux or Xen. The disk is partitioned somewhat similarly:
>> /dev/sda1 - windows xp
>> /dev/sda2 - extended
>> /dev/sda5 - /
>> /dev/sda6 - swap
>> /dev/sda7 - home
>>
>> I created a new XP vm, winxp, with the following configuration, using Yast:
>> name="winxp"
>> uuid="4c1c1e3d-dc7f-4c62-2467-688c64d77394"
>> memory=512
>> maxmem=1024
>>
>> vcpus=2
>> >
>> >
>> >
>> localtime=1
>> keymap="en-us"
>>
>> builder="hvm"
>> extid=0
>> device_model="/usr/lib/xen/bin/qemu-dm"
>> kernel="/usr/lib/xen/boot/hvmloader"
>> boot="cd"
>> disk=[ 'phy:/dev/sda1,hda,w', 'phy:/dev/sr0,hdc:cdrom,r', ]
>>
>> vif=[ 'bridge=br0,model=rtl8139', ]
>>
>> stdvga=0
>> vnc=1
>> vncunused=1
>> apic=1
>> acpi=1
>> pae=1
>>
>> usb=1
>> usbdevice='tablet'
>>
>> serial="pty"
>>
>> the "create" went okay, the vm console/window opened, it brought up the XP
>> install disk, and it did the XP install to /dev/sda1 (the files are there),
>> but when it came time to reboot and finish the installation I got "NTLDR is
>> missing". Is this because I went with a physical partition ("phy:") instead
>> of an image ("file:")? And how do I get this to work?
>>
>>
>>
>>
>> On Sun, Dec 27, 2009 at 7:20 PM, Nick Couchman <
Nick.Couchman@xxxxxxxxx>wrote:
>>
>>> The point of full virtualization is that there are certain operating
>>> systems that cannot run as paravirtualized VMs. Windows, for example, must
>>> run in a full virtualization environment - Microsoft has not provided (and
>>> is not likely to provide) a paravirtual kernel for Windows. Windows Server
>>> 2008 has an "enlightened" mode that switches drivers from full emulation to
>>> paravirtual mode when it detects a hypervisor like VMware or Xen; however,
>>> even this "enlightened" version of Windows still requires a full virtual
>>> machine.
>>>
>>> -Nick
>>>
>>> >>> On 2009/12/27 at 19:34, richard heade <
richard.heade@xxxxxxxxx>
>>> wrote:
>>> > thanks for the response, but it leaves me wondering what's the point of
>>> > full virtualization. I can install the tweaked OS for
>>> > paravirtualization, or I can tweak the hardware configuration for an
>>> > already installed OS for full virtualization. Either way I can't go
>>> > back to the original OS when I, as occasionally happens, get my linux
>>> > system hosed up.
>>> >
>>> >
>>> > Nick Couchman wrote:
>>> >> The challenge in this sort of setup is that the hardware configuration
>>> that
>>> > Windows was installed onto and the hardware configuration that Xen
>>> presents
>>> > to HVM-based domUs is different - in some cases very different. For
>>> example,
>>> > if you're running modern hardware, you probably have a SATA disk, which
>>> is
>>> > usually seen by O/Ss as a SCSI-type controller with SCSI disks.
>>> However, HVM
>>> > domUs use IDE-based controllers and disks, which means booting is going
>>> to
>>> > have issues seeing the change. There are also differences in the
>>> chipset,
>>> > network controllers, etc., that need to be seen correctly by Windows
>>> before
>>> > it boots.
>>> >>
>>> >> One of the basic things is to try converting the SCSI-based disk setup
>>> to IDE
>>> > - there are instructions on Microsoft's support site for doing this.
>>> The
>>> > downside to this is that you probably won't be able to boot Windows back
>>> on
>>> > the original hardware outside of the VM after this change - Windows is
>>> not
>>> > very flexible in terms of differing hardware configurations outside of
>>> your
>>> > basic docked and undocked laptop modes.
>>> >>
>>> >> Note that this also may pose licensing issues - usually machines that
>>> come
>>> > with Windows are installed using an OEM license, which licenses Windows
>>> to
>>> > run on the original hardware only. Using this same copy of Windows to
>>> run in
>>> > a domU is likely a violation of the OEM license - you need another, full
>>> > retail or volume license for Windows to run as a VM.
>>> >>
>>> >> -Nick
>>> >>
>>> >>
>>> >>>>> On 2009/12/27 at 07:52, richard heade <
richard.heade@xxxxxxxxx>
>>> wrote:
>>> >>>>>
>>> >>> I have a dual-boot setup, using grub, that I'm attempting to convert
>>> to
>>> >>> a dual-boot plus xen setup. I'm running openSuSE 11.2 with the
>>> >>> 2.6.31.5-0.1-xen kernel and Xen 3.4.1. The hard drive is partitioned
>>> as:
>>> >>> sda1 - xp (ntfs)
>>> >>> sda2 - extended partition
>>> >>> sda5 - /windows/D (fat32)
>>> >>> sda6 - swap
>>> >>> sda7 - / (ext4)
>>> >>> sda8 - /home (ext4)
>>> >>>
>>> >>> I've configured the windows xp vm as:
>>> >>> name="windowsxp"
>>> >>> uuid="b3a2c424-7df7-94f6-79a8-c641e412f68d"
>>> >>> memory=512
>>> >>> maxmem=512
>>> >>> vcpus=2
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> localtime=1
>>> >>> keymap="en-us"
>>> >>>
>>> >>> builder="hvm"
>>> >>> extid=0
>>> >>> device_model="/usr/lib/xen/bin/qemu-dm"
>>> >>> kernel="/usr/lib/xen/boot/hvmloader"
>>> >>> boot="c"
>>> >>> disk=[ 'phy:/dev/sda1,hda1,w', ]
>>> >>> vif=[ 'bridge=br0,model=rtl8139', ]
>>> >>>
>>> >>> stdvga=0
>>> >>> vnc=1
>>> >>> vncunused=1
>>> >>> apic=1
>>> >>> acpi=1
>>> >>> pae=1
>>> >>>
>>> >>> usb=1
>>> >>> usbdevice='tablet'
>>> >>>
>>> >>> serial="pty"
>>> >>>
>>> >>> When I attempt to run the windows xp vm the console shows "booting
>>> from
>>> >>> hard disk...", the cpu usage goes to 100%, and that's as far as it
>>> gets.
>>> >>> (I've tried multiple different "disk=..." combinations, this is just
>>> the
>>> >>> latest, but I get the same results from all of them.)
>>> >>>
>>> >>> Any ideas on how I might fix this? (it would seem that however xen
>>> tries
>>> >>> to boot windows xp, it's not as effective as grub's chainloader.)
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --------
>>> >> This e-mail may contain confidential and privileged material for the
>>> sole use
>>> > of the intended recipient. If this email is not intended for you, or
>>> you are
>>> > not responsible for the delivery of this message to the intended
>>> recipient,
>>> > please note that this message may contain SEAKR Engineering (SEAKR)
>>> > Privileged/Proprietary Information. In such a case, you are strictly
>>> > prohibited from downloading, photocopying, distributing or otherwise
>>> using
>>> > this message, its contents or attachments in any way. If you have
>>> received
>>> > this message in error, please notify us immediately by replying to this
>>> e-mail
>>> > and delete the message from your mailbox. Information contained in this
>>> > message that does not relate to the business of SEAKR is neither
>>> endorsed by
>>> > nor attributable to SEAKR.
>>> >>
>>> >>
>>>
>>>
>>> --------
>>> This e-mail may contain confidential and privileged material for the sole
>>> use of the intended recipient. If this email is not intended for you, or
>>> you are not responsible for the delivery of this message to the intended
>>> recipient, please note that this message may contain SEAKR Engineering
>>> (SEAKR) Privileged/Proprietary Information. In such a case, you are
>>> strictly prohibited from downloading, photocopying, distributing or
>>> otherwise using this message, its contents or attachments in any way. If
>>> you have received this message in error, please notify us immediately by
>>> replying to this e-mail and delete the message from your mailbox.
>>> Information contained in this message that does not relate to the business
>>> of SEAKR is neither endorsed by nor attributable to SEAKR.
>>>
>>
>>
--------
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Home