4:47 a.m.
What does the eject (to eject a CD) command do to a KVM guest? It
succeeds, and the result is that the device can no longer be mounted.
However, looking at the domain XML reveals it hasn't disconnected the
backing file.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
8:35 a.m.
On 10/19/2009 05:47 AM, Matthew Booth wrote:
What does the eject (to eject a CD) command do to a KVM guest? It
succeeds, and the result is that the device can no longer be mounted.
However, looking at the domain XML reveals it hasn't disconnected the
backing file.
Matt
It should be the equivalent of ejecting a CD or floppy on a physical
machine.
If you do this through libvirt (with the attach-device command and
suitable XML string), then the change should be reflected in the XML.
If you managed to send a monitor command to the KVM guest that didn't go
through libvirt, the change wouldn't be reflected in the domain XML for
the majority of operations (media eject included).
- Cole
8:38 a.m.
On Mon, Oct 19, 2009 at 09:35:04AM -0400, Cole Robinson wrote:
On 10/19/2009 05:47 AM, Matthew Booth wrote:
> What does the eject (to eject a CD) command do to a KVM guest? It
> succeeds, and the result is that the device can no longer be mounted.
> However, looking at the domain XML reveals it hasn't disconnected the
> backing file.
>
> Matt
It should be the equivalent of ejecting a CD or floppy on a physical
machine.
If you do this through libvirt (with the attach-device command and
suitable XML string), then the change should be reflected in the XML.
If you managed to send a monitor command to the KVM guest that didn't go
through libvirt, the change wouldn't be reflected in the domain XML for
the majority of operations (media eject included).
I think the problem Matt sees is from running 'eject' inside the guest.
libvirt will not see that, because KVM has no way to notify us that the
guest ejected the media.
Fortunately, the new KVM monitor control protocol includes support for
this notification, so we'll be able to address this limitation in the
future.
Daniel
--
|: Red Hat, Engineering, London -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 :|
8:49 a.m.
On 19/10/09 14:38, Daniel P. Berrange wrote:
On Mon, Oct 19, 2009 at 09:35:04AM -0400, Cole Robinson wrote:
> On 10/19/2009 05:47 AM, Matthew Booth wrote:
>> What does the eject (to eject a CD) command do to a KVM guest? It
>> succeeds, and the result is that the device can no longer be mounted.
>> However, looking at the domain XML reveals it hasn't disconnected the
>> backing file.
>>
>> Matt
>
> It should be the equivalent of ejecting a CD or floppy on a physical
> machine.
>
> If you do this through libvirt (with the attach-device command and
> suitable XML string), then the change should be reflected in the XML.
>
> If you managed to send a monitor command to the KVM guest that didn't go
> through libvirt, the change wouldn't be reflected in the domain XML for
> the majority of operations (media eject included).
I think the problem Matt sees is from running 'eject' inside the guest.
libvirt will not see that, because KVM has no way to notify us that the
guest ejected the media.
That's it. Re-reading, that wasn't clear from my original question.
Fortunately, the new KVM monitor control protocol includes support
for
this notification, so we'll be able to address this limitation in the
future.
Sounds good. Any idea what the timeframe might be for that?
To put this in context, I was trying to think of an existing way a guest
can modify its environment. I was thinking that if you configured a boot
order of cdrom, hd, and attached a custom LiveCD, the LiveCD could do
its thing and then eject itself, booting from hd next time with no
administrative intervention. Could that ever work?
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
8:51 a.m.
On Mon, Oct 19, 2009 at 02:49:52PM +0100, Matthew Booth wrote:
On 19/10/09 14:38, Daniel P. Berrange wrote:
>On Mon, Oct 19, 2009 at 09:35:04AM -0400, Cole Robinson wrote:
>>On 10/19/2009 05:47 AM, Matthew Booth wrote:
>>>What does the eject (to eject a CD) command do to a KVM guest? It
>>>succeeds, and the result is that the device can no longer be mounted.
>>>However, looking at the domain XML reveals it hasn't disconnected the
>>>backing file.
>>>
>>>Matt
>>
>>It should be the equivalent of ejecting a CD or floppy on a physical
>>machine.
>>
>>If you do this through libvirt (with the attach-device command and
>>suitable XML string), then the change should be reflected in the XML.
>>
>>If you managed to send a monitor command to the KVM guest that didn't go
>>through libvirt, the change wouldn't be reflected in the domain XML for
>>the majority of operations (media eject included).
>
>I think the problem Matt sees is from running 'eject' inside the guest.
>libvirt will not see that, because KVM has no way to notify us that the
>guest ejected the media.
That's it. Re-reading, that wasn't clear from my original question.
>Fortunately, the new KVM monitor control protocol includes support for
>this notification, so we'll be able to address this limitation in the
>future.
Sounds good. Any idea what the timeframe might be for that?
When QEMU developers agree on the implementation of the new protocol...
To put this in context, I was trying to think of an existing way a guest
can modify its environment. I was thinking that if you configured a boot
order of cdrom, hd, and attached a custom LiveCD, the LiveCD could do
its thing and then eject itself, booting from hd next time with no
administrative intervention. Could that ever work?
Yes, that kind of thing is supposed to work.
Daniel
--
|: Red Hat, Engineering, London -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 :|
5329
days inactive
5329
days old
4 comments
3 participants
participants (3)
-
Cole Robinson -
Daniel P. Berrange -
Matthew Booth