[Qemu-devel] Re: [kvm-devel] Feedback and errors

[Qemu-devel] Re: [kvm-devel] Feedback and errors

[Avi Kivity]

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.

[Qemu-devel] Re: [kvm-devel] Feedback and errors

[Anthony Liguori]

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

[Qemu-devel] Re: [kvm-devel] Feedback and errors

[Avi Kivity]

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.

[Qemu-devel] Re: [kvm-devel] Feedback and errors

[Anthony Liguori]

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

[Qemu-devel] Re: [kvm-devel] Feedback and errors

[Avi Kivity]

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

[Qemu-devel] Re: [kvm-devel] Feedback and errors

[nadim khemir]

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?

[Qemu-devel] Re: [kvm-devel] Feedback and errors

[Javier Guerra Giraldez]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[Qemu-devel] Re: [kvm-devel] Feedback and errors

[Daniel P. Berrange]

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 :|

[Qemu-devel] Re: [kvm-devel] Feedback and errors

[Avi Kivity]

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.

Re: [Qemu-devel] Re: [kvm-devel] Feedback and errors

[Jamie Lokier]

Daniel P. Berrange wrote:
> > > 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). 

That reminds me, a "read-only" option for disk images would be handy
occasionally.  Writes would return errors, rather than to an expanding
snapshot file.

And then, logically, any default locking for disk images (if you don't
disable it) would use shared locking for a read-only disk image.

> > 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.

Imho disk locking should be on by default and easy to turn off.

Casual small scale use of QEMU doesn't use a "management stack", it
uses the command line directly invoking qemu or kvm, or a one-line
script.  In that scenario locking against running two instances _by
mistake_ is most useful (it's easy to accidentally forget you have one
running when hidden on the desktop), and least likely for someone to
use a wrapper.

The few cluster deployments using shared disks will notice very
quickly that an additional option is needed for the new QEMU version.
It won't be the first time a new version has required a change to the
command line options to keep an existing deployment working.

-- Jamie