[Qemu-devel] Re: importing VMWare image
Yves Trudeau wrote: Filip Navara a écrit : Yves Trudeau wrote: Hi, I am trying to use a VMWare Win2k image in Qemu-0.7.1. I imported the image with qemu-img successfully but when I lauch qemu, I have the first part (in text mode) of the win2k boot with the progress bar but as soon as it attempt to switch to graphic mode, qemu freezes. I tried "--stdvga" and booted win2k in safe-mode with no result. Is there someone who successfully imported a VMWare image? Any hint will be appreciated. Yves The hardware emulated by QEMU and VMware is different. You might want to try running the image in VMware and reinstalling "Standard IDE driver" instead of the one that is used and then importing the image. - Filip I tried all the "standard" drivers I could find without success, still the same problem. I want to import this vmware image because I have a software, Mindmanager, that runs well under vmware but not under Qemu, altought the installation raises no error. Any other suggestions? How about a seperate hardware profile with almost everything disabled. Could ACPI be causing you problems? If so, it might be time to switch HALs. Adam ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-img.exe to create file greater than 4GB for win32
Hi, Now qemu-img.exe can't create a file greater than 2GB on Windows. A patch and a binary below supports to make a file greater than 4GB on NTFS file system for Windows 2000/XP. This patch is made by lukewarm. http://ebisa.hp.infoseek.co.jp/qemu/arcs/qemu-0.7.1-win32-imgover4g.zip Note: MinGW's ls doesn't show a correct file size if greater than 2GB. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Default BIOS path for win32
Hi, A default BIOS path isn't set properly for win32 when a slash is used to set a drive letter. Attached patch is a workaround for it. It's OK when a path is set manually by -L option. Regards, Kazu qemu-0.7.1-bios.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: Re: [Qemu-devel] usb and qemu
"Jim C. Brown" <[EMAIL PROTECTED]> > > On Tue, Aug 09, 2005 at 10:33:31PM +0200, Michael Hoeller wrote: > > Hello, > > > > is there a way to access an usb stick from Windows which runs in qemu > > under Linux?? > > > > Michael > > > > No. > > http://usbip.naist.jp/ and http://sourceforge.net/projects/usbip/ might help > if the guest and the host were both linux 2.6, however afaict usbip does not > work > under Windows yet. I haven't tried it, but couldn't you either pass the physical device (like /dev/sda) as -hdb, or mount up the USB memory stick and use samba (either qemu's builtin or an existing samba server) to share it to the window's guest? Ben ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] usb and qemu
On Wednesday 10 August 2005 12:57, Ben Taylor wrote: > I haven't tried it, but couldn't you either pass the > physical device (like /dev/sda) as -hdb, or mount up > the USB memory stick and use samba (either qemu's > builtin or an existing samba server) to share it to > the window's guest? > I do this way too Dsant ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Binary package and the kqemu support.
Paul Brook wrote: > > From http://fabrice.bellard.free.fr/qemu/qemu-accel.html: > > > > Terms of Use > > The QEMU Accelerator is free to use, but it is a closed source > > proprietary product. You are not allowed to distribute it yourself to > > other people without an explicit authorisation. Distributors wishing to > > include the QEMU accelerator on CDs, ISO images or packages must contact > > the author to know the exact terms. > > However the qemu 0.7.1 binaries distributed from the qemu website include > kqemu support. This means you are entitled to kqemu.h (which is > necessary to compile kqemu.c) under the LGPL. No, that is not correct. > By distributing kqemu enabled qemu binaries Fabrice has implicitly > dual-licenced kqemu.h under both the LGPL and his kqemu proprietary licence. No. Fabrice is special, because he is the copyright holder. He has the right to distribute binaries, prepared using his own source, using whatever license he likes. That by itself does _not_ grant you an "implicit" license to the source used to prepare those binaries. However, if he is distributing _source_ for kqemu-enabled qemu including kqemu.h, and if he states that the whole source tarball (which happened to include kqemu.h) is under the LGPL, then you could begin to make a case for an implied license of parts of the tarball (i.e. kqemu.h, if it's in that source tarball). I don't know if he's doing that. Also, if he is distributing binaries where part of the binary is LGPL'd or GPL'd code where the _copyright is held by other people_ (i.e. contributors), then you can make a case that if he's distributing kqemu-enabled binaries of qemu (that nobody else is able to legally reproduce), he's infringing the contributor's copyright. But if he's only distributed binaries which are compiled from _his_ LGPL'd code and _his_ closed source code - well, he can simply do that, and the binaries come under whatever binary license he's using. This is all moot, however, as you can just ask Fabrice and he may well be happy to put kqemu.h under the same license as qemu. It's only a small interface file, and nearly all of it, or perhaps all of it (these things are uncertain), may be usable under fair use anyway. -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Binary package and the kqemu support.
> Also, if he is distributing binaries where part of the binary is > LGPL'd or GPL'd code where the _copyright is held by other people_ > (i.e. contributors), then you can make a case that if he's > distributing kqemu-enabled binaries of qemu (that nobody else is able > to legally reproduce), he's infringing the contributor's copyright. That is the case. If you look at the licences the dissassembly parts are (C) Free Software Foundation and licenced under the GPL, so the whole should be made available under those terms. > But if he's only distributed binaries which are compiled from _his_ > LGPL'd code and _his_ closed source code - well, he can simply do > that, and the binaries come under whatever binary license he's using. This is not the case. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] usb and qemu
Isn't there a USB patch floating around somewhere (emulates OHCI in the guest)? Or am I remembering something else? Cheers, Mark On Wednesday 10 August 2005 11:57, Ben Taylor wrote: > "Jim C. Brown" <[EMAIL PROTECTED]> > > > On Tue, Aug 09, 2005 at 10:33:31PM +0200, Michael Hoeller wrote: > > > Hello, > > > > > > is there a way to access an usb stick from Windows which runs in qemu > > > under Linux?? > > > > > > Michael > > > > No. > > > > http://usbip.naist.jp/ and http://sourceforge.net/projects/usbip/ might > > help if the guest and the host were both linux 2.6, however afaict usbip > > does not work under Windows yet. > > I haven't tried it, but couldn't you either pass the > physical device (like /dev/sda) as -hdb, or mount up > the USB memory stick and use samba (either qemu's > builtin or an existing samba server) to share it to > the window's guest? > > Ben > > > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] usb and qemu
On Wednesday 10 August 2005 14:49, Mark Williamson wrote: > > > http://usbip.naist.jp/ and http://sourceforge.net/projects/usbip/ might > > > help if the guest and the host were both linux 2.6, however afaict usbip > > > does not work under Windows yet. >... > Isn't there a USB patch floating around somewhere (emulates OHCI in the > guest)? Yes, but noone's written the code to wire it up to host devices. AFAIK it currently emulates the host controller and not much else. Using the usb-over-ip protocol mentioned above seems like a nice way of getting it to talk to host USB devices in a host-independent way. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: Re: [Qemu-devel] usb and qemu
On Wed, Aug 10, 2005 at 06:57:14AM -0400, Ben Taylor wrote: > I haven't tried it, but couldn't you either pass the > physical device (like /dev/sda) as -hdb, or mount up > the USB memory stick and use samba (either qemu's > builtin or an existing samba server) to share it to > the window's guest? > > Ben > Yes, silly me. That should work fine (with samba you could even swap usb sticks while the guest was running). -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] usb and qemu
On Wed, Aug 10, 2005 at 03:03:25PM +0100, Paul Brook wrote: > > Isn't there a USB patch floating around somewhere (emulates OHCI in the > > guest)? > > Yes, but noone's written the code to wire it up to host devices. AFAIK it > currently emulates the host controller and not much else. > > Using the usb-over-ip protocol mentioned above seems like a nice way of > getting it to talk to host USB devices in a host-independent way. IIRC, one of the authors of the patch wanted to use usbip in qemu, so the guest could see and use host usb devices (thinking that they were connected to the virtual machine) without having to be aware of, or have support for, usbip. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] usb and qemu
On Wednesday 10 August 2005 18:07, Jim C. Brown wrote: > On Wed, Aug 10, 2005 at 03:03:25PM +0100, Paul Brook wrote: > > > Isn't there a USB patch floating around somewhere (emulates OHCI in the > > > guest)? > > > > Yes, but noone's written the code to wire it up to host devices. AFAIK it > > currently emulates the host controller and not much else. > > > > Using the usb-over-ip protocol mentioned above seems like a nice way of > > getting it to talk to host USB devices in a host-independent way. > > IIRC, one of the authors of the patch wanted to use usbip in qemu, so the > guest could see and use host usb devices (thinking that they were connected > to the virtual machine) without having to be aware of, or have support for, > usbip. Right, that's what I meant. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re:is there a way to access an usb stick from Windows which runs in qemu
>is there a way to access an usb stick from Windows > which runs in qemu > under Linux?? Actually I acces my physical hard disks and all types of media when i'm using a guest OS using ftp server. First i start up an FTP server on winblows, next I login from qemu guest OS, in my case DSL linux. Then lastly i login with ftp my.windows.box.net bam now i have full access to my drives under qemu. NOTE: make sure when you setup ftp server that you specify read write and execute and the directory that you wanna share... ie C:\ or F:\ Thats how i do it. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Connecting vde and LAN
On Thu, Aug 04, 2005 at 12:14:53PM +0200, Henrik Nordstrom wrote: > For host->guest packets the RAW sockets demonstrated earlier is fine if > you accept that the guest packets is also duplicated on the local lan. I > do not know of a method to have host->guest packets sent cleanly without > duplication on the Ethernet without setting up a TUN/TAP or PPP interface. > > Regards > Henrik > I was thinking that perhaps vde_packet could be modified to use a tap device (for example tap0). Since the guests can't communicate to the address thats on tap0, it doesn't matter what address it gets - the host address of tap0 and the ip addresses of the guests don't even have to be on the same subnet. So, the modified vde_packet would listen on the vde network and set packets meant for the host (or other workstations on the LAN) to tap0. A route would be set up so that the packets would be routed from tap0 to eth0, which would allow the host to see them. On the other side, vde_packet would listen to eth0, and intercept any packets meant for the guests and inject those into the vde network. Of course, I realize that this isn't as good as being able to get vde_pcap to work right, as it still requires host OS support (for the tap device). However, it sounds easier than playing with ARP and IP packets and still gives the same benefit - we get to bridge the vde network with the LAN onto eth0 instead of br0. I'm still learning how to create and manipulate tuntap devices so I haven't been able to code this up yet. Are there any obvious problems that I missed which would prevent this from working? -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Any med for your girl to be happy!
___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] usb and qemu
> > Isn't there a USB patch floating around somewhere (emulates OHCI in the > > guest)? > > Yes, but noone's written the code to wire it up to host devices. AFAIK it > currently emulates the host controller and not much else. Oh, OK that makes sense. > Using the usb-over-ip protocol mentioned above seems like a nice way of > getting it to talk to host USB devices in a host-independent way. Actually that'd be a fairly neat trick... As an alternative, IIRC there's a user space API for writing USB drivers under Linux - using that you could get access to both local and remote (IP encapsulated) USB devices, albeit not in a cross-platform (host-wise) way. Cheers, Mark ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] usb and qemu
On Wednesday 10 August 2005 5:10 pm, Mark Williamson wrote: > > > Isn't there a USB patch floating around somewhere (emulates OHCI in the > > > guest)? > > > > Yes, but noone's written the code to wire it up to host devices. AFAIK it > > currently emulates the host controller and not much else. > > Oh, OK that makes sense. > > > Using the usb-over-ip protocol mentioned above seems like a nice way of > > getting it to talk to host USB devices in a host-independent way. > > Actually that'd be a fairly neat trick... As an alternative, IIRC there's a > user space API for writing USB drivers under Linux - using that you could get > access to both local and remote (IP encapsulated) USB devices, albeit not in > a cross-platform (host-wise) way. That would be called libusb. The libusb V1_0_DEVEL branch would be the prime candidate for this "wiring up", but is however incomplete. libusb (<=0.1.10a) does not support asynchronous communications and does not have an api to deal with isochronous usb transfers as well. I've been messing around with the ohci-hc / libusb 1.0 connection, albeit slowly. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] bug in Sparc part ?
I don't know if it has already been said on this list. Forgive me if so. -1- i386 only : make clean ok ./configure --cc=gcc32 --target-list="i386-softmmu i386-user" ok make ok -2- default : make cleanok ./configure --cc=gcc32 ok make ->ERROR gcc32 -Wall -O2 -g -fno-strict-aliasing -I. -I/home/moi/install/qemu/qemu-0.7.1/target-sparc -I/home/moi/install/qemu/qemu-0.7.1 -I/home/moi/install/qemu/qemu-0.7.1/linux-user -I/home/moi/install/qemu/qemu-0.7.1/linux-user/sparc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/home/moi/install/qemu/qemu-0.7.1/fpu -I/home/moi/install/qemu/qemu-0.7.1/slirp -c -o translate-op.o /home/moi/install/qemu/qemu-0.7.1/translate-op.c In file included from /home/moi/install/qemu/qemu-0.7.1/translate-op.c:36: op.h: In function `dyngen_code': op.h:3759: syntax error before '.' token op.h:3761: syntax error before '.' token make[1]: *** [translate-op.o] Error 1 make[1]: Leaving directory `/home/moi/install/qemu/qemu-0.7.1/sparc-user' make: *** [all] Error 1 I don't known anything about Sparc, so don't ask me. my configuration : Fedora core 4 - 64 bits, qemu 0.7.1 Dsant, from Lyon in France ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
