[Qemu-devel] block bug: tray status is not updated (and/or guest ignores it)

[Qemu-devel] block bug: tray status is not updated (and/or guest ignores it)

[Luiz Capitulino]

I'm testing with qemu.git (HEAD aa29141d84d), procedure:

1. Start a VM with:

 # qemu -hda disks/test.img -enable-kvm -m 1G -cdrom Fedora-14-x86_64-DVD.iso

2. Then inside the guest run:

 # eject /dev/sr0 && mount /dev/sr0 /mnt

Results:

 Actual: The cdrom is successfully mounted
 Expected: The cdrom is not mounted (mount fails, medium not found)

Git bisect tells the culprit is:

996faf1ad4a93342e381766d95686b16624f0dbd is the first bad commit
commit 996faf1ad4a93342e381766d95686b16624f0dbd
Author: Amit Shah <amit.shah@redhat.com>
Date:   Tue Apr 12 21:36:07 2011 +0530

    atapi: GESN: implement 'media' subcommand

Re: [Qemu-devel] block bug: tray status is not updated (and/or guest ignores it)

[Amit Shah]

On (Thu) 26 May 2011 [15:29:29], Luiz Capitulino wrote:
> 
> I'm testing with qemu.git (HEAD aa29141d84d), procedure:
> 
> 1. Start a VM with:
> 
>  # qemu -hda disks/test.img -enable-kvm -m 1G -cdrom Fedora-14-x86_64-DVD.iso
> 
> 2. Then inside the guest run:
> 
>  # eject /dev/sr0 && mount /dev/sr0 /mnt
> 
> Results:
> 
>  Actual: The cdrom is successfully mounted
>  Expected: The cdrom is not mounted (mount fails, medium not found)

Really?  That's what you expect? :-)

Where will the medium go?

What happens is mount auto-closes the tray and mounts whatever is
there, which is the image you provided.  Works as expected, IMO.

Can you try this with a physical cdrom drive where the tray can be
opened/closed by software commands?  It should give you a similar
behaviour.

		Amit

Re: [Qemu-devel] block bug: tray status is not updated (and/or guest ignores it)

[Amit Shah]

On (Fri) 27 May 2011 [17:01:35], Amit Shah wrote:
> On (Thu) 26 May 2011 [15:29:29], Luiz Capitulino wrote:
> > 
> > I'm testing with qemu.git (HEAD aa29141d84d), procedure:
> > 
> > 1. Start a VM with:
> > 
> >  # qemu -hda disks/test.img -enable-kvm -m 1G -cdrom Fedora-14-x86_64-DVD.iso
> > 
> > 2. Then inside the guest run:
> > 
> >  # eject /dev/sr0 && mount /dev/sr0 /mnt
> > 
> > Results:
> > 
> >  Actual: The cdrom is successfully mounted
> >  Expected: The cdrom is not mounted (mount fails, medium not found)
> 
> Really?  That's what you expect? :-)
> 
> Where will the medium go?
> 
> What happens is mount auto-closes the tray and mounts whatever is
> there, which is the image you provided.  Works as expected, IMO.
> 
> Can you try this with a physical cdrom drive where the tray can be
> opened/closed by software commands?  It should give you a similar
> behaviour.

BTW in case mount doesn't auto-close the tray, it should fail with a
'tray open' message, not with a medium not found message.  I'm
checking the code to see what's happening in the meanwhile.

		Amit

Re: [Qemu-devel] block bug: tray status is not updated (and/or guest ignores it)

[Amit Shah]

On (Fri) 27 May 2011 [17:04:30], Amit Shah wrote:
> On (Fri) 27 May 2011 [17:01:35], Amit Shah wrote:
> > On (Thu) 26 May 2011 [15:29:29], Luiz Capitulino wrote:
> > > 
> > > I'm testing with qemu.git (HEAD aa29141d84d), procedure:
> > > 
> > > 1. Start a VM with:
> > > 
> > >  # qemu -hda disks/test.img -enable-kvm -m 1G -cdrom Fedora-14-x86_64-DVD.iso
> > > 
> > > 2. Then inside the guest run:
> > > 
> > >  # eject /dev/sr0 && mount /dev/sr0 /mnt
> > > 
> > > Results:
> > > 
> > >  Actual: The cdrom is successfully mounted
> > >  Expected: The cdrom is not mounted (mount fails, medium not found)
> > 
> > Really?  That's what you expect? :-)
> > 
> > Where will the medium go?
> > 
> > What happens is mount auto-closes the tray and mounts whatever is
> > there, which is the image you provided.  Works as expected, IMO.

Confirmed, that's what happens.

What's weird though is 'eject' in the monitor makes the cdrom go away
-- a subsequent mount in the guest results in a no medium error.  I
thought we had solved that, Markus?

By not doing a bdrv_close() in the do_eject()->eject_device() call
path this starts working as expected.

		Amit

Re: [Qemu-devel] block bug: tray status is not updated (and/or guest ignores it)

[Luiz Capitulino]

On Fri, 27 May 2011 18:10:08 +0530
Amit Shah <amit.shah@redhat.com> wrote:

> On (Fri) 27 May 2011 [17:04:30], Amit Shah wrote:
> > On (Fri) 27 May 2011 [17:01:35], Amit Shah wrote:
> > > On (Thu) 26 May 2011 [15:29:29], Luiz Capitulino wrote:
> > > > 
> > > > I'm testing with qemu.git (HEAD aa29141d84d), procedure:
> > > > 
> > > > 1. Start a VM with:
> > > > 
> > > >  # qemu -hda disks/test.img -enable-kvm -m 1G -cdrom Fedora-14-x86_64-DVD.iso
> > > > 
> > > > 2. Then inside the guest run:
> > > > 
> > > >  # eject /dev/sr0 && mount /dev/sr0 /mnt
> > > > 
> > > > Results:
> > > > 
> > > >  Actual: The cdrom is successfully mounted
> > > >  Expected: The cdrom is not mounted (mount fails, medium not found)
> > > 
> > > Really?  That's what you expect? :-)

That was the VM behavior before 996faf1ad, therefore it's what I was
expecting.

> > > Where will the medium go?

We were leaking it then?

> > > What happens is mount auto-closes the tray and mounts whatever is
> > > there, which is the image you provided.  Works as expected, IMO.
> 
> Confirmed, that's what happens.

Ok. I got this by testing my series that adds the BLOCK_MEDIA_EJECT event.
At first I thought your commit wasn't handling the tray status correctly
(which would cause problems to the new event), but it seems to work fine,
specially now that I know what's doing. Sorry for the noise.

> What's weird though is 'eject' in the monitor makes the cdrom go away
> -- a subsequent mount in the guest results in a no medium error.  I
> thought we had solved that, Markus?
> 
> By not doing a bdrv_close() in the do_eject()->eject_device() call
> path this starts working as expected.

Yes, also note that with the -f option eject is capable of purging
any block device. I wonder if libvirt (or any client) relies on this.

IMHO, we should do the following:

 1. Drop bdrv_close() from eject and change it to just eject a device
    (which also means working only on removable media)

 2. If we really want to be able to remove block devices from the VM,
    we should add a new command for that

 3. The change command does an eject followed by a bdrv_close(), this is
    fine, considering we can't break compatibility here

Re: [Qemu-devel] block bug: tray status is not updated (and/or guest ignores it)

[Daniel P. Berrange]

On Fri, May 27, 2011 at 10:39:35AM -0300, Luiz Capitulino wrote:
> On Fri, 27 May 2011 18:10:08 +0530
> Amit Shah <amit.shah@redhat.com> wrote:
> 
> > On (Fri) 27 May 2011 [17:04:30], Amit Shah wrote:
> > > On (Fri) 27 May 2011 [17:01:35], Amit Shah wrote:
> > > > On (Thu) 26 May 2011 [15:29:29], Luiz Capitulino wrote:
> > > > > 
> > > > > I'm testing with qemu.git (HEAD aa29141d84d), procedure:
> > > > > 
> > > > > 1. Start a VM with:
> > > > > 
> > > > >  # qemu -hda disks/test.img -enable-kvm -m 1G -cdrom Fedora-14-x86_64-DVD.iso
> > > > > 
> > > > > 2. Then inside the guest run:
> > > > > 
> > > > >  # eject /dev/sr0 && mount /dev/sr0 /mnt
> > > > > 
> > > > > Results:
> > > > > 
> > > > >  Actual: The cdrom is successfully mounted
> > > > >  Expected: The cdrom is not mounted (mount fails, medium not found)
> > > > 
> > > > Really?  That's what you expect? :-)
> 
> That was the VM behavior before 996faf1ad, therefore it's what I was
> expecting.
> 
> > > > Where will the medium go?
> 
> We were leaking it then?
> 
> > > > What happens is mount auto-closes the tray and mounts whatever is
> > > > there, which is the image you provided.  Works as expected, IMO.
> > 
> > Confirmed, that's what happens.
> 
> Ok. I got this by testing my series that adds the BLOCK_MEDIA_EJECT event.
> At first I thought your commit wasn't handling the tray status correctly
> (which would cause problems to the new event), but it seems to work fine,
> specially now that I know what's doing. Sorry for the noise.
> 
> > What's weird though is 'eject' in the monitor makes the cdrom go away
> > -- a subsequent mount in the guest results in a no medium error.  I
> > thought we had solved that, Markus?
> > 
> > By not doing a bdrv_close() in the do_eject()->eject_device() call
> > path this starts working as expected.
> 
> Yes, also note that with the -f option eject is capable of purging
> any block device. I wonder if libvirt (or any client) relies on this.

libvirt will only issue 'eject' on devices which are CDROMs, or Floppy,
never hard disks, etc.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] block bug: tray status is not updated (and/or guest ignores it)

[Markus Armbruster]

"Daniel P. Berrange" <berrange@redhat.com> writes:

> On Fri, May 27, 2011 at 10:39:35AM -0300, Luiz Capitulino wrote:
>> On Fri, 27 May 2011 18:10:08 +0530
>> Amit Shah <amit.shah@redhat.com> wrote:
[...]
>> > What's weird though is 'eject' in the monitor makes the cdrom go away
>> > -- a subsequent mount in the guest results in a no medium error.  I
>> > thought we had solved that, Markus?
>> > 
>> > By not doing a bdrv_close() in the do_eject()->eject_device() call
>> > path this starts working as expected.
>> 
>> Yes, also note that with the -f option eject is capable of purging
>> any block device. I wonder if libvirt (or any client) relies on this.
>
> libvirt will only issue 'eject' on devices which are CDROMs, or Floppy,
> never hard disks, etc.

Any use of -f?  Recommend to stay away from it.

https://bugzilla.redhat.com/show_bug.cgi?id=676528

Re: [Qemu-devel] block bug: tray status is not updated (and/or guest ignores it)

[Daniel P. Berrange]

On Fri, May 27, 2011 at 04:35:24PM +0200, Markus Armbruster wrote:
> "Daniel P. Berrange" <berrange@redhat.com> writes:
> 
> > On Fri, May 27, 2011 at 10:39:35AM -0300, Luiz Capitulino wrote:
> >> On Fri, 27 May 2011 18:10:08 +0530
> >> Amit Shah <amit.shah@redhat.com> wrote:
> [...]
> >> > What's weird though is 'eject' in the monitor makes the cdrom go away
> >> > -- a subsequent mount in the guest results in a no medium error.  I
> >> > thought we had solved that, Markus?
> >> > 
> >> > By not doing a bdrv_close() in the do_eject()->eject_device() call
> >> > path this starts working as expected.
> >> 
> >> Yes, also note that with the -f option eject is capable of purging
> >> any block device. I wonder if libvirt (or any client) relies on this.
> >
> > libvirt will only issue 'eject' on devices which are CDROMs, or Floppy,
> > never hard disks, etc.
> 
> Any use of -f?  Recommend to stay away from it.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=676528

When ejecting CDROM media, there's an option to supply a 'FORCE' flag
to the libvirt API, so media is ejected even if the guest OS has locked
the tray, or is crashed

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] block bug: tray status is not updated (and/or guest ignores it)

[Markus Armbruster]

Amit Shah <amit.shah@redhat.com> writes:

[...]
> What's weird though is 'eject' in the monitor makes the cdrom go away
> -- a subsequent mount in the guest results in a no medium error.  I
> thought we had solved that, Markus?

You fell into QEMU's "let's overload names until everybody's hopelessly
confused" trap.  You're in good company.

Monitor command "eject" does *not* manipulate the tray.  It cuts the
connection between the block device guest part and host part.  Block
devices without a host part look like "no medium" to the guest.

Running /usr/bin/eject does manipulate the tray.  When you open, then
close the tray, you get the same medium back.  IIRC, running mount in
the guest closes the tray automatically.

[...]