On Tue, Mar 26, 2019 at 8:14 AM Eric Blake <eblake@xxxxxxxxxx> wrote:
...
+ <value>pull</value>
+ </attribute>
+ <interleave>
+ <element name='server'>
+ <choice>
...
+ <group>
+ <attribute name='transport'>
+ <value>unix</value>
+ </attribute>
+ <attribute name='socket'>
+ <ref name='absFilePath'/>
+ </attribute>
+ </group>
+ </choice>
+ </element>
+ <ref name='backupDisksPull'/>
+ </interleave>
+ </group>
+ </choice>
We are trying to use backup_v5a from:
And when we start a backup with this xml:
<domainbackup mode="pull">
<server socket="/var/run/vdsm/nbd/4f594cec-1a27-43fd-acf8-3283cacd6347.sock" transport="unix" />
<disks>
<disk name="sda" type="file" />
</disks>
</domainbackup>
Libvirt fail with:
'Operation not supported: <domainbackup> must specify TCP server for now'
Which comes from:
if (!def->server ||
def->server->transport != VIR_STORAGE_NET_HOST_TRANS_TCP) {
virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
_("<domainbackup> must specify TCP server for now"));
goto cleanup;
}
def->server->transport != VIR_STORAGE_NET_HOST_TRANS_TCP) {
virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
_("<domainbackup> must specify TCP server for now"));
goto cleanup;
}
Unix socket support is very important for us, for several reasons:
- always local, no way to configure it in the wrong way
- having permissions on the socket
- easier to manage using file system (persistence is free)
- usually perforamnce better then tcp
I have tests running our nbd client with qemu, starting a backup with unix socket using qmp, so there is
no reason that libvirt would not support it.
Can we expect this to be fixed soon?
If we must use tcp for now, can we use port=0 to get a random port from the kernel,
and find the port by getting the backup xml?
I hope that we don't need to managed pull of ports for backups per host.
Nir
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
