3:06 p.m.
When a user runs 'virsh detach-disk' on a running domain, the disk is
removed, but reappears after the domain is rebooted. This seems odd, as
someone who types detach-disk most likely wants the change to be permanent.
This patch updates the code in xenDaemonDetachDevice() to pass the
rm_cfg flag to Xen, so that the change is committed to the domain's
configuration file.
This change depends on a xen patch that was committed to unstable on
March 20:
http://lists.xensource.com/archives/html/xen-changelog/2008-03/msg00122.html
-Ryan
diff --git a/src/xend_internal.c b/src/xend_internal.c
--- a/src/xend_internal.c
+++ b/src/xend_internal.c
@@ -3347,7 +3347,7 @@ xenDaemonDetachDevice(virDomainPtr domai
if (virDomainXMLDevID(domain, xml, class, ref, sizeof(ref)))
return (-1);
return(xend_op(domain->conn, domain->name, "op",
"device_destroy",
- "type", class, "dev", ref, NULL));
+ "type", class, "dev", ref, "force", "0",
"rm_cfg", "1", NULL));
}
2:08 a.m.
On Tue, Apr 08, 2008 at 01:06:12PM -0700, Ryan Scott wrote:
When a user runs 'virsh detach-disk' on a running domain, the disk is
removed, but reappears after the domain is rebooted. This seems odd, as
someone who types detach-disk most likely wants the change to be permanent.
This patch updates the code in xenDaemonDetachDevice() to pass the
rm_cfg flag to Xen, so that the change is committed to the domain's
configuration file.
This change depends on a xen patch that was committed to unstable on
March 20:
http://lists.xensource.com/archives/html/xen-changelog/2008-03/msg00122.html
but what happens if the flag is passed down while the xend version doesn't
support it ? if this breaks we need to check first that the remote support
it (based on a version change at some point), isn't it ?
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
1:08 p.m.
Daniel Veillard wrote:
On Tue, Apr 08, 2008 at 01:06:12PM -0700, Ryan Scott wrote:
> When a user runs 'virsh detach-disk' on a running domain, the disk is
> removed, but reappears after the domain is rebooted. This seems odd, as
> someone who types detach-disk most likely wants the change to be permanent.
>
> This patch updates the code in xenDaemonDetachDevice() to pass the
> rm_cfg flag to Xen, so that the change is committed to the domain's
> configuration file.
>
> This change depends on a xen patch that was committed to unstable on
> March 20:
> http://lists.xensource.com/archives/html/xen-changelog/2008-03/msg00122.html
but what happens if the flag is passed down while the xend version doesn't
support it ? if this breaks we need to check first that the remote support
it (based on a version change at some point), isn't it ?
In my tests, if you used a new libvirt with an old xen (i.e. passing the
flag when it wasn't expected), the flag was ignored. I didn't test all
configurations, but I don't think a version check is necessary.
The problems occurred when you used a new xen with old libvirt. Xen
would refuse the call if all the flags were not provided.
-Ryan
Daniel
5:52 a.m.
On Tue, Apr 08, 2008 at 01:06:12PM -0700, Ryan Scott wrote:
When a user runs 'virsh detach-disk' on a running domain, the
disk is
removed, but reappears after the domain is rebooted. This seems odd, as
someone who types detach-disk most likely wants the change to be permanent.
Actually I wonder what the expectation is.
The QEMU driver only implements a very limited form of the
virDomainAttachDevice call (merely allowing you to signal that the
CD-ROM has been replaced) and doesn't implement virDomainDetachDevice
at all, so there is no example to go on there.
Maybe better to document what the behaviour is supposed to be in
src/libvirt.c? After all you can effect a permanent change to the
device configuration by using virDomainDefineXML.
Just my 0.02$
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
6:59 a.m.
On Wed, Apr 09, 2008 at 11:52:07AM +0100, Richard W.M. Jones wrote:
On Tue, Apr 08, 2008 at 01:06:12PM -0700, Ryan Scott wrote:
> When a user runs 'virsh detach-disk' on a running domain, the disk is
> removed, but reappears after the domain is rebooted. This seems odd, as
> someone who types detach-disk most likely wants the change to be permanent.
Actually I wonder what the expectation is.
The QEMU driver only implements a very limited form of the
virDomainAttachDevice call (merely allowing you to signal that the
CD-ROM has been replaced) and doesn't implement virDomainDetachDevice
at all, so there is no example to go on there.
Maybe better to document what the behaviour is supposed to be in
src/libvirt.c? After all you can effect a permanent change to the
device configuration by using virDomainDefineXML.
Please think of the poor user. Dumping the XML, editing it by hand, and
feeding it back in barely a user interface at all. virsh detach-disk is.
(And yes, I would expect detach-disk to do exactly that, permanently.)
regards
john
6:38 a.m.
On Wed, Apr 09, 2008 at 12:59:38PM +0100, John Levon wrote:
On Wed, Apr 09, 2008 at 11:52:07AM +0100, Richard W.M. Jones wrote:
> On Tue, Apr 08, 2008 at 01:06:12PM -0700, Ryan Scott wrote:
> > When a user runs 'virsh detach-disk' on a running domain, the disk is
> > removed, but reappears after the domain is rebooted. This seems odd, as
> > someone who types detach-disk most likely wants the change to be permanent.
>
> Actually I wonder what the expectation is.
>
> The QEMU driver only implements a very limited form of the
> virDomainAttachDevice call (merely allowing you to signal that the
> CD-ROM has been replaced) and doesn't implement virDomainDetachDevice
> at all, so there is no example to go on there.
>
> Maybe better to document what the behaviour is supposed to be in
> src/libvirt.c? After all you can effect a permanent change to the
> device configuration by using virDomainDefineXML.
Please think of the poor user. Dumping the XML, editing it by hand, and
feeding it back in barely a user interface at all. virsh detach-disk is.
(And yes, I would expect detach-disk to do exactly that, permanently.)
I think what's most confusing to the 'poor user' is the inconsistency
of behaviour. For example if you were to run that command while the
domain is not running, it would detach the device in the configuration
file. The fact that the command behaves differently depending on the
current state of the domain is what sounds fundemantally wrong to me
from an user perspective.
This is also one more example why it makes sense to add flags to new
operations because in the end both behaviour have their own logic, for
example the diffence between (un)mounting a temporary device used while
running a domain (say an application install CD-Rom) versus a more
persistent data volume. In the end we may want to separate the logic
without adding more entry points and an operation flag would have been
ideal for this, unfortunately virDomainAttachDevice/virDomainDetachDevice
don't have one, too bad.
In that specific case of umounting a device, I think it's reasonable to
make the operation permanent, as that's the behaviour when the domain is
not running, but it's not an ideal situation.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6070
days inactive
6072
days old
5 comments
4 participants
participants (4)
-
Daniel Veillard -
John Levon -
Richard W.M. Jones -
Ryan Scott