Introduce new libvirt API virDomainCreateWithParams that allows to
temporarily boot from another boot device, to use another kernel,
initrd, and cmdline than defined in the persistent domain
definition. All typed parameters are optional.
The design of the API was chosen to ease future extensions.
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Stefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
---
include/libvirt/libvirt-domain.h | 37 +++++++++++++++++++++++
src/driver-hypervisor.h | 6 ++++
src/libvirt-domain.c | 64 ++++++++++++++++++++++++++++++++++++++++
src/libvirt_public.syms | 4 +++
4 files changed, 111 insertions(+)
diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
index 12fd34037e5d..58e4de048a4f 100644
--- a/include/libvirt/libvirt-domain.h
+++ b/include/libvirt/libvirt-domain.h
@@ -1790,6 +1790,43 @@ int virConnectListAllDomains (virConnectPtr conn,
virDomainPtr **domains,
unsigned int flags);
int virDomainCreate (virDomainPtr domain);
+
+/**
+ * VIR_DOMAIN_CREATE_PARM_KERNEL:
+ *
+ * Macro for typed parameter name that represents the used kernel. It
+ * corresponds to the "kernel" node in the XML.
+ */
+# define VIR_DOMAIN_CREATE_PARM_KERNEL "kernel"
+
+/**
+ * VIR_DOMAIN_CREATE_PARM_CMDLINE:
+ *
+ * Macro for typed parameter name that represents the used cmdline. It
+ * corresponds to the "cmdline" node in the XML.
+ */
+# define VIR_DOMAIN_CREATE_PARM_CMDLINE "cmdline"
+
+/**
+ * VIR_DOMAIN_CREATE_PARM_INITRD:
+ *
+ * Macro for typed parameter name that represents the used initial
+ * ramdisk. It corresponds to the "initrd" node in the XML.
+ */
+# define VIR_DOMAIN_CREATE_PARM_INITRD "initrd"
+
+/**
+ * VIR_DOMAIN_CREATE_PARM_DEVICE_IDENTIFIER:
+ *
+ * Macro for typed parameter name that represents the identifier for
+ * the boot device.
+ */
+# define VIR_DOMAIN_CREATE_PARM_DEVICE_IDENTIFIER "bootdevice"
+
+int virDomainCreateWithParams (virDomainPtr domain,
+ virTypedParameterPtr params,
+ int nparams,
+ unsigned int flags);
int virDomainCreateWithFlags (virDomainPtr domain,
unsigned int flags);
diff --git a/src/driver-hypervisor.h b/src/driver-hypervisor.h
index e71a72a44132..2fa9e09e12f6 100644
--- a/src/driver-hypervisor.h
+++ b/src/driver-hypervisor.h
@@ -313,6 +313,11 @@ typedef int
unsigned int nfiles,
int *files,
unsigned int flags);
+typedef int
+(*virDrvDomainCreateWithParams)(virDomainPtr dom,
+ virTypedParameterPtr params,
+ int nparams,
+ unsigned int flags);
typedef virDomainPtr
(*virDrvDomainDefineXML)(virConnectPtr conn,
@@ -1383,6 +1388,7 @@ struct _virHypervisorDriver {
virDrvDomainCreate domainCreate;
virDrvDomainCreateWithFlags domainCreateWithFlags;
virDrvDomainCreateWithFiles domainCreateWithFiles;
+ virDrvDomainCreateWithParams domainCreateWithParams;
virDrvDomainDefineXML domainDefineXML;
virDrvDomainDefineXMLFlags domainDefineXMLFlags;
virDrvDomainUndefine domainUndefine;
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index 2d86e48979d3..36badab2d5d9 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -6682,6 +6682,70 @@ virDomainCreateWithFiles(virDomainPtr domain, unsigned int nfiles,
/**
+ * virDomainCreateWithParams:
+ * @domain: pointer to a defined domain
+ * @params: pointer to boot parameter objects
+ * @nparams: number of boot parameter objects
+ * @flags: bitwise-OR of supported virDomainCreateFlags
+ *
+ * Launch a defined domain. If the call succeeds the domain moves from
+ * the defined to the running domains pools.
+ *
+ * @params provides an array of typed parameters with the length
+ * @nparams. This array will be used to configure the domain to be
+ * temporary started from the device specified by the typed parameter
+ * 'bootdevice'. With the typed parameters 'kernel', 'initrd', and
+ * 'cmdline' it's possible to temporarily override the corresponding
+ * values. All typed parameters are optional.
+ *
+ * For more control over @flags, see virDomainCreateWithFlags().
+ *
+ * Returns 0 in case of success, -1 in case of error
+ */
+int
+virDomainCreateWithParams(virDomainPtr domain,
+ virTypedParameterPtr params,
+ int nparams,
+ unsigned int flags)
+{
+ virConnectPtr conn;
+
+ VIR_DOMAIN_DEBUG(domain, "params=%p, nparams=%d, flags=0x%x",
+ params, nparams, flags);
+ VIR_TYPED_PARAMS_DEBUG(params, nparams);
+
+ virResetLastError();
+
+ virCheckDomainReturn(domain, -1);
+ conn = domain->conn;
+
+ virCheckReadOnlyGoto(conn->flags, error);
+ virCheckNonNegativeArgGoto(nparams, error);
+ if (nparams > 0)
+ virCheckNonNullArgGoto(params, error);
+
+ if (virTypedParameterValidateSet(conn, params, nparams) < 0)
+ goto error;
+
+ if (conn->driver->domainCreateWithParams) {
+ int ret;
+ ret = conn->driver->domainCreateWithParams(domain,
+ params,
+ nparams,
+ flags);
+ if (ret < 0)
+ goto error;
+ return ret;
+ }
+
+ virReportUnsupportedError();
+ error:
+ virDispatchError(domain->conn);
+ return -1;
+}
+
+
+/**
* virDomainGetAutostart:
* @domain: a domain object
* @autostart: the value returned
diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
index 95df3a0dbc7b..5d9b2697702c 100644
--- a/src/libvirt_public.syms
+++ b/src/libvirt_public.syms
@@ -785,4 +785,8 @@ LIBVIRT_4.1.0 {
virStoragePoolLookupByTargetPath;
} LIBVIRT_3.9.0;
+LIBVIRT_4.4.0 {
+ global:
+ virDomainCreateWithParams;
+} LIBVIRT_4.1.0;
# .... define new API here using predicted next version number ....
--
2.13.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, May 09, 2018 at 04:56:12PM +0200, Marc Hartmayer wrote: > Introduce new libvirt API virDomainCreateWithParams that allows to > temporarily boot from another boot device, to use another kernel, > initrd, and cmdline than defined in the persistent domain > definition. All typed parameters are optional. > > The design of the API was chosen to ease future extensions. I don't really see the point in doing this. We already have the ability to temporary boot with a different configuration than is stored in the persistent XML. Just call virDomainCreateXML() passing in the alternative XML doc. This allows changing *any* aspect of the guest configuration, so we're not restricted to just bot device, kernel initrd and cmdline, and thus won't need to write more code anytime someone asks to be able to override something else too. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, May 09, 2018 at 05:40 PM +0200, "Daniel P. Berrangé" <berrange@redhat.com> wrote: > On Wed, May 09, 2018 at 04:56:12PM +0200, Marc Hartmayer wrote: >> Introduce new libvirt API virDomainCreateWithParams that allows to >> temporarily boot from another boot device, to use another kernel, >> initrd, and cmdline than defined in the persistent domain >> definition. All typed parameters are optional. >> >> The design of the API was chosen to ease future extensions. > > I don't really see the point in doing this. We already have the ability > to temporary boot with a different configuration than is stored in > the persistent XML. Just call virDomainCreateXML() passing in the > alternative XML doc. This allows changing *any* aspect of the guest > configuration, so we're not restricted to just bot device, kernel > initrd and cmdline, and thus won't need to write more code anytime > someone asks to be able to override something else too. I know there is the API virDomainCreateXML for creating a transient domain and that it’s possible to temporarily replace parts of the persistent XML with it. But my idea is _not_ to add a functionality to override parts of the persistent XML. My idea is to provide support allowing an easy one-time switch of the boot device in a persistently defined domain. For s390 it’s essential to have an easy way to change the boot configuration since it “knows” only one boot device at a time and it has no support for interactively changing the boot device during the boot/IPL process. I started out with a fixed API (as it was done for example with virDomanCreateWithFiles) but than I liked the approach of providing an more extensible and flexible API better. This is also the reason why I used typed parameters for passing the arguments. This type of API is also not restricted to boot order changes since it could be freely expanded (e.g. passing file descriptors). I can certainly revert back to the static API. > > > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| > -- Beste Grüße / Kind regards Marc Hartmayer IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, May 16, 2018 at 05:30:33PM +0200, Marc Hartmayer wrote: > On Wed, May 09, 2018 at 05:40 PM +0200, "Daniel P. Berrangé" <berrange@redhat.com> wrote: > > On Wed, May 09, 2018 at 04:56:12PM +0200, Marc Hartmayer wrote: > >> Introduce new libvirt API virDomainCreateWithParams that allows to > >> temporarily boot from another boot device, to use another kernel, > >> initrd, and cmdline than defined in the persistent domain > >> definition. All typed parameters are optional. > >> > >> The design of the API was chosen to ease future extensions. > > > > I don't really see the point in doing this. We already have the ability > > to temporary boot with a different configuration than is stored in > > the persistent XML. Just call virDomainCreateXML() passing in the > > alternative XML doc. This allows changing *any* aspect of the guest > > configuration, so we're not restricted to just bot device, kernel > > initrd and cmdline, and thus won't need to write more code anytime > > someone asks to be able to override something else too. > > I know there is the API virDomainCreateXML for creating a transient > domain and that it’s possible to temporarily replace parts of the > persistent XML with it. But my idea is _not_ to add a functionality to > override parts of the persistent XML. My idea is to provide support > allowing an easy one-time switch of the boot device in a persistently > defined domain. For s390 it’s essential to have an easy way to change > the boot configuration since it “knows” only one boot device at a time > and it has no support for interactively changing the boot device during > the boot/IPL process. virDomainCreateXML does not change the persistent XML. If you have an existing persistent guest, and use virDomainCreateXML it lets you start that guest with that customized XML just once, without affecting the persistent XML at all. > I started out with a fixed API (as it was done for example with > virDomanCreateWithFiles) but than I liked the approach of providing an > more extensible and flexible API better. This is also the reason why I > used typed parameters for passing the arguments. This type of API is > also not restricted to boot order changes since it could be freely > expanded (e.g. passing file descriptors). I can certainly revert back to > the static API. Using virDomainCreateXML is the most flexible API because it lets you changed anything in the XML for just that one boot up attempt. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 05/16/2018 05:35 PM, Daniel P. Berrangé wrote: > On Wed, May 16, 2018 at 05:30:33PM +0200, Marc Hartmayer wrote: >> On Wed, May 09, 2018 at 05:40 PM +0200, "Daniel P. Berrangé" <berrange@redhat.com> wrote: >>> On Wed, May 09, 2018 at 04:56:12PM +0200, Marc Hartmayer wrote: >>>> Introduce new libvirt API virDomainCreateWithParams that allows to >>>> temporarily boot from another boot device, to use another kernel, >>>> initrd, and cmdline than defined in the persistent domain >>>> definition. All typed parameters are optional. >>>> >>>> The design of the API was chosen to ease future extensions. >>> >>> I don't really see the point in doing this. We already have the ability >>> to temporary boot with a different configuration than is stored in >>> the persistent XML. Just call virDomainCreateXML() passing in the >>> alternative XML doc. This allows changing *any* aspect of the guest >>> configuration, so we're not restricted to just bot device, kernel >>> initrd and cmdline, and thus won't need to write more code anytime >>> someone asks to be able to override something else too. >> >> I know there is the API virDomainCreateXML for creating a transient >> domain and that it’s possible to temporarily replace parts of the >> persistent XML with it. But my idea is _not_ to add a functionality to >> override parts of the persistent XML. My idea is to provide support >> allowing an easy one-time switch of the boot device in a persistently >> defined domain. For s390 it’s essential to have an easy way to change >> the boot configuration since it “knows” only one boot device at a time >> and it has no support for interactively changing the boot device during >> the boot/IPL process. > > virDomainCreateXML does not change the persistent XML. If you have > an existing persistent guest, and use virDomainCreateXML it lets you > start that guest with that customized XML just once, without affecting > the persistent XML at all. > >> I started out with a fixed API (as it was done for example with >> virDomanCreateWithFiles) but than I liked the approach of providing an >> more extensible and flexible API better. This is also the reason why I >> used typed parameters for passing the arguments. This type of API is >> also not restricted to boot order changes since it could be freely >> expanded (e.g. passing file descriptors). I can certainly revert back to >> the static API. > > Using virDomainCreateXML is the most flexible API because it lets you > changed anything in the XML for just that one boot up attempt. To clarify this: would it be ok for you to implement this feature (the command line parameter to "virsh start") in virsh by doing the xml mangling in the virsh command line tool itself? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, May 16, 2018 at 06:21:40PM +0200, Christian Borntraeger wrote: > > > On 05/16/2018 05:35 PM, Daniel P. Berrangé wrote: > > On Wed, May 16, 2018 at 05:30:33PM +0200, Marc Hartmayer wrote: > >> On Wed, May 09, 2018 at 05:40 PM +0200, "Daniel P. Berrangé" <berrange@redhat.com> wrote: > >>> On Wed, May 09, 2018 at 04:56:12PM +0200, Marc Hartmayer wrote: > >>>> Introduce new libvirt API virDomainCreateWithParams that allows to > >>>> temporarily boot from another boot device, to use another kernel, > >>>> initrd, and cmdline than defined in the persistent domain > >>>> definition. All typed parameters are optional. > >>>> > >>>> The design of the API was chosen to ease future extensions. > >>> > >>> I don't really see the point in doing this. We already have the ability > >>> to temporary boot with a different configuration than is stored in > >>> the persistent XML. Just call virDomainCreateXML() passing in the > >>> alternative XML doc. This allows changing *any* aspect of the guest > >>> configuration, so we're not restricted to just bot device, kernel > >>> initrd and cmdline, and thus won't need to write more code anytime > >>> someone asks to be able to override something else too. > >> > >> I know there is the API virDomainCreateXML for creating a transient > >> domain and that it’s possible to temporarily replace parts of the > >> persistent XML with it. But my idea is _not_ to add a functionality to > >> override parts of the persistent XML. My idea is to provide support > >> allowing an easy one-time switch of the boot device in a persistently > >> defined domain. For s390 it’s essential to have an easy way to change > >> the boot configuration since it “knows” only one boot device at a time > >> and it has no support for interactively changing the boot device during > >> the boot/IPL process. > > > > virDomainCreateXML does not change the persistent XML. If you have > > an existing persistent guest, and use virDomainCreateXML it lets you > > start that guest with that customized XML just once, without affecting > > the persistent XML at all. > > > >> I started out with a fixed API (as it was done for example with > >> virDomanCreateWithFiles) but than I liked the approach of providing an > >> more extensible and flexible API better. This is also the reason why I > >> used typed parameters for passing the arguments. This type of API is > >> also not restricted to boot order changes since it could be freely > >> expanded (e.g. passing file descriptors). I can certainly revert back to > >> the static API. > > > > Using virDomainCreateXML is the most flexible API because it lets you > > changed anything in the XML for just that one boot up attempt. > > To clarify this: > would it be ok for you to implement this feature (the command line parameter > to "virsh start") in virsh by doing the xml mangling in the virsh command line > tool itself? I'm not really a fan of that, as the modifications to virsh are just as non-extensible as the modifications to the API. Each time someone wants another field customizable, we have to add new virsh CLI args and XML munging for them. I could suggest a general arg 'virsh start --edit $GUESTNAME' though, which takes the current persistent XML, launches it in an editor, allowing the user to change the boot order and then starts the guest from this temporary editted XML using virDomainCreateXML. This is a conceptual fit with the 'virsh edit $GUESTNAME' command we already have Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wednesday, 16 May 2018 18:31:26 CEST Daniel P. Berrangé wrote: > On Wed, May 16, 2018 at 06:21:40PM +0200, Christian Borntraeger wrote: > > > > > > On 05/16/2018 05:35 PM, Daniel P. Berrangé wrote: > > > On Wed, May 16, 2018 at 05:30:33PM +0200, Marc Hartmayer wrote: > > >> On Wed, May 09, 2018 at 05:40 PM +0200, "Daniel P. Berrangé" <berrange@redhat.com> wrote: > > >>> On Wed, May 09, 2018 at 04:56:12PM +0200, Marc Hartmayer wrote: > > >>>> Introduce new libvirt API virDomainCreateWithParams that allows to > > >>>> temporarily boot from another boot device, to use another kernel, > > >>>> initrd, and cmdline than defined in the persistent domain > > >>>> definition. All typed parameters are optional. > > >>>> > > >>>> The design of the API was chosen to ease future extensions. > > >>> > > >>> I don't really see the point in doing this. We already have the ability > > >>> to temporary boot with a different configuration than is stored in > > >>> the persistent XML. Just call virDomainCreateXML() passing in the > > >>> alternative XML doc. This allows changing *any* aspect of the guest > > >>> configuration, so we're not restricted to just bot device, kernel > > >>> initrd and cmdline, and thus won't need to write more code anytime > > >>> someone asks to be able to override something else too. > > >> > > >> I know there is the API virDomainCreateXML for creating a transient > > >> domain and that it’s possible to temporarily replace parts of the > > >> persistent XML with it. But my idea is _not_ to add a functionality to > > >> override parts of the persistent XML. My idea is to provide support > > >> allowing an easy one-time switch of the boot device in a persistently > > >> defined domain. For s390 it’s essential to have an easy way to change > > >> the boot configuration since it “knows” only one boot device at a time > > >> and it has no support for interactively changing the boot device during > > >> the boot/IPL process. > > > > > > virDomainCreateXML does not change the persistent XML. If you have > > > an existing persistent guest, and use virDomainCreateXML it lets you > > > start that guest with that customized XML just once, without affecting > > > the persistent XML at all. > > > > > >> I started out with a fixed API (as it was done for example with > > >> virDomanCreateWithFiles) but than I liked the approach of providing an > > >> more extensible and flexible API better. This is also the reason why I > > >> used typed parameters for passing the arguments. This type of API is > > >> also not restricted to boot order changes since it could be freely > > >> expanded (e.g. passing file descriptors). I can certainly revert back to > > >> the static API. > > > > > > Using virDomainCreateXML is the most flexible API because it lets you > > > changed anything in the XML for just that one boot up attempt. > > > > To clarify this: > > would it be ok for you to implement this feature (the command line parameter > > to "virsh start") in virsh by doing the xml mangling in the virsh command line > > tool itself? > > I'm not really a fan of that, as the modifications to virsh are just as > non-extensible as the modifications to the API. Each time someone wants > another field customizable, we have to add new virsh CLI args and XML > munging for them. > > I could suggest a general arg 'virsh start --edit $GUESTNAME' though, > which takes the current persistent XML, launches it in an editor, > allowing the user to change the boot order and then starts the guest > from this temporary editted XML using virDomainCreateXML. This is a > conceptual fit with the 'virsh edit $GUESTNAME' command we already > have Another option could be instead to implement this "temporarly change & start" to another tool, that already does XML munging: virt-xml. In that context, adding options to edit the various bits makes sense, so only the "edit -> start -> revert" thing would be needed there. WDYT? -- Pino Toscano-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Jun 06, 2018 at 02:53 PM +0200, Pino Toscano <ptoscano@redhat.com> wrote: > On Wednesday, 16 May 2018 18:31:26 CEST Daniel P. Berrangé wrote: >> On Wed, May 16, 2018 at 06:21:40PM +0200, Christian Borntraeger wrote: >> > >> > >> > On 05/16/2018 05:35 PM, Daniel P. Berrangé wrote: […snip…] >> I could suggest a general arg 'virsh start --edit $GUESTNAME' though, >> which takes the current persistent XML, launches it in an editor, >> allowing the user to change the boot order and then starts the guest >> from this temporary editted XML using virDomainCreateXML. This is a >> conceptual fit with the 'virsh edit $GUESTNAME' command we already >> have > > Another option could be instead to implement this "temporarly change & > start" to another tool, that already does XML munging: virt-xml. > In that context, adding options to edit the various bits makes sense, > so only the "edit -> start -> revert" thing would be needed there. > > WDYT? Wouldn’t be a (new) tool 'virt-start' better for that since virt-xml does only the XML manipulation? Thanks for thinking about it. > -- > Pino Toscano -- Beste Grüße / Kind regards Marc Hartmayer IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.