External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-11-08 14:29:56 +00:00
Code Issues Packages Projects Releases Wiki Activity
c646eb46dd
libvirt/docs/schemas/domainbackup.rng

301 lines
8.7 KiB
Plaintext
Raw Normal View History

backup: Document new XML for backups Prepare for new backup APIs by describing the XML that will represent a backup. The XML resembles snapshots and checkpoints in being able to select actions for a set of disks, but has other differences. It can support both push model (the hypervisor does the backup directly into the destination file) and pull model (the hypervisor exposes an access port for a third party to grab what is necessary). Add testsuite coverage for some minimal uses of the XML. The <disk> element within <domainbackup> tries to model the same elements as a <disk> under <domain>, but sharing the RNG grammar proved to be hairy. That is in part because while <domain> use <source> to describe a host resource in use by the guest, a backup job is using a host resource that is not visible to the guest: a push backup action is instead describing a <target> (which ultimately could be a remote network resource, but for simplicity the RNG just validates a local file for now), and a pull backup action is instead describing a temporary local file <scratch> (which probably should not be a remote resource). A future refactoring may thus introduce some way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-08-22 01:42:41 +00:00
<?xml version="1.0"?>
<!-- A Relax NG schema for the libvirt domain backup properties XML format -->
<grammar xmlns="http://relaxng.org/ns/structure/1.0">
<start>
<ref name='domainbackup'/>
</start>
<include href='domaincommon.rng'/>
backup: Allow 'encryption' of backups and scratch images Add the appropriate entries into the schema to allow encryption of the backup or scratch image. Since we use blockdev internals for everything no changes to the code are actually necessary. https://bugzilla.redhat.com/show_bug.cgi?id=1811906 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-04-09 13:50:40 +00:00
<define name='backupEncryption'>
<element name='encryption'>
<attribute name='format'>
<choice>
<value>luks</value>
</choice>
</attribute>
<interleave>
<ref name='secret'/>
<optional>
<element name='cipher'>
<ref name='keycipher'/>
</element>
<element name='ivgen'>
<ref name='keyivgen'/>
</element>
</optional>
</interleave>
</element>
</define>
backup: Document new XML for backups Prepare for new backup APIs by describing the XML that will represent a backup. The XML resembles snapshots and checkpoints in being able to select actions for a set of disks, but has other differences. It can support both push model (the hypervisor does the backup directly into the destination file) and pull model (the hypervisor exposes an access port for a third party to grab what is necessary). Add testsuite coverage for some minimal uses of the XML. The <disk> element within <domainbackup> tries to model the same elements as a <disk> under <domain>, but sharing the RNG grammar proved to be hairy. That is in part because while <domain> use <source> to describe a host resource in use by the guest, a backup job is using a host resource that is not visible to the guest: a push backup action is instead describing a <target> (which ultimately could be a remote network resource, but for simplicity the RNG just validates a local file for now), and a pull backup action is instead describing a temporary local file <scratch> (which probably should not be a remote resource). A future refactoring may thus introduce some way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-08-22 01:42:41 +00:00
<define name='domainbackup'>
<element name='domainbackup'>
<interleave>
<optional>
<element name='incremental'>
<text/>
</element>
</optional>
<choice>
<group>
<optional>
<attribute name='mode'>
<value>push</value>
</attribute>
</optional>
<ref name='backupDisksPush'/>
</group>
<group>
<attribute name='mode'>
<value>pull</value>
</attribute>
<interleave>
<element name='server'>
conf: backup: Add 'tls' attribute for 'server' element Allow enabling TLS for the NBD server used to do pull-mode backups. Note that documentation already mentions 'tls', so this just implements the schema and XML bits. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2020-07-01 10:25:42 +00:00
<optional>
<attribute name='tls'>
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</optional>
backup: Document new XML for backups Prepare for new backup APIs by describing the XML that will represent a backup. The XML resembles snapshots and checkpoints in being able to select actions for a set of disks, but has other differences. It can support both push model (the hypervisor does the backup directly into the destination file) and pull model (the hypervisor exposes an access port for a third party to grab what is necessary). Add testsuite coverage for some minimal uses of the XML. The <disk> element within <domainbackup> tries to model the same elements as a <disk> under <domain>, but sharing the RNG grammar proved to be hairy. That is in part because while <domain> use <source> to describe a host resource in use by the guest, a backup job is using a host resource that is not visible to the guest: a push backup action is instead describing a <target> (which ultimately could be a remote network resource, but for simplicity the RNG just validates a local file for now), and a pull backup action is instead describing a temporary local file <scratch> (which probably should not be a remote resource). A future refactoring may thus introduce some way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-08-22 01:42:41 +00:00
<choice>
<group>
<optional>
<attribute name='transport'>
<value>tcp</value>
</attribute>
</optional>
<attribute name='name'>
<choice>
<ref name='dnsName'/>
<ref name='ipAddr'/>
</choice>
</attribute>
<optional>
<attribute name='port'>
<ref name='unsignedInt'/>
</attribute>
</optional>
</group>
<group>
<attribute name='transport'>
<value>unix</value>
</attribute>
<attribute name='socket'>
<ref name='absFilePath'/>
</attribute>
</group>
</choice>
</element>
<ref name='backupDisksPull'/>
</interleave>
</group>
</choice>
</interleave>
</element>
</define>
backup: Allow configuring incremental backup per-disk individually The semantics of the backup operation don't strictly require that all disks being backed up are part of the same incremental part (when a disk was checkpointed/backed up separately or in a different VM), or even they may not have a previous checkpoint at all (e.g. when the disk was freshly hotplugged to the vm). In such cases we can still create a common checkpoint for all of them and backup differences according to configuration. This patch adds a per-disk configuration of the checkpoint to do the incremental backup from via the 'incremental' attribute and allows perform full backups via the 'backupmode' attribute. Note that no changes to the qemu driver are necessary to take advantage of this as we already obey the per-disk 'incremental' field. https://bugzilla.redhat.com/show_bug.cgi?id=1829829 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2020-06-25 14:16:14 +00:00
<define name='backupDiskMode'>
<optional>
<choice>
<attribute name='backupmode'>
<value>full</value>
</attribute>
<group>
<optional>
<attribute name='backupmode'>
<value>incremental</value>
</attribute>
</optional>
<optional>
<attribute name='incremental'/>
</optional>
</group>
</choice>
</optional>
</define>
backup: Document new XML for backups Prepare for new backup APIs by describing the XML that will represent a backup. The XML resembles snapshots and checkpoints in being able to select actions for a set of disks, but has other differences. It can support both push model (the hypervisor does the backup directly into the destination file) and pull model (the hypervisor exposes an access port for a third party to grab what is necessary). Add testsuite coverage for some minimal uses of the XML. The <disk> element within <domainbackup> tries to model the same elements as a <disk> under <domain>, but sharing the RNG grammar proved to be hairy. That is in part because while <domain> use <source> to describe a host resource in use by the guest, a backup job is using a host resource that is not visible to the guest: a push backup action is instead describing a <target> (which ultimately could be a remote network resource, but for simplicity the RNG just validates a local file for now), and a pull backup action is instead describing a temporary local file <scratch> (which probably should not be a remote resource). A future refactoring may thus introduce some way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-08-22 01:42:41 +00:00
<define name='backupPushDriver'>
<optional>
<element name='driver'>
<attribute name='type'>
<ref name='storageFormat'/>
</attribute>
</element>
</optional>
</define>
<define name='backupPullDriver'>
<optional>
<element name='driver'>
<attribute name='type'>
<value>qcow2</value>
</attribute>
</element>
</optional>
</define>
<define name='backupAttr'>
<optional>
<attribute name='backup'>
<choice>
<value>yes</value>
</choice>
</attribute>
</optional>
</define>
<define name='backupDisksPush'>
<optional>
<element name='disks'>
<oneOrMore>
<element name='disk'>
<attribute name='name'>
schemas: backup: Remove pointless <choice> for 'name' of backup disk One of the first versions thought of using disk path as the second option but this was dropped as being a legacy interface. Remove the leftover pointless <choice> wrapper for the disk name as there's just one option now. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-20 10:27:37 +00:00
<ref name='diskTarget'/>
backup: Document new XML for backups Prepare for new backup APIs by describing the XML that will represent a backup. The XML resembles snapshots and checkpoints in being able to select actions for a set of disks, but has other differences. It can support both push model (the hypervisor does the backup directly into the destination file) and pull model (the hypervisor exposes an access port for a third party to grab what is necessary). Add testsuite coverage for some minimal uses of the XML. The <disk> element within <domainbackup> tries to model the same elements as a <disk> under <domain>, but sharing the RNG grammar proved to be hairy. That is in part because while <domain> use <source> to describe a host resource in use by the guest, a backup job is using a host resource that is not visible to the guest: a push backup action is instead describing a <target> (which ultimately could be a remote network resource, but for simplicity the RNG just validates a local file for now), and a pull backup action is instead describing a temporary local file <scratch> (which probably should not be a remote resource). A future refactoring may thus introduce some way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-08-22 01:42:41 +00:00
</attribute>
backup: Allow configuring incremental backup per-disk individually The semantics of the backup operation don't strictly require that all disks being backed up are part of the same incremental part (when a disk was checkpointed/backed up separately or in a different VM), or even they may not have a previous checkpoint at all (e.g. when the disk was freshly hotplugged to the vm). In such cases we can still create a common checkpoint for all of them and backup differences according to configuration. This patch adds a per-disk configuration of the checkpoint to do the incremental backup from via the 'incremental' attribute and allows perform full backups via the 'backupmode' attribute. Note that no changes to the qemu driver are necessary to take advantage of this as we already obey the per-disk 'incremental' field. https://bugzilla.redhat.com/show_bug.cgi?id=1829829 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2020-06-25 14:16:14 +00:00
<ref name='backupDiskMode'/>
backup: Document new XML for backups Prepare for new backup APIs by describing the XML that will represent a backup. The XML resembles snapshots and checkpoints in being able to select actions for a set of disks, but has other differences. It can support both push model (the hypervisor does the backup directly into the destination file) and pull model (the hypervisor exposes an access port for a third party to grab what is necessary). Add testsuite coverage for some minimal uses of the XML. The <disk> element within <domainbackup> tries to model the same elements as a <disk> under <domain>, but sharing the RNG grammar proved to be hairy. That is in part because while <domain> use <source> to describe a host resource in use by the guest, a backup job is using a host resource that is not visible to the guest: a push backup action is instead describing a <target> (which ultimately could be a remote network resource, but for simplicity the RNG just validates a local file for now), and a pull backup action is instead describing a temporary local file <scratch> (which probably should not be a remote resource). A future refactoring may thus introduce some way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-08-22 01:42:41 +00:00
<choice>
<group>
<attribute name='backup'>
<value>no</value>
</attribute>
</group>
<group>
<ref name='backupAttr'/>
<attribute name='type'>
<value>file</value>
</attribute>
<interleave>
<optional>
<element name='target'>
<attribute name='file'>
<ref name='absFilePath'/>
</attribute>
backup: Allow 'encryption' of backups and scratch images Add the appropriate entries into the schema to allow encryption of the backup or scratch image. Since we use blockdev internals for everything no changes to the code are actually necessary. https://bugzilla.redhat.com/show_bug.cgi?id=1811906 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-04-09 13:50:40 +00:00
<interleave>
<zeroOrMore>
<ref name='devSeclabel'/>
</zeroOrMore>
<optional>
<ref name='backupEncryption'/>
</optional>
</interleave>
backup: Document new XML for backups Prepare for new backup APIs by describing the XML that will represent a backup. The XML resembles snapshots and checkpoints in being able to select actions for a set of disks, but has other differences. It can support both push model (the hypervisor does the backup directly into the destination file) and pull model (the hypervisor exposes an access port for a third party to grab what is necessary). Add testsuite coverage for some minimal uses of the XML. The <disk> element within <domainbackup> tries to model the same elements as a <disk> under <domain>, but sharing the RNG grammar proved to be hairy. That is in part because while <domain> use <source> to describe a host resource in use by the guest, a backup job is using a host resource that is not visible to the guest: a push backup action is instead describing a <target> (which ultimately could be a remote network resource, but for simplicity the RNG just validates a local file for now), and a pull backup action is instead describing a temporary local file <scratch> (which probably should not be a remote resource). A future refactoring may thus introduce some way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-08-22 01:42:41 +00:00
</element>
</optional>
<ref name='backupPushDriver'/>
</interleave>
</group>
<group>
<ref name='backupAttr'/>
<attribute name='type'>
<value>block</value>
</attribute>
<interleave>
<optional>
<element name='target'>
<attribute name='dev'>
<ref name='absFilePath'/>
</attribute>
backup: Allow 'encryption' of backups and scratch images Add the appropriate entries into the schema to allow encryption of the backup or scratch image. Since we use blockdev internals for everything no changes to the code are actually necessary. https://bugzilla.redhat.com/show_bug.cgi?id=1811906 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-04-09 13:50:40 +00:00
<interleave>
<zeroOrMore>
<ref name='devSeclabel'/>
</zeroOrMore>
<optional>
<ref name='backupEncryption'/>
</optional>
</interleave>
backup: Document new XML for backups Prepare for new backup APIs by describing the XML that will represent a backup. The XML resembles snapshots and checkpoints in being able to select actions for a set of disks, but has other differences. It can support both push model (the hypervisor does the backup directly into the destination file) and pull model (the hypervisor exposes an access port for a third party to grab what is necessary). Add testsuite coverage for some minimal uses of the XML. The <disk> element within <domainbackup> tries to model the same elements as a <disk> under <domain>, but sharing the RNG grammar proved to be hairy. That is in part because while <domain> use <source> to describe a host resource in use by the guest, a backup job is using a host resource that is not visible to the guest: a push backup action is instead describing a <target> (which ultimately could be a remote network resource, but for simplicity the RNG just validates a local file for now), and a pull backup action is instead describing a temporary local file <scratch> (which probably should not be a remote resource). A future refactoring may thus introduce some way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-08-22 01:42:41 +00:00
</element>
</optional>
<ref name='backupPushDriver'/>
</interleave>
</group>
</choice>
</element>
</oneOrMore>
</element>
</optional>
</define>
<define name='backupDisksPull'>
<optional>
<element name='disks'>
<oneOrMore>
<element name='disk'>
<attribute name='name'>
schemas: backup: Remove pointless <choice> for 'name' of backup disk One of the first versions thought of using disk path as the second option but this was dropped as being a legacy interface. Remove the leftover pointless <choice> wrapper for the disk name as there's just one option now. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-20 10:27:37 +00:00
<ref name='diskTarget'/>
backup: Document new XML for backups Prepare for new backup APIs by describing the XML that will represent a backup. The XML resembles snapshots and checkpoints in being able to select actions for a set of disks, but has other differences. It can support both push model (the hypervisor does the backup directly into the destination file) and pull model (the hypervisor exposes an access port for a third party to grab what is necessary). Add testsuite coverage for some minimal uses of the XML. The <disk> element within <domainbackup> tries to model the same elements as a <disk> under <domain>, but sharing the RNG grammar proved to be hairy. That is in part because while <domain> use <source> to describe a host resource in use by the guest, a backup job is using a host resource that is not visible to the guest: a push backup action is instead describing a <target> (which ultimately could be a remote network resource, but for simplicity the RNG just validates a local file for now), and a pull backup action is instead describing a temporary local file <scratch> (which probably should not be a remote resource). A future refactoring may thus introduce some way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-08-22 01:42:41 +00:00
</attribute>
backup: Allow configuring incremental backup per-disk individually The semantics of the backup operation don't strictly require that all disks being backed up are part of the same incremental part (when a disk was checkpointed/backed up separately or in a different VM), or even they may not have a previous checkpoint at all (e.g. when the disk was freshly hotplugged to the vm). In such cases we can still create a common checkpoint for all of them and backup differences according to configuration. This patch adds a per-disk configuration of the checkpoint to do the incremental backup from via the 'incremental' attribute and allows perform full backups via the 'backupmode' attribute. Note that no changes to the qemu driver are necessary to take advantage of this as we already obey the per-disk 'incremental' field. https://bugzilla.redhat.com/show_bug.cgi?id=1829829 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2020-06-25 14:16:14 +00:00
<ref name='backupDiskMode'/>
conf: backup: Allow configuration of names exported via NBD If users wish to use different name for exported disks or bitmaps the new fields allow to do so. Additionally they also document the current settings. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2019-12-20 10:37:40 +00:00
<optional>
<attribute name='exportname'>
<text/>
</attribute>
schema: backup: Make 'exportname' and 'exportbitmap' independent Both are optional but don't have to be specified together. Fix the schema. https://bugzilla.redhat.com/show_bug.cgi?id=1826746 Suggested-by: Yi Sun <yisun@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2020-04-24 08:37:54 +00:00
</optional>
<optional>
conf: backup: Allow configuration of names exported via NBD If users wish to use different name for exported disks or bitmaps the new fields allow to do so. Additionally they also document the current settings. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2019-12-20 10:37:40 +00:00
<attribute name='exportbitmap'>
<text/>
</attribute>
</optional>
backup: Document new XML for backups Prepare for new backup APIs by describing the XML that will represent a backup. The XML resembles snapshots and checkpoints in being able to select actions for a set of disks, but has other differences. It can support both push model (the hypervisor does the backup directly into the destination file) and pull model (the hypervisor exposes an access port for a third party to grab what is necessary). Add testsuite coverage for some minimal uses of the XML. The <disk> element within <domainbackup> tries to model the same elements as a <disk> under <domain>, but sharing the RNG grammar proved to be hairy. That is in part because while <domain> use <source> to describe a host resource in use by the guest, a backup job is using a host resource that is not visible to the guest: a push backup action is instead describing a <target> (which ultimately could be a remote network resource, but for simplicity the RNG just validates a local file for now), and a pull backup action is instead describing a temporary local file <scratch> (which probably should not be a remote resource). A future refactoring may thus introduce some way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-08-22 01:42:41 +00:00
<choice>
<group>
<attribute name='backup'>
<value>no</value>
</attribute>
</group>
<group>
<optional>
<ref name='backupAttr'/>
<attribute name='type'>
<value>file</value>
</attribute>
</optional>
<optional>
<interleave>
<element name='scratch'>
<attribute name='file'>
<ref name='absFilePath'/>
</attribute>
backup: Allow 'encryption' of backups and scratch images Add the appropriate entries into the schema to allow encryption of the backup or scratch image. Since we use blockdev internals for everything no changes to the code are actually necessary. https://bugzilla.redhat.com/show_bug.cgi?id=1811906 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-04-09 13:50:40 +00:00
<interleave>
<zeroOrMore>
<ref name='devSeclabel'/>
</zeroOrMore>
<optional>
<ref name='backupEncryption'/>
</optional>
</interleave>
backup: Document new XML for backups Prepare for new backup APIs by describing the XML that will represent a backup. The XML resembles snapshots and checkpoints in being able to select actions for a set of disks, but has other differences. It can support both push model (the hypervisor does the backup directly into the destination file) and pull model (the hypervisor exposes an access port for a third party to grab what is necessary). Add testsuite coverage for some minimal uses of the XML. The <disk> element within <domainbackup> tries to model the same elements as a <disk> under <domain>, but sharing the RNG grammar proved to be hairy. That is in part because while <domain> use <source> to describe a host resource in use by the guest, a backup job is using a host resource that is not visible to the guest: a push backup action is instead describing a <target> (which ultimately could be a remote network resource, but for simplicity the RNG just validates a local file for now), and a pull backup action is instead describing a temporary local file <scratch> (which probably should not be a remote resource). A future refactoring may thus introduce some way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-08-22 01:42:41 +00:00
</element>
<ref name='backupPullDriver'/>
</interleave>
</optional>
</group>
<group>
<ref name='backupAttr'/>
<attribute name='type'>
<value>block</value>
</attribute>
<interleave>
<element name='scratch'>
<attribute name='dev'>
<ref name='absFilePath'/>
</attribute>
backup: Allow 'encryption' of backups and scratch images Add the appropriate entries into the schema to allow encryption of the backup or scratch image. Since we use blockdev internals for everything no changes to the code are actually necessary. https://bugzilla.redhat.com/show_bug.cgi?id=1811906 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-04-09 13:50:40 +00:00
<interleave>
<zeroOrMore>
<ref name='devSeclabel'/>
</zeroOrMore>
<optional>
<ref name='backupEncryption'/>
</optional>
</interleave>
backup: Document new XML for backups Prepare for new backup APIs by describing the XML that will represent a backup. The XML resembles snapshots and checkpoints in being able to select actions for a set of disks, but has other differences. It can support both push model (the hypervisor does the backup directly into the destination file) and pull model (the hypervisor exposes an access port for a third party to grab what is necessary). Add testsuite coverage for some minimal uses of the XML. The <disk> element within <domainbackup> tries to model the same elements as a <disk> under <domain>, but sharing the RNG grammar proved to be hairy. That is in part because while <domain> use <source> to describe a host resource in use by the guest, a backup job is using a host resource that is not visible to the guest: a push backup action is instead describing a <target> (which ultimately could be a remote network resource, but for simplicity the RNG just validates a local file for now), and a pull backup action is instead describing a temporary local file <scratch> (which probably should not be a remote resource). A future refactoring may thus introduce some way to parameterize RNG to accept <disk type='FOO'>...</disk> so that the name of the subelement can be <source> for domain, or <target> or <scratch> as needed for backups. Future patches may improve this area of code. Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-08-22 01:42:41 +00:00
</element>
<ref name='backupPullDriver'/>
</interleave>
</group>
</choice>
</element>
</oneOrMore>
</element>
</optional>
</define>
</grammar>
Reference in New Issue Copy Permalink