On Tue, Jan 29, 2019 at 06:40:08PM +, Daniel P. Berrangé wrote:
> On Tue, Jan 29, 2019 at 05:15:42PM +0100, Erik Skultety wrote:
> > On Wed, Jan 23, 2019 at 03:02:28PM +, Singh, Brijesh wrote:
> > >
> > >
> > > On 1/23/19 7:36 AM, Daniel P. Berrangé wrote:
> > > > On Wed, Jan 23, 2019 at
Hi,
> > (Migration compat is left as an exercise for the reader :-))
>
> It's not just migration compatibility, it's also guest ABI: "the guest
> can tell the difference".
Is that actually the case on x86? I don't think so.
Note: arm is different, because the flash is listed in the device
On Tue, Jan 15, 2019 at 08:15:47PM -0500, John Ferlan wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1581670
>
> Introduce the bare bones functions to processing capability
> data for the storage driver. Currently just looking to store
> and format the storage pool types in output, such as:
On Tue, Jan 29, 2019 at 18:52:37 +0100, Kashyap Chamarthy wrote:
> On Tue, Jan 29, 2019 at 05:24:09PM +0100, Peter Krempa wrote:
> > Some clients take the advice to poll virDomainGetBlockJobInfo rather
> > than wait for the ready event. In some cases qemu can get to 100% and
> > still not reach
Am 29.01.2019 um 17:37 hat Markus Armbruster geschrieben:
> Kevin Wolf writes:
>
> > scsi-disk includes in the Device Identification VPD page, depending on
> > configuration amongst others, a vendor specific designator that consists
> > either of the serial number if given or the BlockBackend
On Wed, Jan 30, 2019 at 09:06:30AM +0100, Erik Skultety wrote:
> Thanks for ^this bit which helped me understand the bits below. When I read
> the
> man page yesterday the first question was, okay, how do I figure out whether
> the file capabilities bit is set? Well, use xattrs...which didn't
On Mon, Jan 28, 2019 at 09:26:45 -0500, John Ferlan wrote:
>
>
> On 1/23/19 11:10 AM, Peter Krempa wrote:
> > Security labelling of disks consists of labelling of the disk image
>
> *labeling
>
> > itself and it's backing chain. Modify
> > virSecurityManager[Set|Restore]ImageLabel to take a
On Tue, Jan 29, 2019 at 04:32:34PM +0100, Peter Krempa wrote:
v2 contains a tweak to the CSS to widen the page slightly and keep
borders on narrow screen.
Peter Krempa (2):
docs: Format bit shift and hex notation for bitwise flag enums
docs: css: Make docs page wider while still accomodating
On Tue, Jan 29, 2019 at 04:32:35PM +0100, Peter Krempa wrote:
Big number itself does not make much sense in some cases. Format the
bitshift format as well.
Changes our web page docs from:
VIR_MIGRATE_POSTCOPY = 32768 : Setting the VIR_MIGRATE_POSTCOPY...
VIR_MIGRATE_TLS = 65536 : Setting
> > > though, we need a #ifdef check for existance of PR_CAP_AMBIENT
> > >
> > > > An alternative question I've been playing ever since we exchanged the
> > > > last few
> > > > emails is that can't we wait until the ioctls are compared against
> > > > permissions
> > > > in kernel so that
Hi folks,
First time contributor, but I felt that what I discovered was (probably) a
very rare situation.
I'm running a Centos server (my only Linux deployment) to which customers
all over the U.S. connect to process their micro-lender businesses. There
are several VM's, among other one
On Wed, Jan 30, 2019 at 02:56:46PM +0100, Michal Privoznik wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1503284
>
> The way we currently start qemu from CPU affinity POV is as
> follows:
>
> 1) the child process is set affinity to all online CPUs (unless
> some vcpu pinning was given in
On 30/01/19 15:13, Markus Armbruster wrote:
> -global driver=cfi.pflash01,property=secure,value=on
>
> Affects *all* such devices, but fortunately we have at most two, and the
> one we don't want to affect happens to ignore the property value.
Is this true? I think both need secure=on, at
Commit 7a227688a83880 assumes that libvirt_driver_storage_impl.la
is always available. Well it is not. Users have option to turn
the storage driver off in which case it isn't build and linking
the test with the library then fails.
Signed-off-by: Michal Privoznik
---
And alternative approach
On 01/30/19 16:24, Peter Maydell wrote:
> Well, nobody who does anything with x86 has cared enough to
> make the pflash implementation actually correct.
I feel sort of included under this umbrella, so:
I haven't been aware of any particular pflash implementation errors. I
"didn't care" because
On 1/30/19 3:40 PM, John Ferlan wrote:
Recent adjustment to add XML namespace processing for storage pool
XML processing broke the mingw* builds:
CC storagevolxml2xmltest.o
gmake[2]: *** No rule to make target '../src/libvirt_driver_storage_impl.la',
needed by
Other than dumping and parsing the config for all running VMs, is
there a way to get the current map of vsock cids allocated to their VM
domains?
Thanks,
Brian
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Jan 29, 2019 at 06:18:21PM -0800, nico wrote:
> Hi folks,
>
>
>
> First time contributor, but I felt that what I discovered was (probably) a
> very rare situation.
>
>
>
> I'm running a Centos server (my only Linux deployment) to which customers
> all over the U.S. connect to
On 1/30/19 9:33 AM, Michal Privoznik wrote:
> Commit 7a227688a83880 assumes that libvirt_driver_storage_impl.la
> is always available. Well it is not. Users have option to turn
> the storage driver off in which case it isn't build and linking
> the test with the library then fails.
>
>
On Mon, Jan 28, 2019 at 13:00:03 -0500, John Ferlan wrote:
>
>
> On 1/23/19 11:11 AM, Peter Krempa wrote:
> > Be more sensible when setting labels of the target of a
> > virDomainBlockCopy operation. Previously we'd relabel everything in case
> > it's a copy job even if there's no unlabelled
On Wed, Jan 30, 2019 at 03:55:05PM +, Daniel P. Berrangé wrote:
> On Wed, Jan 30, 2019 at 10:03:43AM -0500, John Ferlan wrote:
> >
> >
> > On 1/30/19 3:31 AM, Pavel Hrdina wrote:
> > > On Tue, Jan 15, 2019 at 08:15:47PM -0500, John Ferlan wrote:
> > >>
On 1/30/19 3:31 AM, Pavel Hrdina wrote:
> On Tue, Jan 15, 2019 at 08:15:47PM -0500, John Ferlan wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1581670
>>
>> Introduce the bare bones functions to processing capability
>> data for the storage driver. Currently just looking to store
>> and
On Wed, Jan 23, 2019 at 04:32:39PM -0500, Cole Robinson wrote:
> devices lack the model= attribute which is used by
> most other device types. bus= mostly acts as one, but it
> serves other purposes too like determing what target=
> prefix to use, and for matching against controller type=
>
On Tue, Jan 29, 2019 at 10:07:16AM -0600, Brian Kroth wrote:
> Other than dumping and parsing the config for all running VMs, is
> there a way to get the current map of vsock cids allocated to their VM
> domains?
What you describe is the only supported approach from libvirt's POV.
Regards,
Commit f2f84b4d4 added storagepoolxml2argvtest processing; however,
it didn't follow alter the else to !WITH_STORAGE and add the source
itself to the EXTRA_DIST like the other WITH_STORAGE options for
virstorageutiltest and storagevolxml2argvtest.
Signed-off-by: John Ferlan
---
Recent adjustment to add XML namespace processing for storage pool
XML processing broke the mingw* builds:
CC storagevolxml2xmltest.o
gmake[2]: *** No rule to make target '../src/libvirt_driver_storage_impl.la',
needed by 'storagepoolxml2xmltest.exe'. Stop.
gmake[2]: *** Waiting for
Commit 7a227688a caused a build failure on mingw. Following
other uses of including ../src/libvirt_driver_storage_impl.la
I moved to under the WITH_STORAGE conditional.
Signed-off-by: John Ferlan
---
tests/Makefile.am | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
On Mon, Jan 28, 2019 at 09:27:51 -0500, John Ferlan wrote:
>
>
> On 1/23/19 11:11 AM, Peter Krempa wrote:
> > Allow callers use the new flag.
> >
> > Signed-off-by: Peter Krempa
> > ---
> > src/qemu/qemu_domain.c | 4 ++--
> > src/qemu/qemu_security.c | 10 ++
> >
On Wed, Jan 30, 2019 at 11:25:25AM -0600, Brian Kroth wrote:
> OK, I was expecting it to maintain a list internally (at least for the
> things it knows about) so that the auto property in the domxml can work
> nicely, but I suppose it would still need to fallback to letting the kernel
> reject an
On 1/30/19 7:39 AM, Erik Skultety wrote:
though, we need a #ifdef check for existance of PR_CAP_AMBIENT
> An alternative question I've been playing ever since we exchanged the
> last few
> emails is that can't we wait until the ioctls are compared against
>
There is an online service call LGTM (Looks Good To Me) which does
static analysis of open source projects and I happened to learn that
they include coverage of libvirt
https://lgtm.com/projects/g/libvirt/libvirt
I looked at the alerts they reported. Currently no errors, 41 warnings
and 90
The 'rv' variable is never changed after being declared, so can be
removed.
Signed-off-by: Daniel P. Berrangé
---
src/remote/remote_daemon_dispatch.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/remote/remote_daemon_dispatch.c
On Wed, Jan 30, 2019 at 02:39:54PM +0100, Erik Skultety wrote:
> > > > though, we need a #ifdef check for existance of PR_CAP_AMBIENT
> > > >
> > > > > An alternative question I've been playing ever since we exchanged the
> > > > > last few
> > > > > emails is that can't we wait until the ioctls
On Wed, 30 Jan 2019 at 07:24, Markus Armbruster wrote:
>
> Let me reply to the "why is the cfi.pflash01 device so weird" part
> first, because that's relatively quick, and because it could easily
> distract us from the more important "how do we want to configure OVMF"
> part. I'll reply to that
On 01/30/19 15:33, Paolo Bonzini wrote:
> On 30/01/19 15:13, Markus Armbruster wrote:
>> -global driver=cfi.pflash01,property=secure,value=on
>>
>> Affects *all* such devices, but fortunately we have at most two, and
>> the one we don't want to affect happens to ignore the property value.
>
>
On Tue, Jan 29, 2019 at 04:32:09PM +0100, Andrea Bolognani wrote:
> On Wed, 2019-01-23 at 16:32 -0500, Cole Robinson wrote:
> [...]
> > +++ b/docs/schemas/domaincommon.rng
> > @@ -2153,6 +2153,8 @@
> >ibmvscsi
> >virtio-scsi
> >lsisas1078
On Wed, 30 Jan 2019 at 16:44, Laszlo Ersek wrote:
>
> On 01/30/19 16:24, Peter Maydell wrote:
>
> > Well, nobody who does anything with x86 has cared enough to
> > make the pflash implementation actually correct.
>
> I feel sort of included under this umbrella, so:
>
> I haven't been aware of any
OK, I was expecting it to maintain a list internally (at least for the
things it knows about) so that the auto property in the domxml can work
nicely, but I suppose it would still need to fallback to letting the kernel
reject an already taken cid number anyways (eg: due to a manually executed
qemu
On Wed, Jan 30, 2019 at 10:03:43AM -0500, John Ferlan wrote:
>
>
> On 1/30/19 3:31 AM, Pavel Hrdina wrote:
> > On Tue, Jan 15, 2019 at 08:15:47PM -0500, John Ferlan wrote:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1581670
> >>
> >> Introduce the bare bones functions to processing
On 1/29/19 10:14 AM, Ján Tomko wrote:
> On Fri, Jan 18, 2019 at 09:42:35AM -0500, John Ferlan wrote:
>> Alter the code to use the virStorageFileGetSCSIKey helper
>> to fetch the unique key for the SCSI disk. Alter the logic
>> to follow the former code which would return a duplicate
>> of @dev
PEP 8 says:
"Comparisons to singletons like None should always be done
with 'is' or 'is not', never the equality operators."
There are potentially semantics differences, though in the case of this
libvirt code its merely a style change:
The struct _virStorageBackendQemuImgInfo is quite large so it is
preferrable to pass it by reference instead of by value. This requires
us to stop modifying the "compat" field.
Signed-off-by: Daniel P. Berrangé
---
src/storage/storage_util.c | 35 +--
1 file
'val' is initialized from virDomainCapsFeatureTypeFromString and a
few lines earlier there was already a check for 'val < 0'.
The 'val >= 0' is thus always true. The enum conversion similarly
ensures that the val will be less than VIR_DOMAIN_CAPS_FEATURE_LAST,
so "val <
Signed-off-by: Daniel P. Berrangé
---
src/hyperv/hyperv_wmi_generator.py | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/hyperv/hyperv_wmi_generator.py
b/src/hyperv/hyperv_wmi_generator.py
index 518a55fd6d..fc1370955f 100755
--- a/src/hyperv/hyperv_wmi_generator.py
+++
The virDomainDeviceInfo parameter is a large struct so it is preferrable
to pass it by reference instead of by value.
Signed-off-by: Daniel P. Berrangé
---
src/qemu/qemu_command.c| 4 ++--
src/qemu/qemu_domain.c | 10 +-
src/qemu/qemu_domain.h | 9 +
Only run the pool-netfs-ns-mountopts if built WITH_STORAGE_FS and only
run pool-rbd-ns-configopts if built with WITH_STORAGE_RBD since the
namespace support is only enabled if the pool is enabled.
Signed-off-by: John Ferlan
---
tests/storagepoolxml2xmltest.c | 4
1 file changed, 4
On Tue, Jan 29, 2019 at 04:32:36PM +0100, Peter Krempa wrote:
> Bump the width to 85em while keeping a maximum width of 90%.
>
> Signed-off-by: Peter Krempa
> ---
> docs/libvirt.css | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/docs/libvirt.css
On 1/30/19 12:40 PM, Daniel P. Berrangé wrote:
> The virDomainDeviceInfo parameter is a large struct so it is preferrable
> to pass it by reference instead of by value.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> src/qemu/qemu_command.c| 4 ++--
> src/qemu/qemu_domain.c |
On 1/30/19 12:40 PM, Daniel P. Berrangé wrote:
> PEP 8 says:
>
> "Comparisons to singletons like None should always be done
> with 'is' or 'is not', never the equality operators."
>
> There are potentially semantics differences, though in the case of this
> libvirt code its merely a
On 1/30/19 12:40 PM, Daniel P. Berrangé wrote:
> Signed-off-by: Daniel P. Berrangé
> ---
> src/hyperv/hyperv_wmi_generator.py | 1 -
> 1 file changed, 1 deletion(-)
>
Reviewed-by: John Ferlan
John
--
libvir-list mailing list
libvir-list@redhat.com
On 1/30/19 12:40 PM, Daniel P. Berrangé wrote:
> 'val' is initialized from virDomainCapsFeatureTypeFromString and a
> few lines earlier there was already a check for 'val < 0'.
>
> The 'val >= 0' is thus always true. The enum conversion similarly
> ensures that the val will be less than
On 1/30/19 12:40 PM, Daniel P. Berrangé wrote:
> The 'rv' variable is never changed after being declared, so can be
> removed.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> src/remote/remote_daemon_dispatch.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
Reviewed-by:
On 1/30/19 12:40 PM, Daniel P. Berrangé wrote:
> The struct _virStorageBackendQemuImgInfo is quite large so it is
> preferrable to pass it by reference instead of by value. This requires
> us to stop modifying the "compat" field.
>
> Signed-off-by: Daniel P. Berrangé
> ---
>
https://bugzilla.redhat.com/show_bug.cgi?id=1503284
The way we currently start qemu from CPU affinity POV is as
follows:
1) the child process is set affinity to all online CPUs (unless
some vcpu pinning was given in the domain XML)
2) Once qemu is running, cpuset cgroup is configured taking
Cc: Paolo for additonal device infrastructure expertise.
Peter Maydell writes:
> On Fri, 25 Jan 2019 at 15:11, Markus Armbruster wrote:
>> (1) cfi.pflash01 isn't available with -device.
>>
>> (2) "Magic board code picks up the backend [created for -drive
>> if=pflash], creates a frontend
55 matches
Mail list logo
