Re: [kvm-devel] Feedback and errors
Anthony Liguori wrote: Avi Kivity wrote: Well, one user (me) has made this mistake, several times. I guess it's usage patterns. I'm pretty religious about using -snapshot unless I have a very specific reason not to. I have never encountered this problem myself. Most users cannot use -snapshot for their workloads. FWIW, the whole override thing for Xen has been an endless source of pain. It's very difficult (if not impossible) to accurately determine if someone else is using the disk. What's wrong with the standard file locking API? Of course it won't stop non-qemu apps from accessing it, but that's unlikely anyway. Xen tries to be very smart about determining whether devices are mounted somewhere else or not. I'm not talking about being too smart. Just an flock(). Also, it tends to confuse people trying to do something legitimate more often than helping someone doing something stupid. -drive exclusive=off (or share=yes) The problem I have is that the default policy gets very complicated. At first thought, I would say it's fine as long as exclusive=off was the default for using -snapshot or using raw images. However, if you create a VM with a qcow image using -snapshot, and then create another one without using snapshot, you're boned. Well then, default to exclusive=on. If you're using -shapshot you can add the extra parameter as well. What we really need is a global configuration file so that individual users can select these defaults according to what makes sense for them. In the mean time, I think the policy vs. mechanism strongly suggests that exclusive=off should be the default (not to mention maintaining backwards compatibility). The problem is that this is bad for users. -- error compiling committee.c: too many arguments to function - 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
Re: [kvm-devel] Feedback and errors
On Friday 02 May 2008, Anthony Liguori wrote: What we really need is a global configuration file so that individual users can select these defaults according to what makes sense for them. i favor the idea of writing parameters into the boot image itself. -- Javier signature.asc Description: This is a digitally signed message part. - 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
Re: [kvm-devel] Feedback and errors
On Sunday 04 May 2008 13.19.30 Avi Kivity wrote: ... I guess it's usage patterns. I'm pretty religious about using -snapshot unless I have a very specific reason not to. I have never encountered this problem myself. Most users cannot use -snapshot for their workloads. and -snapshot does not work with loadvm. Xen tries to be very smart about determining whether devices are mounted somewhere else or not. I'm not talking about being too smart. Just an flock(). That's also what I'd like to see. Make the flock call a standard and have option --exclisove-hda-lock check that no one else has locked the file. This way backwardcompatibility is kept and the one who wants to check still can do it. What we really need is a global configuration file so that individual users can select these defaults according to what makes sense for them. Any example? - 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
Re: [kvm-devel] Feedback and errors
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 rbx rcx 0010 rdx ... 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 state1automatically 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
Re: [kvm-devel] Feedback and errors
Avi Kivity wrote: 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. This is not a situation where the user has a reasonable expectation of what will happen that we violate. If the user is unhappy with the results, it's because the user made a mistake. FWIW, the whole override thing for Xen has been an endless source of pain. It's very difficult (if not impossible) to accurately determine if someone else is using the disk. Also, it tends to confuse people trying to do something legitimate more often than helping someone doing something stupid. I very frequently run multiple VMs with the same disk. I do it strictly for the purposes of benchmarking. There are ways to share a disk without using a clustered filesystem. If a higher level management tool wants to enforce a policy (like libvirt), then let it. We should not be enforcing policies within QEMU though. Regards, Anthony Liguori - 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
Re: [kvm-devel] Feedback and errors
On Fri, May 02, 2008 at 01:52:18PM +0300, Avi Kivity wrote: 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. That depends entirely on what you are doing with the disk in the guest OS. The disk could be hosting a cluster filesystem. The guest OS could be running on a read-only root FS. The disk could be application raw data storage which can be shared (eg Oracle RAC). And if the disk is backed by a physical volume which is accessible to multiple hosts, locking on the VM's host won't provide any safety against VMs on another host accessing it. 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. Turning on file locking by default will break existing apps / deployments using shared disks. IMHO this is a policy decision that should be solved at ahigher level in the management stack where a whole world view is available rather than QEMU which only knows about its own VM host. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| - 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
Re: [kvm-devel] Feedback and errors
Anthony Liguori wrote: 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. This is not a situation where the user has a reasonable expectation of what will happen that we violate. If the user is unhappy with the results, it's because the user made a mistake. Well, one user (me) has made this mistake, several times. FWIW, the whole override thing for Xen has been an endless source of pain. It's very difficult (if not impossible) to accurately determine if someone else is using the disk. What's wrong with the standard file locking API? Of course it won't stop non-qemu apps from accessing it, but that's unlikely anyway. Also, it tends to confuse people trying to do something legitimate more often than helping someone doing something stupid. -drive exclusive=off (or share=yes) I very frequently run multiple VMs with the same disk. I do it strictly for the purposes of benchmarking. There are ways to share a disk without using a clustered filesystem. I imagine only raw format disks, and only as non-root filesystems (or with -shapshot, which should automatically set exclusive=off)? If a higher level management tool wants to enforce a policy (like libvirt), then let it. We should not be enforcing policies within QEMU though. I agree that qemu is not the place to enforce policies, but covering a hole that users are likely to step into, while allowing its explicit uncovering, is a good thing. We're not enforcing the policy, only hinting. -- 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
Re: [kvm-devel] Feedback and errors
Daniel P. Berrange wrote: 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. Turning on file locking by default will break existing apps / deployments using shared disks. IMHO this is a policy decision that should be solved at ahigher level in the management stack where a whole world view is available rather than QEMU which only knows about its own VM host. Running a newer qemu with an older libvirt would pose a problem, yes. But we shouldn't ignore unmanaged deployments. -- 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
Re: [kvm-devel] Feedback and errors
Avi Kivity wrote: Well, one user (me) has made this mistake, several times. I guess it's usage patterns. I'm pretty religious about using -snapshot unless I have a very specific reason not to. I have never encountered this problem myself. FWIW, the whole override thing for Xen has been an endless source of pain. It's very difficult (if not impossible) to accurately determine if someone else is using the disk. What's wrong with the standard file locking API? Of course it won't stop non-qemu apps from accessing it, but that's unlikely anyway. Xen tries to be very smart about determining whether devices are mounted somewhere else or not. Also, it tends to confuse people trying to do something legitimate more often than helping someone doing something stupid. -drive exclusive=off (or share=yes) The problem I have is that the default policy gets very complicated. At first thought, I would say it's fine as long as exclusive=off was the default for using -snapshot or using raw images. However, if you create a VM with a qcow image using -snapshot, and then create another one without using snapshot, you're boned. What we really need is a global configuration file so that individual users can select these defaults according to what makes sense for them. In the mean time, I think the policy vs. mechanism strongly suggests that exclusive=off should be the default (not to mention maintaining backwards compatibility). I very frequently run multiple VMs with the same disk. I do it strictly for the purposes of benchmarking. There are ways to share a disk without using a clustered filesystem. I imagine only raw format disks, and only as non-root filesystems (or with -shapshot, which should automatically set exclusive=off)? Yup. If a higher level management tool wants to enforce a policy (like libvirt), then let it. We should not be enforcing policies within QEMU though. I agree that qemu is not the place to enforce policies, but covering a hole that users are likely to step into, while allowing its explicit uncovering, is a good thing. We're not enforcing the policy, only hinting. Unfortunately, the solution involves breaking backwards compatibility for legitimate use-cases (not to mention making those use-cases more awkward). I think the only way to sanely do this is as a global configuration parameter. Regards, Anthony Liguori - 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
