Signed-off-by: Han Han
---
.../qemuxml2argvdata/disk-network-iscsi.args | 8 +++-
.../disk-network-iscsi.x86_64-2.12.0.args | 7 ++-
.../disk-network-iscsi.x86_64-latest.args | 45 +++
tests/qemuxml2argvdata/disk-network-iscsi.xml | 9
tests/qemuxml2argvtest.c
Signed-off-by: Han Han
---
docs/news.xml | 10 ++
1 file changed, 10 insertions(+)
diff --git a/docs/news.xml b/docs/news.xml
index 4cef804a..73e58a8f 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -44,6 +44,16 @@
+
+
+ qemu: support iSCSI iSER
+
Introduce QEMU_CAPS_ISCSI_ISER for iSER(iSCSI Extensions for RDMA) of
iscsi backend.
Signed-off-by: Han Han
---
src/qemu/qemu_capabilities.c | 4
src/qemu/qemu_capabilities.h | 3 +++
tests/qemucapabilitiesdata/caps_2.10.0.aarch64.xml | 1 +
Now libvirt supports to parse the iser element in source. It will be
used to enable the iSCSI iSER.
Signed-off-by: Han Han
---
src/conf/domain_conf.c| 10 ++
src/util/virstoragefile.c | 17 ++---
src/util/virstoragefile.h | 2 ++
3 files changed, 26 insertions(+), 3
Signed-off-by: Han Han
---
docs/formatdomain.html.in | 5 +
docs/schemas/domaincommon.rng | 5 +
2 files changed, 10 insertions(+)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 23eb0292..78fd8546 100644
--- a/docs/formatdomain.html.in
+++
The iSCSI iSER transport is introdcued since QEMU 2.9. For blockdev json,
it will appear at 'transport' field:
'json:{...,{"driver": "iscsi","transport":"iser",...}}'
For legacy drive filename as iscsi uri, it will start with 'iser'
scheme:
iser://[[username][%]@][:]//
Signed-off-by: Han Han
The iSER[1](iSCSI Extensions for RDMA) transport is introduced since QEMU
2.9 [2]. It is only valid in iscsi network disk. Note that for the
legacy uri of iscsi iser transport, it will start with 'iser' instead of
'iscsi'.
Diff from v1: Use iser element of the source to enable iSER instead of
the
On 5/14/20 11:32 AM, Daniel Henrique Barboza wrote:
On 5/14/20 11:09 AM, Ján Tomko wrote:
On a Wednesday in 2020, Daniel Henrique Barboza wrote:
Aside from trivial XML parsing/format changes, this patch adds
additional rules for TPM device support to better accomodate
[...]
Any
Although the original patches to support controllers with
hotplug='off' were checking during hotplug/attach requests that the
device was being plugged into a PCI controller that didn't have
hotplug disabled, but I forgot to do the same for device detach (the
main impetus for adding the feature was
On Thu, May 14, 2020 at 06:46:55PM +0200, Andrea Bolognani wrote:
> On Tue, 2020-05-12 at 11:23 +0100, Daniel P. Berrangé wrote:
> > +++ b/examples/MonoDevelop/virDomainStats/virDomainStats.csproj
> > @@ -1 +1,56 @@
> > -
> > > xmlns="http://schemas.microsoft.com/developer/msbuild/2003;>
> >
>
On Tue, 2020-05-12 at 11:26 +0100, Daniel P. Berrangé wrote:
> +++ b/CONTRIBUTING.rst
> @@ -0,0 +1,28 @@
> +==
> +Contributing to libvirt-appdev-guide-python
> +==
The title markers don't match the length of the text.
With that fixed,
On Tue, 2020-05-12 at 11:25 +0100, Daniel P. Berrangé wrote:
> The docs build needs to validate one axis
>
> - A variety of publican versions
>
> We get coverage for this by running builds across various distros.
> The CentOS 8 build is picked as the special one, from which we
Based on the
On 14.05.2020 03:41, Marek Marczykowski-Górecki wrote:
> On Wed, May 13, 2020 at 01:56:52PM +0200, Artur Puzio wrote:
>>
>> On 12.05.2020 15:47, Artur Puzio wrote:
>>> On 08.05.2020 18:41, Jim Fehlig wrote:
On 4/30/20 6:07 AM, Artur Puzio wrote:
> gfx_passthru xl.cfg option enables GPU
On Tue, 2020-05-12 at 11:23 +0100, Daniel P. Berrangé wrote:
> With the introduction of automated CI pipelines, we are now ready to switch
> to using merge requests for the project. With this switch we longer wish
> to have patches sent to the mailing list.
>
> Signed-off-by: Daniel P. Berrangé
On Tue, 2020-05-12 at 11:23 +0100, Daniel P. Berrangé wrote:
> The csharp build needs to validate two axis
>
> - A variety of libvirt versions
> - A variety of csharp versions
>
> We get coverage for both these axis by running a build against the
> distro provided libvirt packages. All that is
On Tue, 2020-05-12 at 11:23 +0100, Daniel P. Berrangé wrote:
> +++ b/examples/MonoDevelop/virDomainStats/virDomainStats.csproj
> @@ -1 +1,56 @@
> -
> xmlns="http://schemas.microsoft.com/developer/msbuild/2003;>
>
> Debug
> AnyCPU
> 9.0.21022
> 2.0
>
On Tue, 2020-05-12 at 11:21 +0100, Daniel P. Berrangé wrote:
> Signed-off-by: Daniel P. Berrangé
> ---
> .hgignore | 7 ---
> 1 file changed, 7 deletions(-)
> delete mode 100644 .hgignore
Reviewed-by: Andrea Bolognani
--
Andrea Bolognani / Red Hat / Virtualization
On Tue, 2020-05-12 at 11:21 +0100, Daniel P. Berrangé wrote:
> +++ b/CONTRIBUTING.rst
> @@ -0,0 +1,28 @@
> +
> +Contributing to ruby-libvirt
> +
> +
> +The libvirt Ruby API binding accepts code contributions via merge requests
> +on the
On Tue, 2020-05-12 at 11:21 +0100, Daniel P. Berrangé wrote:
> +.container_job_template: _job_definition
> + image: docker:stable
> + stage: containers
> + services:
> +- docker:dind
> + before_script:
> +- export TAG="$CI_REGISTRY_IMAGE/ci-$NAME:latest"
> +- export
On Tue, 2020-05-12 at 10:51 +0100, Daniel P. Berrangé wrote:
> This fixes a bugs from bit-rot and then enables GitLab CI and use of
> merge requests for contribution.
>
> Daniel P. Berrangé (6):
> Fix test driver connection type
> Add workaround for broken screenshot API on Ubuntu 18.04
On Tue, 2020-05-12 at 10:51 +0100, Daniel P. Berrangé wrote:
> +%if 0%{?rhel} != 8
> BuildRequires: ant-junit
> +%endif
This can probably be changed to
%if 0%{?rhel} < 8
under the assumption that packages that have been dropped from RHEL
8 are probably not going to be re-introduced in later
On Tue, 2020-05-12 at 10:51 +0100, Daniel P. Berrangé wrote:
> With the introduction of automated CI pipelines, we are now ready to switch
> to using merge requests for the project. With this switch we longer wish
> to have patches sent to the mailing list, and thus the git-publish
> config is
On Tue, 2020-05-12 at 10:51 +0100, Daniel P. Berrangé wrote:
> +.dist_build_job_template: _build_job_definition
> + image: $CI_REGISTRY_IMAGE/ci-$NAME:latest
> + stage: builds
> + script:
> +- ant build jar docs
> +- if test "$NAME" != "centos-8" ; then ant test ; fi
I don't like the
On Mon, 2020-05-11 at 18:22 +0100, Daniel P. Berrangé wrote:
> + publican:
> +default: publican
> +OpenSUSE:
> +CentOS8:
> +pkg:
This should be
publican:
default: publican
pkg:
OpenSUSE:
CentOS8:
With that fixed,
Reviewed-by: Andrea Bolognani
--
Andrea
On Mon, 2020-05-11 at 18:22 +0100, Daniel P. Berrangé wrote:
> The libvirt-java binding needs the JDK to build successfully, as that
> provides the compiler.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> guests/vars/mappings.yml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
On Mon, 2020-05-11 at 18:22 +0100, Daniel P. Berrangé wrote:
> Some platforms pull in libxml2 indirectly, but since libvirt-php needs
> it, we should list it explicitly.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> guests/vars/projects/libvirt-php.yml | 1 +
> 1 file changed, 1 insertion(+)
On Mon, 2020-05-11 at 18:22 +0100, Daniel P. Berrangé wrote:
> + mono:
> +default:
> +Fedora: mono-devel
> +Debian9: mono-devel
> +
> + monodevelop:
> +default:
> +Fedora: monodevelop
> +Debian9: monodevelop
You don't need the 'default' entries.
With those removed,
On Mon, 2020-05-11 at 18:22 +0100, Daniel P. Berrangé wrote:
> + ant-junit:
> +default: ant-junit
> +deb: ant-optional
> +CentOS8:
> +pkg:
It looks like FreeBSD has the required bits after all:
$ pkg list apache-ant | grep -i -E 'junit.*jar'
On Mon, 2020-05-11 at 18:22 +0100, Daniel P. Berrangé wrote:
> + ruby:
> +default: ruby
> +deb: ruby-dev
> +rpm: ruby-devel
This should be
ruby:
deb: ruby-dev
pkg: ruby
rpm: ruby-devel
With that changed,
Reviewed-by: Andrea Bolognani
--
Andrea Bolognani / Red
https://gitlab.com/libvirt/libvirt/-/issues/13
Add support for downscript:
But -net ...,script=/etc/qemu-ifup has some limitation:
https://github.com/qemu/qemu/blob/035b448b84f3557206abc44d786c5d3db2638f7d/net/tap.c#L818
Maybe virNetDevRunEthernetScript is another choice.
In previous commit we started tracking whether QEMU supports
'-numa mem='. This is tied to the machine type because migration
from '-numa mem=' to '-numa memdev' is impossible (or vice
versa). But since it's tied to a machine type (where migration
from one to another is also unsupported) we can
When building -numa command line there is a for() loop that
builds '-numa memdev=' for each guest NUMA node. And also
records in a local variable whether any of memory-object-*
backends must be used to satisfy desired config. Well, instead of
checking in each iteration whether corresponding
v2 of:
https://www.redhat.com/archives/libvir-list/2020-May/msg00490.html
diff to v1:
- different approach used. I completely forgot about the discussion we
had, but after Dan pointed it out to me, it clicked.
Michal Prívozník (3):
qemu: Track numa-mem-supported machine attribute
On 5/14/20 11:09 AM, Ján Tomko wrote:
On a Wednesday in 2020, Daniel Henrique Barboza wrote:
Aside from trivial XML parsing/format changes, this patch adds
additional rules for TPM device support to better accomodate
all the available scenarios with the new TPM Proxy.
The changes make no
On a Wednesday in 2020, Daniel Henrique Barboza wrote:
This patch wraps it up all the wiring done in previous patches,
enabling a PPC64 guest to launch a guest using a TPM Proxy
device.
Note that device validation is already being done in qemu_validate.c,
qemuValidateDomainDeviceDefTPM(), on
On a Wednesday in 2020, Daniel Henrique Barboza wrote:
Aside from trivial XML parsing/format changes, this patch adds
additional rules for TPM device support to better accomodate
all the available scenarios with the new TPM Proxy.
The changes make no impact to existing domains. This means that
On a Wednesday in 2020, Daniel Henrique Barboza wrote:
QEMU 4.1.0 introduced a new device type called TPM Proxy, currently
implemented by PPC64 guests via a new virtual device called
'spapr-tpm-proxy' (see QEMU 0fb6bd073230 for more info).
The TPM Proxy device interacts with a TPM Resource
On a Wednesday in 2020, Daniel Henrique Barboza wrote:
Expose the TPM Proxy support for PPC64 guests by creating a new
cap called QEMU_CAPS_DEVICE_SPAPR_TPM_PROXY.
This device is part of the machinery the guest need to orchestrate
with the PPC64 Ultravisor the transition to the Secure VM (SVM)
On Thu, 2020-05-14 at 15:34 +0200, Boris Fiuczynski wrote:
> On 5/14/20 10:37 AM, Daniel P. Berrangé wrote:
> > I don't see this existing behaviour as confusing. It looks like mostly
> > being a docs ommission about auto-allocation taking place.
>
> Maybe I am repeating myself but I find e.g the
On Thu, May 14, 2020 at 03:34:30PM +0200, Boris Fiuczynski wrote:
> On 5/14/20 10:37 AM, Daniel P. Berrangé wrote:
> > On Wed, May 13, 2020 at 07:41:34PM +0200, Andrea Bolognani wrote:
> > > On Wed, 2020-05-13 at 17:32 +0100, Daniel P. Berrangé wrote:
> > > > On Tue, May 12, 2020 at 12:13:22PM
On 5/13/20 3:30 PM, Daniel Henrique Barboza wrote:
Aside from trivial XML parsing/format changes, this patch adds
additional rules for TPM device support to better accomodate
all the available scenarios with the new TPM Proxy.
The changes make no impact to existing domains. This means that
the
On 5/13/20 3:30 PM, Daniel Henrique Barboza wrote:
Next patch will make use of g_autoptr() with virDomainTPMDefPtr.
Signed-off-by: Daniel Henrique Barboza
---
src/conf/domain_conf.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index
On 5/14/20 10:37 AM, Daniel P. Berrangé wrote:
On Wed, May 13, 2020 at 07:41:34PM +0200, Andrea Bolognani wrote:
On Wed, 2020-05-13 at 17:32 +0100, Daniel P. Berrangé wrote:
On Tue, May 12, 2020 at 12:13:22PM +0200, Boris Fiuczynski wrote:
The behavior change would be
Current code:
uid=0
On 5/13/20 3:30 PM, Daniel Henrique Barboza wrote:
QEMU 4.1.0 introduced a new device type called TPM Proxy, currently
implemented by PPC64 guests via a new virtual device called
'spapr-tpm-proxy' (see QEMU 0fb6bd073230 for more info).
The TPM Proxy device interacts with a TPM Resource Manager,
On 5/13/20 3:30 PM, Daniel Henrique Barboza wrote:
A TPM Proxy device can coexist with a regular TPM. The TPM Proxy
is also always a 'passthrough' device of the 'spapr-tpm-proxy'
model.
This patch adds a pointer to this device in the domain definition
called 'tpmproxy'. This pointer is handled
On 5/13/20 3:30 PM, Daniel Henrique Barboza wrote:
Signed-off-by: Daniel Henrique Barboza
Reviewed-by: Stefan Berger
---
docs/news.xml | 17 +
1 file changed, 17 insertions(+)
diff --git a/docs/news.xml b/docs/news.xml
index 4cef804aac..c22a0f0a18 100644
---
On Thu, May 14, 2020 at 11:37:40 +0200, Michal Privoznik wrote:
> *** BLURB HERE ***
>
> Michal PrÃvoznÃk (2):
> qemuDomainStorageSourcePrivateDispose: Free httpcookie
> qemuBlockJobDataDisposeJobdata: Free data.commit.disabledBitmapsBase
>
> src/qemu/qemu_blockjob.c | 5 +
>
==179663== 35 (24 direct, 11 indirect) bytes in 1 blocks are definitely lost in
loss record 205 of 461
==179663==at 0x4839EC6: calloc (vg_replace_malloc.c:762)
==179663==by 0x5791AC0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6400.1)
==179663==by 0x190C79:
*** BLURB HERE ***
Michal Prívozník (2):
qemuDomainStorageSourcePrivateDispose: Free httpcookie
qemuBlockJobDataDisposeJobdata: Free data.commit.disabledBitmapsBase
src/qemu/qemu_blockjob.c | 5 +
src/qemu/qemu_domain.c | 1 +
2 files changed, 6 insertions(+)
--
2.26.2
==156803== 58 (40 direct, 18 indirect) bytes in 1 blocks are definitely lost in
loss record 306 of 463
==156803==at 0x4839EC6: calloc (vg_replace_malloc.c:762)
==156803==by 0x5791AC0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6400.1)
==156803==by 0x48F60DC: virAlloc (viralloc.c:48)
On Wed, May 13, 2020 at 07:41:34PM +0200, Andrea Bolognani wrote:
> On Wed, 2020-05-13 at 17:32 +0100, Daniel P. Berrangé wrote:
> > On Tue, May 12, 2020 at 12:13:22PM +0200, Boris Fiuczynski wrote:
> > > The behavior change would be
> > > Current code:
> > > uid=0 fid=0 -> uid=0 fid=0 -> address
On Wed, May 13, 2020 at 07:00:49PM +0200, Andrea Bolognani wrote:
> On Tue, 2020-05-12 at 16:42 +0200, Erik Skultety wrote:
> > This series is trying to consolidate the number of config files we currently
> > recognize under ~/.config/lcitool to a single global YAML config file.
> > Thanks
> > to
On Wed, May 13, 2020 at 06:48:26PM +0200, Andrea Bolognani wrote:
> On Tue, 2020-05-12 at 16:42 +0200, Erik Skultety wrote:
> > +def _validate_section(self, config, section, mandatory_keys):
> > +# remove keys we don't recognize
> > +self._remove_unknown_keys(config[section],
On Wed, May 13, 2020 at 11:26:52PM -0500, Brijesh Singh wrote:
>
> On 5/13/20 1:21 AM, Erik Skultety wrote:
> > 2) check if /dev/sev device exist (aka firmware is detected)
> This seems reasonable. Shouldn't it have been documented in
> docs/kbase/launch_security_sev.rst?
> >>>
54 matches
Mail list logo
