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
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
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
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
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
-
Cole Robinson -
Daniel P. Berrange -
Matthew Booth