Description of problem: python-virtinst version: python-virtinst-0.400.3-1.el5 xen version : xen-3.0.3-86.el5 libvirt version : libvirt-0.6.3-3.el5 virt-manager version : virt-manager-0.6.1-1.el5 system : Red Hat Enterprise Linux Server release 5.4 Beta (Tikanga) kernel info : Linux 2.6.18-151.el5xen #1 SMP Wed May 27 16:33:19 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Steps to Reproduce: 1. download minix vmware virtual machine from http://www.minix3.org/download/minix3_1_2a_vmware.zip 2. unzip minix3_1_2a_vmware.zip 3. cd minix 4. virt-convert -i vmx -o virt-image MS-DOS.vmx 5. cd minix 6. virt-image --name minix minix.virt-image.xml 7. use virt-manager to watch the guest status Actual results: the guest was started normally, we can see minix 3. Expected results: blocked at booting screen, always there, see attachment. Additional info: have installed VMware Workstation 6.5.1 build-126130 on RHEL5.4 Beta (Tikanga), and tried to open the minix, the result is that it can be started successfully. And I also created a new RHEL5.3-Server virtual machine using VMware Workstation. then use it as the test source, found it can be started normally.
Created attachment 348631 [details] blocked at booting screen picture.
Can you provide the 'MS-DOS.vmx' file from the appliance, the generated minix.virt-image.xml file and the output from 'virsh dumpxml minix' so we can see the final libvirt XML
Created attachment 348636 [details] dumped libvirt xml of minix 3.
Created attachment 348637 [details] minix virt-image xml
Created attachment 348638 [details] MS-DOS.vmx
I'd say there is a non-trivial chance that the pre-installed VMWare image for Minix simply won't automatically adapt to cope with the Xen virtual hardware model. Then again, perhaps Xen won't rnu Minix at all. I think it'd be worth testing the bootable ISO install image of Minix first to make sure Minix itself does work in Xen, before trying to further troubleshoot the VMware image usage, eg try the IDE ISO from here http://www.minix3.org/download/
(In reply to comment #6) > I'd say there is a non-trivial chance that the pre-installed VMWare image for > Minix simply won't automatically adapt to cope with the Xen virtual hardware > model. Then again, perhaps Xen won't rnu Minix at all. > > I think it'd be worth testing the bootable ISO install image of Minix first to > make sure Minix itself does work in Xen, before trying to further troubleshoot > the VMware image usage, eg try the IDE ISO from here > > http://www.minix3.org/download/ Yeah, totally agreed. I doubt anyone has ever tried Minix on RHEL-5 Xen before, so it's certainly possible that it doesn't work at all, in which case this would be a "kernel-xen" bug, in all likelihood. Chris Lalancette
It depends on whether xen can start minix normally, I will test it (install a minix guest on xen). then tell you the result. if the minix can run normally on xen, it's a bug of virt-convert.
have tested by installing a minix3 on xen, it failed. the problem is same----blocked at booting screen, always there. so I think it's not a bug of virt-convert, but caused by xen don't support minix3.
OK, thanks for confirming. I'll move it to the xen component for now, since that is one place where the problem might actually be (another is kernel-xen, I just don't know yet). Chris Lalancette
(In reply to comment #10) > OK, thanks for confirming. I'll move it to the xen component for now, since > that is one place where the problem might actually be (another is kernel-xen, I > just don't know yet). > > Chris Lalancette Well, I don't know where exactly this could be but I tried it and it's saying something about 3 seconds to boot the first option. The problem here is that it's stuck even before I can enter a digit to choose what version of MINIX to boot so this is really a bug that's xen related. I don't know whether it's xen or kernel-xen but there may be some call to the emulated BIOS environment, HVMAssist BIOS, that is not supported by it. But I can't see anything helpful in qemu-dm.{$PID}.log and xend.log so I don't really know where to look. Maybe more investigation in qemu-dm code is necessary and I also should add some logging to this one. I'm going to take this one and try to investigate. Michal
(In reply to comment #13) > (In reply to comment #10) > > OK, thanks for confirming. I'll move it to the xen component for now, since > > that is one place where the problem might actually be (another is kernel-xen, I > > just don't know yet). > > > > Chris Lalancette > > Well, I don't know where exactly this could be but I tried it and it's saying > something about 3 seconds to boot the first option. The problem here is that > it's stuck even before I can enter a digit to choose what version of MINIX to > boot so this is really a bug that's xen related. I don't know whether it's xen > or kernel-xen but there may be some call to the emulated BIOS environment, > HVMAssist BIOS, that is not supported by it. But I can't see anything helpful > in qemu-dm.{$PID}.log and xend.log so I don't really know where to look. Maybe > more investigation in qemu-dm code is necessary and I also should add some > logging to this one. I'm going to take this one and try to investigate. > > Michal I've been doing some investigation of this one and finally I have added logging support for the qemu-dm process to log all the outputs to port port 0xE9 using the do_outp() function in helper2.c code. What I was thinking was confirmed, There is a halt called from some EIP instruction since there is a "Unknown opcode at 9317:0412=0x93582" message when trying to boot Minix. It appears some important instruction used by Minix is not emulated at the time resulting in halt of the virtual machine. Michal
This is happening in vmxassist. It is not a complete vm86 implementation, and it doesn't handle some exits. For HLT we can afford doing nothing, the only problem is that the guest will busy wait while in real mode. You just need something like: case 0xF4: /* hlt */ TRACE((regs, regs->eip - eip, "hlt")); return OPC_EMULATED;
Created attachment 405545 [details] Screenshot of minix boot after patching vmxassist (In reply to comment #15) > This is happening in vmxassist. It is not a complete vm86 implementation, and > it doesn't handle some exits. For HLT we can afford doing nothing, the only > problem is that the guest will busy wait while in real mode. You just need > something like: > > case 0xF4: /* hlt */ > TRACE((regs, regs->eip - eip, "hlt")); > return OPC_EMULATED; Thanks, I did try to emulate the halt instruction and it passed this part but it's still not working. It's stuck a little later but still stuck. No real output is present in the debug file from the hvmloader/vmxassist: HVM Loader Detected Xen v3.1.2-194.el5 Writing SMBIOS tables ... Loading ROMBIOS ... 8876 bytes of ROMBIOS high-memory extensions: Relocating to 0x1ffac00-0x1ffceac ... done PCI-ISA link 0 routed to IRQ5 PCI-ISA link 1 routed to IRQ7 PCI-ISA link 2 routed to IRQ10 PCI-ISA link 3 routed to IRQ11 pci dev 01:1 bar 20 size 00000010: 0000c001 pci dev 01:2 INTA->IRQ7 pci dev 02:0 bar 10 size 02000000: f0000008 pci dev 02:0 bar 14 size 00001000: f2000000 pci dev 03:0 bar 10 size 00000100: 0000c101 pci dev 03:0 bar 14 size 01000000: f3000008 pci dev 03:0 INTA->IRQ11 Creating MP tables ... Loading Cirrus VGABIOS ... Loading ACPI ... BIOS map: c0000-c8003: VGA BIOS d0000-d5403: VMXAssist e9000-e9171: SMBIOS tables ea000-eb2cf: ACPI tables f0000-fffff: Main BIOS Loading VMXAssist ... VMX go ... VMXAssist (Mar 9 2010) Memory size 31 MB E820 map: 0000000000000000 - 000000000009FC00 (RAM) 000000000009FC00 - 00000000000A0000 (Reserved) 00000000000E0000 - 0000000000100000 (Reserved) 0000000000100000 - 0000000001FFAC00 (RAM) 0000000001FFAC00 - 0000000002000000 (Reserved) Start BIOS ... Starting emulated 16-bit real-mode: ip=F000:FFF0 rombios.c,v 1.138 2005/05/07 15:55:26 vruppert Exp $ Remapping master: ICW2 0x8 -> 0x20 Remapping slave: ICW2 0x70 -> 0x28 VGABios $Id: vgabios.c,v 1.61 2005/05/24 16:50:50 vruppert Exp $ HVMAssist BIOS, 1 cpu, $Revision: 1.138 $ $Date: 2005/05/07 15:55:26 $ ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (8192 MBytes) ata0 slave: Unknown device Booting from Hard Disk... ... and that's all ... It seems like this is purely the guest issue. The guest is stuck with the screen attached to this comment and that's all. It's using converted image like in comment #0 but since I don't see anything in the vmxassist/hvmloader output and nothing in the qemu-dm.{PID}.log so I don't know now. Thanks for the talk about instructions, emulation, vm86 etc. anyway :) Michal
> It seems like this is purely the guest issue. The guest is stuck with the > screen attached to this comment and that's all This says the opposite to me, it's likely another bug in qemu or the hypervisor. xenctx says that cs=0x0030 so it's already in protected mode and vmxassist is out of the picture.
(In reply to comment #17) > > It seems like this is purely the guest issue. The guest is stuck with the > > screen attached to this comment and that's all > > This says the opposite to me, it's likely another bug in qemu or the > hypervisor. xenctx says that cs=0x0030 so it's already in protected mode and > vmxassist is out of the picture. Yeah, this can be. Well, but under the qemu itself (no kvm involved) it runs OK but with qemu-kvm (respectively KVM enabled) it does not. Same with Xen. For the HLT instruction emulation patch attached to bug 580945 is necessary. Michal
I close this as WONTFIX, as minix is not supported guest, and it costs quite a lot time to discover the real problem.