qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] monitor: allow device to be ejected if no disk


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH] monitor: allow device to be ejected if no disk is inserted
Date: Mon, 7 Jun 2010 09:43:45 -0300
User-agent: Mutt/1.5.19 (2009-01-05)

On Mon, Jun 07, 2010 at 02:19:28PM +0200, Markus Armbruster wrote:
> Kevin Wolf <address@hidden> writes:
> > Am 02.06.2010 00:12, schrieb Eduardo Habkost:
> >> The first eject command didn't work because the is_inserted() check
> >> failed.
> >
> > But does it really make a difference? The guest should not see a medium
> > before and it should not see one afterwards.

It does, as the whole purpose of the "eject" command is to disconnect
the block device from the host backing file.

Awful naming, I agree, but that's the expected semantics of the command.


> > The question is what the semantics of the eject monitor command is
> > supposed to be. I for one would have expected that it means that if
> > there was a medium inserted in the virtual CD-ROM drive, it won't be
> > there afterwards. I wouldn't have expected the connection to the host
> > device to be affected.
> 
> But that's what it does: remove the media from the block device host
> part, leaving the device empty.

Exactly. For example, this is how libvirt handles changes to disk
configuration:

    if (disk->src) {
        /* [...] */
        ret = qemuMonitorChangeMedia(priv->mon,
                                     driveAlias,
                                     disk->src, format);
    } else {
        ret = qemuMonitorEjectMedia(priv->mon, driveAlias);
    }

There are existing users of the "eject" command that expect this
semantics, as it is the only available way to disconnect a block device.

If we want to solve the naming confusion, this could be implemented as a
special case of the "change" command instead, and then the "eject"
command could be deprecated.

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]