nadim khemir wrote: > Hi, great work. > > While playing with kvm-qemu I noticed a few points that might be of interrest: > > 1/ -loadvm and -snapshot don't work together. It works as if -loadvm wasn't > passed as argument > > 2/ two instances of kvm can be passed the same -hda. There is no locking > whatsoever. This messes up things seriously. > >
These two are upstream qemu problems. Copying qemu-devel. I guess using file locking by default would improve the situation, and we can add a -drive ...,exclusive=no option for people playing with cluster filesystems. > 3/ trying to run 'savevm' in the qemu console when -usb is used results in > > (qemu) savevm scite > (qemu) exception 13 (0) > rax 0000000000000000 rbx 0000000000000000 rcx 0000000000000010 rdx > 0000000000000000 > ... > > This is documented but a warning in the console would be better than a crash > > if the vm is stopped first, 'savevm' works but it still crashes on 'cont' > instead > > 4/ if -vga-std is used when doing a 'savevm', 'loadvm' restores a black > screen. Everything is there and with some gymnastic (moving a window around) > the screen is like it should be. > > 5/ -usbdevice tablet is a must, 'ctl+alt' is just too painfull! is it > possible > to get the same effect (with another system) and still be able to 'savevm'? > > -vmmouse will work with Linux, with Windows, you might need to install a driver. > 6/ If you use -usbdevice tablet, keyboard is first handled by guest OS. In my > case I have 'alt F4' close windows in the host OS. If I try to close a window > in the guest OS with 'alt f4', it closes qemu altogether. > Try full screen mode (alt-ctrl-F). If the host didn't handle Alt-F4 in non-capture mode, you'd have no way to close the qemu window. > 7/ On the other hand, mouse events are _not_ handled by the gues OS first, > IE: > alt click isn't handled by X but by windows (in this case) > > 8/ keyboard input lost when switching to full screen or back. fixed by > using 'ctl+alt' twice > > 9/ IMHO, the way "versionning" with 'savevm' is done could feel more natural. > > first run > time ------------------------------> stop VM > ^ | > | | > | v > savevm state1 automatically save "HEAD" in -hda > > > > second run > time ------------------------------>stop VM > ^ | > | | > | v > loadvm state1 automatically save "HEAD" in -hda > ^ > | > .----------' > | > .-------------------------------------------------. > | I believe most people want to save in 'state1' | > | or possibly in 'state2' but few want to | > | override "HEAD" | > '-------------------------------------------------' > > > automatically overriding 'state1' feels as wrong as overriding "HEAD". I > believe that a -savevm to qemu would be a good idea. If nothing is passed as > argument "HEAD" is used. That would preserve "HEAD" and allow saving to a > user defined vm snapshot. > > 10/ subscription to the mailing list doesn't seem to work > > What do you mean? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
