Re: [libvirt] [PATCH 2/5] s390: Report blank host model instead of "host"

[Jiri Denemark]

On Fri, Nov 04, 2016 at 11:00:29 -0400, Jason J. Herne wrote:
> On 11/03/2016 08:54 AM, Jiri Denemark wrote:
> > On Wed, Nov 02, 2016 at 16:34:32 -0400, Jason J. Herne wrote:
> >> From: "Collin L. Walling" 
> >>
> >> On s390 , the host's features are heavily influenced by not only the host
> >> hardware but also by hardware microcode level, host OS version, qemu
> >> version and kvm version. In this environment it does not make sense to
> >> attempt to report exact host details. Rather than use the generic "host"
> >> we leave this field blank.
> >>
> >> Signed-off-by: Collin L. Walling 
> >> Signed-off-by: Jason J. Herne 
> >> ---
> >>  src/cpu/cpu_s390.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/src/cpu/cpu_s390.c b/src/cpu/cpu_s390.c
> >> index 0f94084..c75eacb 100644
> >> --- a/src/cpu/cpu_s390.c
> >> +++ b/src/cpu/cpu_s390.c
> >> @@ -59,7 +59,7 @@ s390Decode(virCPUDefPtr cpu,
> >>  virCheckFlags(VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES, -1);
> >>
> >>  if (cpu->model == NULL &&
> >> -VIR_STRDUP(cpu->model, "host") < 0)
> >> +VIR_STRDUP(cpu->model, "") < 0)
> >>  return -1;
> >>
> >>  return 0;
> >
> > I think this function shouldn't do anything. Reporting "host" or even ""
> > as host CPU is pointless. If we cannot provide anything reasonable, we
> > should not report it at all.
> 
> I would agree. But virsh domcapabilities only indicates support for 
> host-model
> mode if we have something in cpu->hostModel.
> 
> virDomainCapsCPUFormat()
> ...
> if (cpu->hostModel) {
>  virBufferAddLit(buf, "supported='yes'>\n");
> 
> It also causes the guest to fail when trying to use host-model mode
> because virQEMUCapsInitHostCPUModel() skips setting qemuCaps->hostCPUModel
> if caps->host.cpu->model does not exist.

And that's what you need to change. As I wrote in my comments to patch
4/5, virQEMUCapsInitHostCPUModel() is the place where
qemuCaps->hostCPUModel should be initialized with the host CPU returned
by QEMU. If you do that, all the issues you mentioned will go away.

Jirka

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Allow saving QEMU libvirt state to a pipe

[Roy Keene]

All,

Currently the "virsh save" command opens a file to save a domain's 
XML and memory state, does the save, and then re-opens the file to 
simulate seeking to the beginning to update the header to indicate that 
the file is complete.


For pipes this is not possible, attempting to re-open the pipe will not 
connect you to the same consumer.  Seeking is also not possible on a pipe.


Attached is a patch that detects if the file being written to is not 
seekable, and if so writes the completed header initially, then writes 
the normal data, and avoids re-opening the file.


This is useful to me for saving a VM state directly to Ceph RBD images 
without having an intermediate file.


I've tested this patch successfully (against v1.3.5) for both saving and 
restoring a domain:


# *( fifo="$(mktemp -u)"; mkfifo "${fifo}" && virsh save one-0 "${fifo}" 
& cat "${fifo}" | rbd import - rbd/test1234 & wait; rm -f "${fifo}" )*


Domain one-0 saved to /tmp/tmp.HK4hChiQqB

#

# *( fifo="$(mktemp -u)"; mkfifo "${fifo}" && rbd export rbd/test1234 - 
> "${fifo}" & virsh restore "${fifo}" & wait; rm -f "${fifo}" ) *

Exporting image: 100% complete...done.
Domain restored from /tmp/tmp.0YaUZ5Y2yT

# *virsh list*
 IdName   State

 11one-0  running
#

--
Roy Keene
Knight Point Systems, LLC
Service-Disabled Veteran-Owned Business
1775 Wiehle Avenue Suite 101 | Reston, VA 20190
c: 813-956-3808f: 571-266-3106
www.knightpoint.com
DHS EAGLE II Prime Contractor: FC1 SDVOSB Track
GSA Schedule 70 SDVOSB: GS-35F-0646S
GSA MOBIS Schedule: GS-10F-0404Y
ISO 2 / ISO 27001

Notice: This e-mail message, including any attachments, is for the
sole use of the intended recipient(s) and may contain confidential
and privileged information.  Any unauthorized review,  copy,  use,
disclosure, or distribution is STRICTLY prohibited. If you are not
the intended recipient,  please contact the sender by reply e-mail
and destroy all copies of the original message.

diff --no-dereference -uNr libvirt-1.3.5.orig/src/qemu/qemu_driver.c libvirt-1.3.5-savepipe/src/qemu/qemu_driver.c
--- libvirt-1.3.5.orig/src/qemu/qemu_driver.c	2016-05-28 11:47:33.0 -0500
+++ libvirt-1.3.5-savepipe/src/qemu/qemu_driver.c	2016-11-04 10:54:15.160805261 -0500
@@ -3080,6 +3080,7 @@
 virQEMUSaveHeader header;
 bool bypassSecurityDriver = false;
 bool needUnlink = false;
+bool canReopen = true;
 int ret = -1;
 int fd = -1;
 int directFlag = 0;
@@ -3087,7 +3088,6 @@
 unsigned int wrapperFlags = VIR_FILE_WRAPPER_NON_BLOCKING;
 
 memset(, 0, sizeof(header));
-memcpy(header.magic, QEMU_SAVE_PARTIAL, sizeof(header.magic));
 header.version = QEMU_SAVE_VERSION;
 header.was_running = was_running ? 1 : 0;
 header.compressed = compressed;
@@ -3109,12 +3109,32 @@
 if (fd < 0)
 goto cleanup;
 
+/*
+ * Determine if this file can be re-opened
+ *
+ * Right now we just try to seek into it, if that fails then that means we
+ * are probably not dealing with a regular file here and we probably
+ * cannot reopen it.
+ */
+if (lseek(fd, 0, SEEK_SET) == ((off_t) -1)) {
+canReopen = false;
+}
+
 if (virSecurityManagerSetImageFDLabel(driver->securityManager, vm->def, fd) < 0)
 goto cleanup;
 
 if (!(wrapperFd = virFileWrapperFdNew(, path, wrapperFlags)))
 goto cleanup;
 
+/* Set the header magic */
+if (canReopen) {
+/* We will update the magic after the saving completes successfully */
+memcpy(header.magic, QEMU_SAVE_PARTIAL, sizeof(header.magic));
+} else {
+/* If we cannot re-open the output, include the final magic here */
+memcpy(header.magic, QEMU_SAVE_MAGIC, sizeof(header.magic));
+}
+
 /* Write header to file, followed by XML */
 if (qemuDomainSaveHeader(fd, path, domXML, ) < 0)
 goto cleanup;
@@ -3124,28 +3144,30 @@
 asyncJob) < 0)
 goto cleanup;
 
-/* Touch up file header to mark image complete. */
+if (canReopen) {
+/* Touch up file header to mark image complete. */
 
-/* Reopen the file to touch up the header, since we aren't set
- * up to seek backwards on wrapperFd.  The reopened fd will
- * trigger a single page of file system cache pollution, but
- * that's acceptable.  */
-if (VIR_CLOSE(fd) < 0) {
-virReportSystemError(errno, _("unable to close %s"), path);
-goto cleanup;
-}
+/* Reopen the file to touch up the header, since we aren't set
+ * up to seek backwards on wrapperFd.  The reopened fd will
+ * trigger a single page of file system cache pollution, but
+ * that's acceptable.  */
+if (VIR_CLOSE(fd) < 0) 

Re: [libvirt] [systemd-devel] How to make udev not touch my device?

[Martin Pitt]

Hello Michal,

Michal Privoznik [2016-11-04  8:47 +0100]:
> That means that whenever a VM is being started up, libvirtd (our
> daemon we have) relabels all the necessary paths that QEMU process
> (representing VM) can touch.

Does that mean it's shipping an udev rule that does that? Or actually
listens to uevents by itself (possibly via libudev) and applies the
labels?

> However, I'm facing an issue that I don't know how to fix. In some cases
> QEMU can close & reopen a block device. However, closing a block device
> triggers an event and hence if there is a rule that sets a security
> label on a device the QEMU process is unable to reopen the device again.

Is that triggering the above libvirtd action (in the daemon via
libudev or via an udev rule), or is that something else?

> My question is, whet we can do to prevent udev from mangling with our
> security labels that we've set on the devices?

Sorry for my ignorance, but my question in return is: What's the udev
rule that mangles with it in the first place? I don't see any such
rule in upstream systemd or in Debian/Ubuntu, but it's of course
possible that Fedora ships such a rule via another package.

> One of the ideas our lead developer had was for libvirt to set some kind
> of udev label on devices managed by libvirt (when setting up security
> labels) and then whenever udev sees such labelled device it won't touch
> it at all (this could be achieved by a rule perhaps?). Later, when
> domain is shutting down libvirt removes that label. But I don't think
> setting an arbitrary label on devices is supported, is it?

It actually is -- they are called "tags" (TAG+=) and "properties"
(ENV{PROPNAME}="foo"), see udev(7). So indeed the most straightforward
way would be to tag or set a property on those devices which you want
to handle in libvirtd yourself, and then add something like

   TAG=="libvirtd", GOTO="skip_selinux_context"
   [... original rule that changes context goes here ..]
   LABEL="skip_selinux_context"

But for further details I need to understand the actual rules
involved.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Unbreak rebuilding docs with release tarballs

[Guido Günther]

Release tarballs ship the include/libvirt/libvirt-common.h.

when srcdir != builddir we end up including libvirt-common.h twice: from
$top_srcdir/include/libvirt-common.h and from
$builddir/include/libvirt-common.h leading to

  function virTypedParamsGetUInt from 
/tmp/buildd/libvirt-2.4.0/debian/build/docs/../include/libvirt/libvirt-common.h 
redeclared in /tmp/buildd/libvirt-2.4.0/docs/../include/libvirt/libvirt-common.h
  function virTypedParamsAddBoolean from 
/tmp/buildd/libvirt-2.4.0/debian/build/docs/../include/libvirt/libvirt-common.h 
redeclared in /tmp/buildd/libvirt-2.4.0/docs/../include/libvirt/libvirt-common.h
   …

Only add the builddir to the search list if there is no pregenerated
libvirt-common.h.

Reuse the existing check that predates the libvirt.h → libvirt-common.h
split and that probably was meant for exactly that.

References: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842452
---
 docs/apibuild.py | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/docs/apibuild.py b/docs/apibuild.py
index 8728b27..47f340c 100755
--- a/docs/apibuild.py
+++ b/docs/apibuild.py
@@ -2607,10 +2607,9 @@ class app:
 dirs = [srcdir + "/../src",
 srcdir + "/../src/util",
 srcdir + "/../include/libvirt"]
-if builddir:
+if (builddir and
+not os.path.exists(srcdir + 
"/../include/libvirt/libvirt-common.h")):
 dirs.append(builddir + "/../include/libvirt")
-if glob.glob(srcdir + "/../include/libvirt/libvirt.h") == [] :
-dirs.append("../include/libvirt")
 builder = docBuilder(name, srcdir, dirs, [])
 elif glob.glob("src/libvirt.c") != [] :
 if not quiet:
-- 
2.10.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH glib] Add missing dep on intltool

[Daniel P. Berrange]

Libvirt-glib requires intltool at build time. Previously it
was pulled in transitively via another RPM dependancy. As of
Fedora 26, this no longer happens, exposing the missing RPM
dep.

Signed-off-by: Daniel P. Berrange 
---

Pushed as a build fix for rawhide

 libvirt-glib.spec.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libvirt-glib.spec.in b/libvirt-glib.spec.in
index 2ec8337..a1ca11f 100644
--- a/libvirt-glib.spec.in
+++ b/libvirt-glib.spec.in
@@ -37,6 +37,7 @@ BuildRequires: libtool
 %if %{with_vala}
 BuildRequires: vala-tools
 %endif
+BuildRequires: intltool
 
 %package devel
 Group: Development/Libraries
-- 
2.9.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: libvirt-glib release 1.0.0

[Daniel P. Berrange]

I am pleased to announce that a new release of the libvirt-glib package,
version 1.0.0, is now available from

  ftp://libvirt.org/libvirt/glib/

The packages are GPG signed with

Key fingerprint: DAF3 A6FD B26B 6291 2D0E  8E3F BE86 EBB4 1510 4FDF (4096R)

Changes in this release:

- Switch to new release numbering scheme, major
  digit incremented each year, minor for each
  release, micro for stable branches (if any)
- Fix Libs.private variable in pkg-config file
- Fix git introspection warnings
- Add ability to set SPICE gl property
- Add support for virtio video model
- Add support for 3d accel property
- Add support for querying video model
- Add support for host device config for PCI devs
- Add docs for more APIs
- Avoid unused variable warnings
- Fix check for libvirt optional features to use pkg-config
- Delete manually written python binding. All apps should
  use PyGObject with gobjection introspection.
- Add schema to be NULL on config objects
- Preserve unknown devices listed in XML
- Add further test coverage

libvirt-glib comprises three distinct libraries:

   - libvirt-glib- Integrate with the GLib event loop and error handling
   - libvirt-gconfig - Representation of libvirt XML documents as GObjects
   - libvirt-gobject - Mapping of libvirt APIs into the GObject type system

NB: While libvirt aims to be API/ABI stable forever, with libvirt-glib
we are not currently guaranteeing that libvirt-glib libraries are
permanently API/ABI stable. That said we do not expect to break the
API/ABI for the forseeable future and will always strive avoid it.

Follow up comments about libvirt-glib should be directed to the regular
libvir-list@redhat.com development list.

Thanks to all the people involved in contributing to this release.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties

[Eduardo Habkost]

On Fri, Nov 04, 2016 at 04:45:17PM +0100, Markus Armbruster wrote:
> Eduardo Habkost  writes:
> 
> > (CCing libvirt people, as I forgot to CC them)
> >
> > On Mon, Oct 31, 2016 at 03:07:23PM +0100, Igor Mammedov wrote:
> >> On Fri, 28 Oct 2016 23:48:06 -0200
> >> Eduardo Habkost  wrote:
> >> 
> >> > When an abstract class is used on device-list-properties, we can
> >> > simply return the class properties registered for the class.
> >> > 
> >> > This will be useful if management software needs to query for
> >> > supported options that apply to all devices of a given type (e.g.
> >> > options supported by all CPU models, options supported by all PCI
> >> > devices).
> >> Patch looks fine to me but I'm not qmp interface guru
> >> so I'd leave review up to maintainers.
> >> 
> >> One question though,
> >> How would management software discover typename of abstract class?
> >
> > It depends on the use case. On some cases, management may already
> > have bus-specific logic that will know what's the base type it
> > needs to query (e.g. it may query "pci-device" to find out if all
> > PCI devices support a given option). On other cases, it may be
> > discovered using other commands.
> 
> The stated purpose of this feature is to let management software "query
> for supported options that apply to all devices of a given type".  I
> suspect that when management software has a notion of "a given type", it
> knows its name.
> 
> Will management software go fishing for subtype relationships beyond the
> types it knows?  I doubt it.  Of course, management software developers
> are welcome to educate me :)
> 
> > For the CPU case, I will propose adding the base QOM CPU typename
> > in the query-target command.
> 
> Does this type name vary?  If yes, can you give examples?

It does. x86-specific CPU properties are on the x86_64-cpu and
i386-cpu classes. arm-specific CPU properties are on the arm-cpu
class.

> 
> >> Perhaps this patch should be part of some other series.
> >
> > This is a valid point. In this case, it depends on the approach
> > we want to take: do we want to provide a flexible interface for
> > management, let them find ways to make it useful and give us
> > feedback on what is lacking; or do we want to provide the new
> > interface only after we have specified the complete solution for
> > the problem?
> >
> > I don't know the answer. I will let the qdev/QOM/QMP maintainers
> > answer that.
> 
> I'm reluctant to add QMP features just because we think they might be
> useful to someone.  We should talk to users to confirm our hunch before
> we act on it.
> 
> That said, this one isn't exactly a biggie.

Considering we are past soft freeze, I can document a more
concrete usage example when I submit the next version.

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties

[Markus Armbruster]

Eduardo Habkost  writes:

> (CCing libvirt people, as I forgot to CC them)
>
> On Mon, Oct 31, 2016 at 03:07:23PM +0100, Igor Mammedov wrote:
>> On Fri, 28 Oct 2016 23:48:06 -0200
>> Eduardo Habkost  wrote:
>> 
>> > When an abstract class is used on device-list-properties, we can
>> > simply return the class properties registered for the class.
>> > 
>> > This will be useful if management software needs to query for
>> > supported options that apply to all devices of a given type (e.g.
>> > options supported by all CPU models, options supported by all PCI
>> > devices).
>> Patch looks fine to me but I'm not qmp interface guru
>> so I'd leave review up to maintainers.
>> 
>> One question though,
>> How would management software discover typename of abstract class?
>
> It depends on the use case. On some cases, management may already
> have bus-specific logic that will know what's the base type it
> needs to query (e.g. it may query "pci-device" to find out if all
> PCI devices support a given option). On other cases, it may be
> discovered using other commands.

The stated purpose of this feature is to let management software "query
for supported options that apply to all devices of a given type".  I
suspect that when management software has a notion of "a given type", it
knows its name.

Will management software go fishing for subtype relationships beyond the
types it knows?  I doubt it.  Of course, management software developers
are welcome to educate me :)

> For the CPU case, I will propose adding the base QOM CPU typename
> in the query-target command.

Does this type name vary?  If yes, can you give examples?

>> Perhaps this patch should be part of some other series.
>
> This is a valid point. In this case, it depends on the approach
> we want to take: do we want to provide a flexible interface for
> management, let them find ways to make it useful and give us
> feedback on what is lacking; or do we want to provide the new
> interface only after we have specified the complete solution for
> the problem?
>
> I don't know the answer. I will let the qdev/QOM/QMP maintainers
> answer that.

I'm reluctant to add QMP features just because we think they might be
useful to someone.  We should talk to users to confirm our hunch before
we act on it.

That said, this one isn't exactly a biggie.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 2/5] s390: Report blank host model instead of "host"

[Jason J. Herne]

On 11/03/2016 08:54 AM, Jiri Denemark wrote:

On Wed, Nov 02, 2016 at 16:34:32 -0400, Jason J. Herne wrote:

From: "Collin L. Walling" 

On s390 , the host's features are heavily influenced by not only the host
hardware but also by hardware microcode level, host OS version, qemu
version and kvm version. In this environment it does not make sense to
attempt to report exact host details. Rather than use the generic "host"
we leave this field blank.

Signed-off-by: Collin L. Walling 
Signed-off-by: Jason J. Herne 
---
 src/cpu/cpu_s390.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/cpu/cpu_s390.c b/src/cpu/cpu_s390.c
index 0f94084..c75eacb 100644
--- a/src/cpu/cpu_s390.c
+++ b/src/cpu/cpu_s390.c
@@ -59,7 +59,7 @@ s390Decode(virCPUDefPtr cpu,
 virCheckFlags(VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES, -1);

 if (cpu->model == NULL &&
-VIR_STRDUP(cpu->model, "host") < 0)
+VIR_STRDUP(cpu->model, "") < 0)
 return -1;

 return 0;


I think this function shouldn't do anything. Reporting "host" or even ""
as host CPU is pointless. If we cannot provide anything reasonable, we
should not report it at all.


I would agree. But virsh domcapabilities only indicates support for 
host-model

mode if we have something in cpu->hostModel.

virDomainCapsCPUFormat()
...
if (cpu->hostModel) {
virBufferAddLit(buf, "supported='yes'>\n");

It also causes the guest to fail when trying to use host-model mode
because virQEMUCapsInitHostCPUModel() skips setting qemuCaps->hostCPUModel
if caps->host.cpu->model does not exist.

Using an empty string here fixes both. Should I stick with it, or should we
fix the problems elsewhere?

--
-- Jason J. Herne (jjhe...@linux.vnet.ibm.com)

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

[Daniel P. Berrange]

On Fri, Nov 04, 2016 at 09:05:49AM -0500, Eric Blake wrote:
> On 10/31/2016 07:41 AM, Daniel P. Berrange wrote:
> > The libvirt logo used a specific font with angled tops
> > to letters like "l", "b" and "t" - this is the "Overpass"
> > font, made available by Red Hat under an open source
> > font license. The re-branding makes use of webfont
> > support so that we can use this font across the entire
> > libvirt website for a consistent look.
> > 
> 
> The old logo used a visual effect on the letters - it looks like there
> is a horizontal line halfway through the logo, where the lower half of
> 'lib' and upper half of 'virt' has some sort of metallic-looking sheen.
> In the new logo, there is no effect at all.  Can you add that back?

I never really liked the sheen on the logo and couldn't figure out an
effective way to add it in inkscape so far, though I admit I didn't
try very hard since i didn't like it.

> Also, the old logo had a different kerning between 'rt' than the new
> logo, where it looks like the two letters are too close.

The fonts aren't exactly the same as the original and like wise using
inkscape instead of adobe illustrator, so its hard to get the exact
same layout. The kerning is unpleasant, but I've not been able to figure
out a good way to increase space between those two letters without
affecting the other letters too.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

[Eric Blake]

On 10/31/2016 07:41 AM, Daniel P. Berrange wrote:
> The libvirt logo used a specific font with angled tops
> to letters like "l", "b" and "t" - this is the "Overpass"
> font, made available by Red Hat under an open source
> font license. The re-branding makes use of webfont
> support so that we can use this font across the entire
> libvirt website for a consistent look.
> 

The old logo used a visual effect on the letters - it looks like there
is a horizontal line halfway through the logo, where the lower half of
'lib' and upper half of 'virt' has some sort of metallic-looking sheen.
In the new logo, there is no effect at all.  Can you add that back?
Also, the old logo had a different kerning between 'rt' than the new
logo, where it looks like the two letters are too close.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 04/17] docs: add footer to all pages

[Daniel P. Berrange]

On Fri, Nov 04, 2016 at 02:19:22PM +0100, Ján Tomko wrote:
> On Mon, Oct 31, 2016 at 12:41:45PM +, Daniel P. Berrange wrote:
> > Add a footer to all pages containing a blurb about the
> > code of conduct, and links to social media sites.
> > 
> > Signed-off-by: Daniel P. Berrange 
> > ---
> > docs/libvirt.css | 44 
> > docs/page.xsl| 12 
> > 2 files changed, 56 insertions(+)
> > 
> 
> > diff --git a/docs/page.xsl b/docs/page.xsl
> > index e3b8d5b..8f6a8c7 100644
> > --- a/docs/page.xsl
> > +++ b/docs/page.xsl
> > @@ -170,6 +170,18 @@
> > 
> >   
> > 
> > +
> > +  
> > +
> > +   > href="https://twitter.com/hashtag/libvirt;>twitter
> 
> This is essentially an ad for twitter. Unless they are sponsoring the
> project, it feels out of place here.

Errr, it is linking to libvirt related content people share on twitter.

> 
> > +   > href="https://plus.google.com/communities/109522598353007505282;>google 
> > plus
> 
> I presume that community is run by either you or some other libvirt 
> maintainer,
> which is what I would expect from such link.
> 
> > +   > href="http://stackoverflow.com/questions/tagged/libvirt;>stackoverflow
> 
> This feels like https://www.google.com/?q=libvirt;>google.

Stack overflow is much more targetted than a global websearch - it is
a user self-help forum, and the libvirt tag is directly relevant. 

Linking to related content on other community related sites is a very
relevant thing - libvirt does not exist in an island where everything
happens on websites run by ourselves. Encouraging engagement with libvirt
via these external social media sites is a key way to promote libvirt and
ensure our community grows over time.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 04/17] docs: add footer to all pages

[Ján Tomko]

On Mon, Oct 31, 2016 at 12:41:45PM +, Daniel P. Berrange wrote:

Add a footer to all pages containing a blurb about the
code of conduct, and links to social media sites.

Signed-off-by: Daniel P. Berrange 
---
docs/libvirt.css | 44 
docs/page.xsl| 12 
2 files changed, 56 insertions(+)




diff --git a/docs/page.xsl b/docs/page.xsl
index e3b8d5b..8f6a8c7 100644
--- a/docs/page.xsl
+++ b/docs/page.xsl
@@ -170,6 +170,18 @@

  

+
+  
+
+  https://twitter.com/hashtag/libvirt;>twitter


This is essentially an ad for twitter. Unless they are sponsoring the
project, it feels out of place here.


+  https://plus.google.com/communities/109522598353007505282;>google plus


I presume that community is run by either you or some other libvirt maintainer,
which is what I would expect from such link.


+  http://stackoverflow.com/questions/tagged/libvirt;>stackoverflow


This feels like https://www.google.com/?q=libvirt;>google.

Jan


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 12/17] docs: expand downloads page to cover all modules

[Ján Tomko]

On Mon, Oct 31, 2016 at 12:41:53PM +, Daniel P. Berrange wrote:

Previously the download page only covered the main libvirt
module and the app dev guide. Expand it to provide direct
links to all artifacts published by the project, whether
the main library, language bindings, docs, or testing.

Tweak the top table styling to better fit in with new
branding.

Signed-off-by: Daniel P. Berrange 
---
docs/downloads.html.in | 391 +++--
docs/libvirt.css   |  13 +-
2 files changed, 322 insertions(+), 82 deletions(-)

diff --git a/docs/downloads.html.in b/docs/downloads.html.in
index 1a3400a..374ccb0 100644
--- a/docs/downloads.html.in
+++ b/docs/downloads.html.in



+
+  
+
+  Module
+  Releases
+  GIT Repos


Would be nice to separate the official repo from the official mirrors:

GIT Repo
GIT Mirrors


+
+  
+



+Primary download site
+
+
+  Most modules have releases made available for download on the project
+  site, via FTP, HTTP or HTTPS. Some modules are instead made available
+  at alternative locations, for example, the Perl binding is made
+  available only on CPAN.



  ftp://libvirt.org/libvirt/;>libvirt.org FTP server
  http://libvirt.org/sources/;>libvirt.org HTTP server



+  http://libvirt.org/sources/;>libvirt.org HTTPS 
server


The link points to http:




Hourly development snapshots
@@ -35,23 +313,25 @@
Primary release schedule


-  Libvirt follows a time based plan, with releases made once a month
-  on the 1st of each month give or take a few days. The only exception
-  is at the start of the year where there are two 6 weeks gaps (first
-  release in the middle of Jan, then skip the Feb release), giving
-  a total of 11 releases a year.
+  The core libvirt module follows a time based plan, with releases made
+  once a month on the 1st of each month give or take a few days. The only#


Stray #


+  exception is at the start of the year where there are two 6 weeks gaps
+  (first release in the middle of Jan, then skip the Feb release), giving
+  a total of 11 releases a year. The Python and Perl modules will aim to
+  release at the same time as the core libvirt module. Other modules have
+  independant ad-hoc releases with no fixed time schedle.


Jan


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] qemu: Fix build on RHEL-6

[Peter Krempa]

On Fri, Nov 04, 2016 at 13:19:28 +0100, Jiri Denemark wrote:
> Commit c29e6d4805 cause build failure on RHEL-6:
> 
> ../../src/qemu/qemu_capabilities.c: In function 'virQEMUCapsIsValid':
> ../../src/qemu/qemu_capabilities.c:4085: error: declaration of 'ctime'
> shadows a global declaration [-Wshadow]
> /usr/include/time.h:258: error: shadowed declaration is here [-Wshadow]
> 
> Signed-off-by: Jiri Denemark 
> ---
>  src/qemu/qemu_capabilities.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

ACK


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 06/17] docs: add page describing contribution to libvirt

[Ján Tomko]

On Mon, Oct 31, 2016 at 12:41:47PM +, Daniel P. Berrange wrote:

Add a page that describes what contributions libvirt is
looking for and how to get involved.



Neat.


Signed-off-by: Daniel P. Berrange 
---
docs/contribute.html.in | 140 
1 file changed, 140 insertions(+)
create mode 100644 docs/contribute.html.in

diff --git a/docs/contribute.html.in b/docs/contribute.html.in
new file mode 100644
index 000..3686025
--- /dev/null
+++ b/docs/contribute.html.in



+  Translation. All the libvirt modules aim to support
+translations where appropriate. All translation is
+handling outside of the normal libvirt review process,
+using the http://fedora.zanata.org;>Fedora
+instance of the Zanata tool. Thus people wishing
+to contribution to translation should join the Fedora


s/contribution/contribute/

Maybe this bug can be closed then:
https://bugzilla.redhat.com/show_bug.cgi?id=672746


+translation tool


Jan


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 1/2] qemuDomainAttachNetDevice: Don't overwrite error on rollback

[Michal Privoznik]

If there is an error hotpluging a net device (for whatever
reason) a rollback operation is performed. However, whilst doing
so various helper functions that are called report errors on
their own. This results in the original error to be overwritten
and thus misleading the user.

Signed-off-by: Michal Privoznik 
---
 src/qemu/qemu_hotplug.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index e06862c..34f2135 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -935,6 +935,7 @@ qemuDomainAttachNetDevice(virQEMUDriverPtr driver,
   virDomainNetDefPtr net)
 {
 qemuDomainObjPrivatePtr priv = vm->privateData;
+virErrorPtr originalError = NULL;
 char **tapfdName = NULL;
 int *tapfd = NULL;
 size_t tapfdSize = 0;
@@ -1320,6 +1321,7 @@ qemuDomainAttachNetDevice(virQEMUDriverPtr driver,
 if (!virDomainObjIsActive(vm))
 goto cleanup;
 
+originalError = virSaveLastError();
 if (vlan < 0) {
 if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_NETDEV)) {
 char *netdev_name;
@@ -1350,6 +1352,8 @@ qemuDomainAttachNetDevice(virQEMUDriverPtr driver,
 ignore_value(qemuDomainObjExitMonitor(driver, vm));
 VIR_FREE(hostnet_name);
 }
+virSetError(originalError);
+virFreeError(originalError);
 goto cleanup;
 }
 
-- 
2.8.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 2/2] qemuDomainAttachNetDevice: Enable multiqueue for vhost-user

[Michal Privoznik]

https://bugzilla.redhat.com/show_bug.cgi?id=1386976

We have everything ready. Actually the only limitation was our
check that denied hotplug of vhost-user.

Signed-off-by: Michal Privoznik 
---
 src/qemu/qemu_hotplug.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 34f2135..a7dcf83 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -977,7 +977,8 @@ qemuDomainAttachNetDevice(virQEMUDriverPtr driver,
 !(actualType == VIR_DOMAIN_NET_TYPE_NETWORK ||
   actualType == VIR_DOMAIN_NET_TYPE_BRIDGE ||
   actualType == VIR_DOMAIN_NET_TYPE_DIRECT ||
-  actualType == VIR_DOMAIN_NET_TYPE_ETHERNET)) {
+  actualType == VIR_DOMAIN_NET_TYPE_ETHERNET ||
+  actualType == VIR_DOMAIN_NET_TYPE_VHOSTUSER)) {
 virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("Multiqueue network is not supported for: %s"),
virDomainNetTypeToString(actualType));
-- 
2.8.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 0/2] Allow hotplug of vhost-mq

[Michal Privoznik]

Basically this is trivial. Everything is prepared and the only
thing that prevented us from doing this was missing exception in
one check. Trivial.

Michal Privoznik (2):
  qemuDomainAttachNetDevice: Don't overwrite error on rollback
  qemuDomainAttachNetDevice: Enable multiqueue for vhost-user

 src/qemu/qemu_hotplug.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
2.8.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] qemu: Fix build on RHEL-6

[Jiri Denemark]

Commit c29e6d4805 cause build failure on RHEL-6:

../../src/qemu/qemu_capabilities.c: In function 'virQEMUCapsIsValid':
../../src/qemu/qemu_capabilities.c:4085: error: declaration of 'ctime'
shadows a global declaration [-Wshadow]
/usr/include/time.h:258: error: shadowed declaration is here [-Wshadow]

Signed-off-by: Jiri Denemark 
---
 src/qemu/qemu_capabilities.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index ffe7bcd..747226c 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -4082,12 +4082,12 @@ virQEMUCapsNewForBinary(virCapsPtr caps,
 
 bool
 virQEMUCapsIsValid(virQEMUCapsPtr qemuCaps,
-   time_t ctime)
+   time_t qemuctime)
 {
 if (!qemuCaps->binary)
 return true;
 
-if (!ctime) {
+if (!qemuctime) {
 struct stat sb;
 
 if (stat(qemuCaps->binary, ) < 0) {
@@ -4097,14 +4097,14 @@ virQEMUCapsIsValid(virQEMUCapsPtr qemuCaps,
   virStrerror(errno, ebuf, sizeof(ebuf)));
 return false;
 }
-ctime = sb.st_ctime;
+qemuctime = sb.st_ctime;
 }
 
-if (ctime != qemuCaps->ctime) {
+if (qemuctime != qemuCaps->ctime) {
 VIR_DEBUG("Outdated capabilities for '%s': QEMU binary changed "
   "(%lld vs %lld)",
   qemuCaps->binary,
-  (long long) ctime, (long long) qemuCaps->ctime);
+  (long long) qemuctime, (long long) qemuCaps->ctime);
 return false;
 }
 
-- 
2.10.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

[Daniel P. Berrange]

On Fri, Nov 04, 2016 at 12:09:30PM +0100, Martin Kletzander wrote:
> On Fri, Nov 04, 2016 at 10:17:18AM +0100, Peter Krempa wrote:
> > On Mon, Oct 31, 2016 at 12:41:41 +, Daniel Berrange wrote:
> > > The current libvirt website design dates from 2008 and
> > > has not changed significantly since. Compared to
> > > contemporary open source project websites it looks
> > > pretty dated and cluttered.
> > 
> > IMO dated is not that bad. Cluttered is the issue perhaps. Said this I
> > don't really like all the "modern" web pages, thus I'm biased.
> > 
> 
> True, you do, but you must also admit that this doesn't do most of the
> bad stuff "modern" pages do.  You definitely know what I'm talking
> about. ;)
> 
> > [...]
> > 
> > > The libvirt logo used a specific font with angled tops
> > > to letters like "l", "b" and "t" - this is the "Overpass"
> > > font, made available by Red Hat under an open source
> > > font license. The re-branding makes use of webfont
> > > support so that we can use this font across the entire
> > > libvirt website for a consistent look.
> > > 
> > > The colors of the website CSS now exactly match the
> > > colors used in the logo in most places.
> > 
> > +1
> > 
> > > The bigger change is in the layout, with the huge
> > > left hand sitemap nav bar being removed to give more
> > > space to the main content. The front page now directly
> > > links to the key pages that were shown to be highly
> > > visited in the apache web logs. Most of the rest of
> > > the links are now available from the "docs.html" page
> > > linked from "Learn" in the top nav bar.
> > 
> > I'm not a fan of this despite having monitors in portrait mode and thus
> > finally having the whole width with content.
> > 
> > What bothers me is that for navigation you can't select a different
> > section without opening the menu page (either by going back, or by
> > clicking on the "learn".
> > 
> 
> This might be an issue, but the bigger one I see in this is that there
> is no place on the front page (or anywhere rather) that says
> "Documentation".  "Learn" is very misleading for me.
> 
> > On the other hand I (and my favorities completion in my browser)
> > remember most of the pages I'm accessing, thus I'm not using the menu
> > anyways usually.
> > 
> > > Another key change is that the download page now
> > > covers all language bindings, test suites, docs
> > > released by the project, not merely the core C
> > > library.
> > > 
> > > Finally a new page "contribute.html" is added as the
> > > source of information useful to people wishing to get
> > > involved in the libvirt project.
> > > 
> > > View the new site here
> > > 
> > > https://berrange.fedorapeople.org/libvirt-new-website/
> > > 
> > > Note that the front page includes a feed of 4 most
> > > recent blog posts, however, if visiting over https://
> > > this will be blocked by browsers. In firefox you
> > > can tell it to allow http:// content temporarily
> > > at which point the feed will appear. I'll be doing
> > > a proper fix by getting a TLS cert for virt-tools.org
> > > website setup.
> > 
> > In this new design all the XML snippets and other stuff enclosed in
> >  in the source is not in a monospace font any more, which is
> > terrible.
> > 
> > Additionally I don't quite like sans-serif fonts for big blocks of
> > texts, but the old page was not better in this aspect. I'd be in favor
> > of changing to a serif font.
> > 
> 
> Serif is meant for paper, monitors should show Sans-Serif.  And I'm not
> saying it just because I like it that way, but as it is supposed to be
> like that.  Not all might like it, though.

More specifically, serif is meant for high resolution mediums. So serif
might be practical for Hi-DPI monitors, but not for traditional bad-DPI
monitors that the majority of us suffer with :-(

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

[Martin Kletzander]

On Fri, Nov 04, 2016 at 10:17:18AM +0100, Peter Krempa wrote:

On Mon, Oct 31, 2016 at 12:41:41 +, Daniel Berrange wrote:

The current libvirt website design dates from 2008 and
has not changed significantly since. Compared to
contemporary open source project websites it looks
pretty dated and cluttered.


IMO dated is not that bad. Cluttered is the issue perhaps. Said this I
don't really like all the "modern" web pages, thus I'm biased.



True, you do, but you must also admit that this doesn't do most of the
bad stuff "modern" pages do.  You definitely know what I'm talking
about. ;)


[...]


The libvirt logo used a specific font with angled tops
to letters like "l", "b" and "t" - this is the "Overpass"
font, made available by Red Hat under an open source
font license. The re-branding makes use of webfont
support so that we can use this font across the entire
libvirt website for a consistent look.

The colors of the website CSS now exactly match the
colors used in the logo in most places.


+1


The bigger change is in the layout, with the huge
left hand sitemap nav bar being removed to give more
space to the main content. The front page now directly
links to the key pages that were shown to be highly
visited in the apache web logs. Most of the rest of
the links are now available from the "docs.html" page
linked from "Learn" in the top nav bar.


I'm not a fan of this despite having monitors in portrait mode and thus
finally having the whole width with content.

What bothers me is that for navigation you can't select a different
section without opening the menu page (either by going back, or by
clicking on the "learn".



This might be an issue, but the bigger one I see in this is that there
is no place on the front page (or anywhere rather) that says
"Documentation".  "Learn" is very misleading for me.


On the other hand I (and my favorities completion in my browser)
remember most of the pages I'm accessing, thus I'm not using the menu
anyways usually.


Another key change is that the download page now
covers all language bindings, test suites, docs
released by the project, not merely the core C
library.

Finally a new page "contribute.html" is added as the
source of information useful to people wishing to get
involved in the libvirt project.

View the new site here

https://berrange.fedorapeople.org/libvirt-new-website/

Note that the front page includes a feed of 4 most
recent blog posts, however, if visiting over https://
this will be blocked by browsers. In firefox you
can tell it to allow http:// content temporarily
at which point the feed will appear. I'll be doing
a proper fix by getting a TLS cert for virt-tools.org
website setup.


In this new design all the XML snippets and other stuff enclosed in
 in the source is not in a monospace font any more, which is
terrible.

Additionally I don't quite like sans-serif fonts for big blocks of
texts, but the old page was not better in this aspect. I'd be in favor
of changing to a serif font.



Serif is meant for paper, monitors should show Sans-Serif.  And I'm not
saying it just because I like it that way, but as it is supposed to be
like that.  Not all might like it, though.


Overall I don't disagree with this as long as the XML and code snippets
stay in a monospace font.

Peter






--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

[Daniel P. Berrange]

On Fri, Nov 04, 2016 at 11:44:03AM +0100, Martin Kletzander wrote:
> On Fri, Nov 04, 2016 at 09:43:00AM +0100, Erik Skultety wrote:
> > On Thu, Nov 03, 2016 at 04:13:11PM +, Daniel P. Berrange wrote:
> > > On Thu, Nov 03, 2016 at 03:25:55PM +, Daniel P. Berrange wrote:
> > > >
> > > > The bluriness is caused by inkscape anti-aliasing the font when
> > > > exporting the SVG to PNG. I'll see if I can find any inkscape
> > > > options to reduce this anti-aliasing, or perhaps try a different
> > > > tool for the PNG export.
> > > 
> > > [snip]
> > > 
> > > >   https://berrange.fedorapeople.org/libvirt-new-website-heavy/
> > > 
> > > I've also made this version of the website show a completely
> > > non-anti-aliased version of the logo banner. It certanly
> > > does look "crisper" - only downside is the jagged edges on
> > > the penguins, but I think on balance it is still better.
> > > 
> > > 
> > 
> > Soo much better, I also like the bigger contrast of the regular OverPass 
> > font.
> > One little detail though, did you also change the font size of the three
> > Section links in the top panel (Download, Contribute, Learn)? Because it 
> > looks
> > like it and I liked the size of those in the 'Light' version more. 
> > Otherwise,
> 
> We'll probably have to agree to disagree on that, the heavier fits the
> rest of the page more, IMHO.
> 
> > great. Oh, I almost forgot, any plans on extending the plain XML 
> > configuration
> > page, so it might be less empty?
> > 
> 
> And I totally forgot.  That was one of the first things I clicked and
> wondered what's supposed to be there =)
> 
> Also, two more things:
> 
> 1)  should have monospace font inside it

Yes, same mistake as with 

> 2) Wiki should use the same (or similar) design

Yes, since we seem to have agreement of this proposal, I'll prepare a
wiki style update to match, before pushing this, so we have consistent
style between the two at all times.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

[Martin Kletzander]

On Fri, Nov 04, 2016 at 09:43:00AM +0100, Erik Skultety wrote:

On Thu, Nov 03, 2016 at 04:13:11PM +, Daniel P. Berrange wrote:

On Thu, Nov 03, 2016 at 03:25:55PM +, Daniel P. Berrange wrote:
>
> The bluriness is caused by inkscape anti-aliasing the font when
> exporting the SVG to PNG. I'll see if I can find any inkscape
> options to reduce this anti-aliasing, or perhaps try a different
> tool for the PNG export.

[snip]

>   https://berrange.fedorapeople.org/libvirt-new-website-heavy/

I've also made this version of the website show a completely
non-anti-aliased version of the logo banner. It certanly
does look "crisper" - only downside is the jagged edges on
the penguins, but I think on balance it is still better.




Soo much better, I also like the bigger contrast of the regular OverPass font.
One little detail though, did you also change the font size of the three
Section links in the top panel (Download, Contribute, Learn)? Because it looks
like it and I liked the size of those in the 'Light' version more. Otherwise,


We'll probably have to agree to disagree on that, the heavier fits the
rest of the page more, IMHO.


great. Oh, I almost forgot, any plans on extending the plain XML configuration
page, so it might be less empty?



And I totally forgot.  That was one of the first things I clicked and
wondered what's supposed to be there =)

Also, two more things:

1)  should have monospace font inside it

2) Wiki should use the same (or similar) design


Erik



Regards,
Daniel
--
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 6/8] qemu: Unify cached caps validity checks

[Daniel P. Berrange]

On Wed, Nov 02, 2016 at 10:22:35AM +0100, Jiri Denemark wrote:
> Let's keep all run time validation of cached QEMU capabilities in
> virQEMUCapsIsValid and call it whenever we access the cache.
> virQEMUCapsInitCached should keep only the checks which do not make
> sense once the cache is loaded in memory.
> 
> Signed-off-by: Jiri Denemark 
> ---
>  src/qemu/qemu_capabilities.c | 59 
> ++--
>  src/qemu/qemu_capabilities.h |  3 ++-
>  2 files changed, 42 insertions(+), 20 deletions(-)
> 
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index 91e8b30..d1c31ad 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -3516,25 +3516,21 @@ virQEMUCapsInitCached(virCapsPtr caps,
>  VIR_WARN("Failed to load cached caps from '%s' for '%s': %s",
>   capsfile, qemuCaps->binary, virGetLastErrorMessage());
>  virResetLastError();
> -ret = 0;
> -virQEMUCapsReset(qemuCaps);
> -goto cleanup;
> +goto discard;
>  }
>  
> +if (!virQEMUCapsIsValid(qemuCaps, qemuctime))
> +goto discard;
> +
>  /* Discard cache if QEMU binary or libvirtd changed */
> -if (qemuctime != qemuCaps->ctime ||
> -selfctime != virGetSelfLastChanged() ||
> +if (selfctime != virGetSelfLastChanged() ||
>  selfvers != LIBVIR_VERSION_NUMBER) {
> -VIR_DEBUG("Outdated cached capabilities '%s' for '%s' "
> -  "(%lld vs %lld, %lld vs %lld, %lu vs %lu)",
> +VIR_DEBUG("Dropping cached capabilities '%s' for '%s': "
> +  "libvirt changed (%lld vs %lld, %lu vs %lu)",
>capsfile, qemuCaps->binary,
> -  (long long)qemuCaps->ctime, (long long)qemuctime,
>(long long)selfctime, (long long)virGetSelfLastChanged(),
>selfvers, (unsigned long)LIBVIR_VERSION_NUMBER);
> -ignore_value(unlink(capsfile));
> -virQEMUCapsReset(qemuCaps);
> -ret = 0;
> -goto cleanup;
> +goto discard;
>  }
>  
>  VIR_DEBUG("Loaded '%s' for '%s' ctime %lld usedQMP=%d",
> @@ -3548,6 +3544,12 @@ virQEMUCapsInitCached(virCapsPtr caps,
>  VIR_FREE(capsfile);
>  VIR_FREE(capsdir);
>  return ret;
> +
> + discard:
> +ignore_value(unlink(capsfile));
> +virQEMUCapsReset(qemuCaps);
> +ret = 0;
> +goto cleanup;
>  }
>  
>  
> @@ -4111,17 +4113,36 @@ virQEMUCapsNewForBinary(virCapsPtr caps,
>  }
>  
>  
> -bool virQEMUCapsIsValid(virQEMUCapsPtr qemuCaps)
> +bool
> +virQEMUCapsIsValid(virQEMUCapsPtr qemuCaps,
> +   time_t ctime)

This broke the build on RHEL-6


c1: warnings being treated as errors
../../src/qemu/qemu_capabilities.c: In function 'virQEMUCapsIsValid':
../../src/qemu/qemu_capabilities.c:4085: error: declaration of 'ctime' shadows 
a global declaration [-Wshadow]
/usr/include/time.h:258: error: shadowed declaration is here [-Wshadow]


We should just call this qemuctime, as done elsewhere to avoid the
clash.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [libvirt-glib] tests: Don't leak xml data in test-gconfig-device-unknown

[Daniel P. Berrange]

On Fri, Nov 04, 2016 at 11:15:01AM +0100, Christophe Fergeau wrote:
> ---
>  tests/test-gconfig.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tests/test-gconfig.c b/tests/test-gconfig.c
> index 9cf3f12..2c98c25 100644
> --- a/tests/test-gconfig.c
> +++ b/tests/test-gconfig.c
> @@ -782,6 +782,7 @@ static void test_domain_device_unknown(void)
>  
>  g_list_free_full(devices, g_object_unref);
>  g_object_unref(G_OBJECT(domain));
> +g_free(xml);
>  }

ACK

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 00/19] Avoid races with udev

[Daniel P. Berrange]

On Fri, Nov 04, 2016 at 08:48:06AM +0100, Michal Privoznik wrote:
> On 03.11.2016 13:33, Daniel P. Berrange wrote:
> > On Thu, Nov 03, 2016 at 08:18:50PM +0800, Michal Privoznik wrote:
> >> This is v2 of:
> >>
> >> https://www.redhat.com/archives/libvir-list/2016-October/msg01151.html
> >>
> >> diff to v1:
> >> - Added udev rule (patch 18/19)
> >> - Wire the beast into spec file
> >> - Introduced a configure argument that suppress installation of this 
> >> feature
> >>
> >> One of the problems here is that this requires patched udev:
> >>
> >> https://github.com/systemd/systemd/commit/4f985bd80278972912b80df1390f84d7a89f8d51
> >>
> >> This is going to be part of systemd-232 release. Therefore, in my code 
> >> I've put
> >> checks for 232 version.
> > 
> > As discussed on the previous posting, this series is still race prone as
> > this doesn't stop udev changing the labels on devices managed by libvirt.
> > It merely causes udev to change them, and then change them back again.
> 
> True. But I guess the problem there is udev guys don't want others to
> store anything in their DB. So while this is not entirely race free it
> makes situation better, doesn't it. But I guess the best would be to ask
> them directly so everybody can see what's going on. I've sent the e-mail
> here:
> 
> https://lists.freedesktop.org/archives/systemd-devel/2016-November/037714.html
> 
> > 
> > IMHO if we're going to require an unreleased udev, then we should work to
> > get an enhancement to udev so that we can avoid this relabelling entirely
> > and thus fully fix the race problem.
> 
> Again, question is whether udev guys are willing to make their SW to
> waive its 'privileged' position of managing all the devices. If they are
> not, we can't avoid the race but we can at least minimize the window
> where the race is possible.

FWIW, a (probably insane) alternative idea is to take udev out of the
picture entirely by setting up a libvirt private /var/run/libvirt/dev
directory and running mknod in the and pointing QEMU to the path
/var/run/libvirt/dev/sda instead of /dev/sda.

In fact a more serious approach is that we could actually start to make
use of container namespaces to confine QEMU. ie start a new mount namespace
for each QEMU process with a new /dev tmpfs mounted on that. We just mknod
the few dev nodes that QEMU needs access to. This gives us security benefits
as well as taking udev out of the picture.

> BTW: as of yesterday late night "unreleased systemd" statement is no
> longer true. Lennart made a release, so udev behaviour this patch set
> relies on is now officially supported.

Right, but no distro is going to have that version for a long while
yet, so if we did have to wait for another udev release later, we not
any worse off.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

[Daniel P. Berrange]

On Fri, Nov 04, 2016 at 09:43:00AM +0100, Erik Skultety wrote:
> On Thu, Nov 03, 2016 at 04:13:11PM +, Daniel P. Berrange wrote:
> > On Thu, Nov 03, 2016 at 03:25:55PM +, Daniel P. Berrange wrote:
> > > 
> > > The bluriness is caused by inkscape anti-aliasing the font when
> > > exporting the SVG to PNG. I'll see if I can find any inkscape
> > > options to reduce this anti-aliasing, or perhaps try a different
> > > tool for the PNG export.
> > 
> > [snip]
> > 
> > >   https://berrange.fedorapeople.org/libvirt-new-website-heavy/
> > 
> > I've also made this version of the website show a completely
> > non-anti-aliased version of the logo banner. It certanly
> > does look "crisper" - only downside is the jagged edges on
> > the penguins, but I think on balance it is still better.
> > 
> > 
> 
> Soo much better, I also like the bigger contrast of the regular OverPass font.
> One little detail though, did you also change the font size of the three
> Section links in the top panel (Download, Contribute, Learn)? Because it looks
> like it and I liked the size of those in the 'Light' version more. Otherwise,

No change in size, but it just seems the metrics of the two font variants are
slightly different, so they come out a slightly different size.

> great. Oh, I almost forgot, any plans on extending the plain XML configuration
> page, so it might be less empty?

I've not considered that yet, but we should do something there.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

[Daniel P. Berrange]

On Fri, Nov 04, 2016 at 10:17:18AM +0100, Peter Krempa wrote:
> > The bigger change is in the layout, with the huge
> > left hand sitemap nav bar being removed to give more
> > space to the main content. The front page now directly
> > links to the key pages that were shown to be highly
> > visited in the apache web logs. Most of the rest of
> > the links are now available from the "docs.html" page
> > linked from "Learn" in the top nav bar.
> 
> I'm not a fan of this despite having monitors in portrait mode and thus
> finally having the whole width with content.
> 
> What bothers me is that for navigation you can't select a different
> section without opening the menu page (either by going back, or by
> clicking on the "learn".

FWIW, based on the web access stats, the number of clicks required
to access the most commonly pages is down with this new design.
For example, accessing domain XML page used to take 3 clicks in
the nav bar (Docs -> Format -> XML Format), but is now 1 click
from the index page. For the bulk of content that used to be under
the 'Docs' entry in the nav bar, the number of clicks is either
the same, or reduced.

What has increased is number of clicks if you want to switch back
and forth between domain XML & network XML & storage XML, but I
don't believe that is a common pattern. We could still optimize
that if desired though, but having each XML page have a menu of
links to other XML pages. I'm not seeing that as a key problem
though

> 
> On the other hand I (and my favorities completion in my browser)
> remember most of the pages I'm accessing, thus I'm not using the menu
> anyways usually.
> 
> > Another key change is that the download page now 
> > covers all language bindings, test suites, docs
> > released by the project, not merely the core C
> > library.
> > 
> > Finally a new page "contribute.html" is added as the
> > source of information useful to people wishing to get
> > involved in the libvirt project.
> > 
> > View the new site here
> > 
> > https://berrange.fedorapeople.org/libvirt-new-website/
> > 
> > Note that the front page includes a feed of 4 most
> > recent blog posts, however, if visiting over https://
> > this will be blocked by browsers. In firefox you
> > can tell it to allow http:// content temporarily
> > at which point the feed will appear. I'll be doing
> > a proper fix by getting a TLS cert for virt-tools.org
> > website setup.
> 
> In this new design all the XML snippets and other stuff enclosed in
>  in the source is not in a monospace font any more, which is
> terrible.

Yeah, that's clearly a mistake - it should have remained monospace
for sure.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [libvirt-glib] tests: Don't leak xml data in test-gconfig-device-unknown

[Christophe Fergeau]

---
 tests/test-gconfig.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/test-gconfig.c b/tests/test-gconfig.c
index 9cf3f12..2c98c25 100644
--- a/tests/test-gconfig.c
+++ b/tests/test-gconfig.c
@@ -782,6 +782,7 @@ static void test_domain_device_unknown(void)
 
 g_list_free_full(devices, g_object_unref);
 g_object_unref(G_OBJECT(domain));
+g_free(xml);
 }
 
 
-- 
2.9.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v3] [glib 5/5] gconfig, tests: Add test case for unknown devices

[Zeeshan Ali]

On Thu, Nov 3, 2016 at 4:31 PM, Christophe Fergeau  wrote:
> On Thu, Nov 03, 2016 at 02:40:58PM +0100, Zeeshan Ali wrote:
>> ---
>>  tests/test-gconfig.c| 24 
>>  tests/xml/gconfig-domain-device-unknown.xml |  5 +
>>  2 files changed, 29 insertions(+)
>>  create mode 100644 tests/xml/gconfig-domain-device-unknown.xml
>>
>> diff --git a/tests/test-gconfig.c b/tests/test-gconfig.c
>> index 5389a26..685cf97 100644
>> --- a/tests/test-gconfig.c
>> +++ b/tests/test-gconfig.c
>> @@ -762,6 +762,28 @@ static void test_domain_device_pci_hostdev(void)
>>  g_object_unref(G_OBJECT(domain));
>>  }
>>
>> +static void test_domain_device_unknown(void)
>> +{
>> +GVirConfigDomain *domain;
>> +GList *devices;
>> +GError *error = NULL;
>> +char *xml;
>> +
>> +xml = load_xml("gconfig-domain-device-unknown.xml");
>> +
>> +domain = gvir_config_domain_new_from_xml(xml, );
>> +g_assert_no_error(error);
>> +
>> +devices = gvir_config_domain_get_devices(domain);
>> +g_assert_nonnull(devices);
>
>
> + gvir_config_domain_set_devices(domain, devices);

Ah yes. Fixed that (and adjusted the test xml), pushed the series.

Thanks.

-- 
Regards,

Zeeshan Ali

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] docs: Add Qt Virtual machines manager and Qt Remote viewer

[Michal Privoznik]

On 03.11.2016 13:44, Alexander Vasilenko wrote:
> ---
>  docs/apps.html.in | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/docs/apps.html.in b/docs/apps.html.in
> index 1a138b3..4efb318 100644
> --- a/docs/apps.html.in
> +++ b/docs/apps.html.in
> @@ -208,6 +208,17 @@
>  to remote consoles supporting the VNC protocol. Also provides
>  an optional mozilla browser plugin.
>
> +   href="http://f1ash.github.io/qt-virt-manager;>qt-virt-manager
> +  
> +The Qt GUI for create and control VMs and another virtual entities
> +(aka networks, storages, interfaces, secrets, network filters).
> +Contains integrated LXC/SPICE/VNC viewer for accessing the graphical 
> or
> +text console associated with a virtual machine or container.
> +  
> +   href="http://f1ash.github.io/qt-virt-manager/#virtual-machines-viewer;>qt-remote-viewer
> +  
> +The Qt VNC/SPICE viewer for access to remote desktops or VMs.
> +  
>  
>  
>  Infrastructure as a Service (IaaS)
> 

Oh, this is nice. Let me see if I can get the package into Gentoo too.

ACKed and pushed.
Congratulations on your first libvirt contribution.

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] vshReadlineParse: Remove unused variable

[Peter Krempa]

On Fri, Nov 04, 2016 at 09:58:53 +0100, Michal Privoznik wrote:
> After 06a7b1ff4 the @_need_arg is not used anywhere. Well,
> it is set but never read:
> 
> vsh.c: In function 'vshReadlineParse':
> vsh.c:2658:14: warning: variable 'opts_need_arg' set but not used 
> [-Wunused-but-set-variable]
>  uint64_t opts_need_arg, opts_seen;
>   ^
> 
> Signed-off-by: Michal Privoznik 
> ---
>  tools/vsh.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

How about removing the complete function given it's history?

Consider this as an ACK though.


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

[Peter Krempa]

On Mon, Oct 31, 2016 at 12:41:41 +, Daniel Berrange wrote:
> The current libvirt website design dates from 2008 and
> has not changed significantly since. Compared to
> contemporary open source project websites it looks
> pretty dated and cluttered.

IMO dated is not that bad. Cluttered is the issue perhaps. Said this I
don't really like all the "modern" web pages, thus I'm biased.

[...]

> The libvirt logo used a specific font with angled tops
> to letters like "l", "b" and "t" - this is the "Overpass"
> font, made available by Red Hat under an open source
> font license. The re-branding makes use of webfont
> support so that we can use this font across the entire
> libvirt website for a consistent look.
> 
> The colors of the website CSS now exactly match the
> colors used in the logo in most places.

+1

> The bigger change is in the layout, with the huge
> left hand sitemap nav bar being removed to give more
> space to the main content. The front page now directly
> links to the key pages that were shown to be highly
> visited in the apache web logs. Most of the rest of
> the links are now available from the "docs.html" page
> linked from "Learn" in the top nav bar.

I'm not a fan of this despite having monitors in portrait mode and thus
finally having the whole width with content.

What bothers me is that for navigation you can't select a different
section without opening the menu page (either by going back, or by
clicking on the "learn".

On the other hand I (and my favorities completion in my browser)
remember most of the pages I'm accessing, thus I'm not using the menu
anyways usually.

> Another key change is that the download page now 
> covers all language bindings, test suites, docs
> released by the project, not merely the core C
> library.
> 
> Finally a new page "contribute.html" is added as the
> source of information useful to people wishing to get
> involved in the libvirt project.
> 
> View the new site here
> 
> https://berrange.fedorapeople.org/libvirt-new-website/
> 
> Note that the front page includes a feed of 4 most
> recent blog posts, however, if visiting over https://
> this will be blocked by browsers. In firefox you
> can tell it to allow http:// content temporarily
> at which point the feed will appear. I'll be doing
> a proper fix by getting a TLS cert for virt-tools.org
> website setup.

In this new design all the XML snippets and other stuff enclosed in
 in the source is not in a monospace font any more, which is
terrible.

Additionally I don't quite like sans-serif fonts for big blocks of
texts, but the old page was not better in this aspect. I'd be in favor
of changing to a serif font.

Overall I don't disagree with this as long as the XML and code snippets
stay in a monospace font.

Peter



signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

[Michal Privoznik]

On 03.11.2016 17:13, Daniel P. Berrange wrote:
> On Thu, Nov 03, 2016 at 03:25:55PM +, Daniel P. Berrange wrote:
>>
>> The bluriness is caused by inkscape anti-aliasing the font when
>> exporting the SVG to PNG. I'll see if I can find any inkscape
>> options to reduce this anti-aliasing, or perhaps try a different
>> tool for the PNG export.
> 
> [snip]
> 
>>   https://berrange.fedorapeople.org/libvirt-new-website-heavy/

Yes, I like this one better than the previous one.
Kudos for rolling up your sleeves and working on it.
(Consider this as ACK).

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] vshReadlineParse: Remove unused variable

[Michal Privoznik]

After 06a7b1ff4 the @_need_arg is not used anywhere. Well,
it is set but never read:

vsh.c: In function 'vshReadlineParse':
vsh.c:2658:14: warning: variable 'opts_need_arg' set but not used 
[-Wunused-but-set-variable]
 uint64_t opts_need_arg, opts_seen;
  ^

Signed-off-by: Michal Privoznik 
---
 tools/vsh.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/vsh.c b/tools/vsh.c
index 17199ae..f7ba070 100644
--- a/tools/vsh.c
+++ b/tools/vsh.c
@@ -2655,7 +2655,7 @@ vshReadlineParse(const char *text, int state)
 static char **completed_list;
 static unsigned int completed_list_index;
 static uint64_t const_opts_need_arg, const_opts_required, const_opts_seen;
-uint64_t opts_need_arg, opts_seen;
+uint64_t opts_seen;
 size_t opt_index;
 static bool cmd_exists, opts_filled, opt_exists;
 static bool non_bool_opt_exists, data_complete;
@@ -2728,7 +2728,6 @@ vshReadlineParse(const char *text, int state)
 if (vshCmddefOptParse(cmd, _opts_need_arg,
   _opts_required) < 0)
 goto error;
-opts_need_arg = const_opts_need_arg;
 opts_seen = const_opts_seen;
 opts_filled = true;
 } else if (tkdata[0] == '-' && tkdata[1] == '-' &&
@@ -2793,7 +2792,6 @@ vshReadlineParse(const char *text, int state)
 || opt->type == VSH_OT_BOOL)
 goto error;
 opt_exists = true;
-opts_need_arg = const_opts_need_arg;
 opts_seen = const_opts_seen;
 } else {
 /* In every other case, return NULL */
-- 
2.8.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 00/17] Redo website layout and branding

[Erik Skultety]

On Thu, Nov 03, 2016 at 04:13:11PM +, Daniel P. Berrange wrote:
> On Thu, Nov 03, 2016 at 03:25:55PM +, Daniel P. Berrange wrote:
> > 
> > The bluriness is caused by inkscape anti-aliasing the font when
> > exporting the SVG to PNG. I'll see if I can find any inkscape
> > options to reduce this anti-aliasing, or perhaps try a different
> > tool for the PNG export.
> 
> [snip]
> 
> >   https://berrange.fedorapeople.org/libvirt-new-website-heavy/
> 
> I've also made this version of the website show a completely
> non-anti-aliased version of the logo banner. It certanly
> does look "crisper" - only downside is the jagged edges on
> the penguins, but I think on balance it is still better.
> 
> 

Soo much better, I also like the bigger contrast of the regular OverPass font.
One little detail though, did you also change the font size of the three
Section links in the top panel (Download, Contribute, Learn)? Because it looks
like it and I liked the size of those in the 'Light' version more. Otherwise,
great. Oh, I almost forgot, any plans on extending the plain XML configuration
page, so it might be less empty?

Erik


> Regards,
> Daniel
> -- 
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
> 
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 6/8] qemu: Unify cached caps validity checks

[Jiri Denemark]

On Thu, Nov 03, 2016 at 16:37:59 +0100, Pavel Hrdina wrote:
> On Wed, Nov 02, 2016 at 10:22:35AM +0100, Jiri Denemark wrote:
> > Let's keep all run time validation of cached QEMU capabilities in
> > virQEMUCapsIsValid and call it whenever we access the cache.
> > virQEMUCapsInitCached should keep only the checks which do not make
> > sense once the cache is loaded in memory.
> > 
> > Signed-off-by: Jiri Denemark 
> > ---
> >  src/qemu/qemu_capabilities.c | 59 
> > ++--
> >  src/qemu/qemu_capabilities.h |  3 ++-
> >  2 files changed, 42 insertions(+), 20 deletions(-)
..
> > +return false;
> > +}
> > +ctime = sb.st_ctime;
> > +}
> > +
> > +if (ctime != qemuCaps->ctime) {
> > +VIR_DEBUG("Dropping cached capabilities for '%s': "
> > +  "binary is newer than cache (%lld vs %lld)",
> > +  qemuCaps->binary,
> > +  (long long) ctime, (long long) qemuCaps->ctime);
> 
> ... same here.  This function doesn't drop the capabilities.
> 
> ACK, the suggested change is only for debug logs so I'll leave it up to you,
> but it would be cleaner :)

Yeah, the suggested changes make sense. I moved the "Dropping..."
message to the place where we actually drop the cache and pushed the
result.

Thanks,

Jirka

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 5/8] qemu: Store loaded QEMU binary ctime in qemuCaps

[Jiri Denemark]

On Thu, Nov 03, 2016 at 16:15:39 +0100, Pavel Hrdina wrote:
> On Wed, Nov 02, 2016 at 10:22:34AM +0100, Jiri Denemark wrote:
> > virQEMUCapsLoadCache loads QEMU capabilities from a file, but strangely
> > enough it returns the loaded QEMU binary ctime in qemuctime parameter
> > instead of storing it in qemuCaps.
> > 
> > Signed-off-by: Jiri Denemark 
> > ---
> >  src/qemu/qemu_capabilities.c | 10 +-
> >  src/qemu/qemu_capspriv.h |  1 -
> >  tests/testutilsqemu.c|  3 +--
> >  3 files changed, 6 insertions(+), 8 deletions(-)
> 
> ACK

Thanks, pushed.

Jirka

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] qemu: Allow use of hot plugged host CPUs if no affinity set

[Viktor Mihajlovski]

Running VMs couldn't use newly hot plugged host CPUs even if the VMs
had no CPU pinning defined AND the cpuset controller was disabled in
the libvirt qemu configuration.
This was because in this case the process affinity was set by libvirt
to all currently present host CPUs in order to avoid situations, where
libvirtd was deliberately running on a CPU subset and thus the spawned
VMs would be involuntarily restricted to the CPU subset inherited by
libvirtd.
That however prevents new host CPUs to be utilized when they show up.
With this change we will NOT set the VM's affinity mask if it
matches the online host CPU mask.

There's still the chance that for some reason the deliberately chosen
libvirtd affinity matches the online host CPU mask by accident. In this
case the behavior remains as it was before (CPUs offline while setting
the affinity will not be used if they show up later on).

Signed-off-by: Viktor Mihajlovski 
Tested-by: Matthew Rosato 
---
 src/qemu/qemu_process.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 1b67aee..76f9210 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -2202,6 +2202,7 @@ qemuProcessInitCpuAffinity(virDomainObjPtr vm)
 int ret = -1;
 virBitmapPtr cpumap = NULL;
 virBitmapPtr cpumapToSet = NULL;
+virBitmapPtr hostcpumap = NULL;
 qemuDomainObjPrivatePtr priv = vm->privateData;
 
 if (!vm->pid) {
@@ -2223,6 +2224,16 @@ qemuProcessInitCpuAffinity(virDomainObjPtr vm)
  * the spawned QEMU instance to all pCPUs if no map is given in
  * its config file */
 int hostcpus;
+hostcpumap = virHostCPUGetOnlineBitmap();
+cpumap = virProcessGetAffinity(vm->pid);
+
+if (hostcpumap && cpumap && virBitmapEqual(hostcpumap, cpumap)) {
+/* we're using all available CPUs, no reason to set
+ * mask. If libvirtd is running without explicit
+ * affinity, we can use hotplugged CPUs for this VM */
+ret = 0;
+goto cleanup;
+}
 
 /* setaffinity fails if you set bits for CPUs which
  * aren't present, so we have to limit ourselves */
@@ -2248,6 +2259,7 @@ qemuProcessInitCpuAffinity(virDomainObjPtr vm)
 
  cleanup:
 virBitmapFree(cpumap);
+virBitmapFree(hostcpumap);
 return ret;
 }
 
-- 
1.9.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2 00/19] Avoid races with udev

[Michal Privoznik]

On 03.11.2016 13:33, Daniel P. Berrange wrote:
> On Thu, Nov 03, 2016 at 08:18:50PM +0800, Michal Privoznik wrote:
>> This is v2 of:
>>
>> https://www.redhat.com/archives/libvir-list/2016-October/msg01151.html
>>
>> diff to v1:
>> - Added udev rule (patch 18/19)
>> - Wire the beast into spec file
>> - Introduced a configure argument that suppress installation of this feature
>>
>> One of the problems here is that this requires patched udev:
>>
>> https://github.com/systemd/systemd/commit/4f985bd80278972912b80df1390f84d7a89f8d51
>>
>> This is going to be part of systemd-232 release. Therefore, in my code I've 
>> put
>> checks for 232 version.
> 
> As discussed on the previous posting, this series is still race prone as
> this doesn't stop udev changing the labels on devices managed by libvirt.
> It merely causes udev to change them, and then change them back again.

True. But I guess the problem there is udev guys don't want others to
store anything in their DB. So while this is not entirely race free it
makes situation better, doesn't it. But I guess the best would be to ask
them directly so everybody can see what's going on. I've sent the e-mail
here:

https://lists.freedesktop.org/archives/systemd-devel/2016-November/037714.html

> 
> IMHO if we're going to require an unreleased udev, then we should work to
> get an enhancement to udev so that we can avoid this relabelling entirely
> and thus fully fix the race problem.

Again, question is whether udev guys are willing to make their SW to
waive its 'privileged' position of managing all the devices. If they are
not, we can't avoid the race but we can at least minimize the window
where the race is possible.

BTW: as of yesterday late night "unreleased systemd" statement is no
longer true. Lennart made a release, so udev behaviour this patch set
relies on is now officially supported.

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] How to make udev not touch my device?

[Michal Privoznik]

Hey udev developers,

I'm a libvirt developer and I've been facing an interesting issue
recently. Libvirt is a library for managing virtual machines and as such
allows basically any device to be exposed to a virtual machine. For
instance, a virtual machine can use /dev/sdX as its own disk. Because of
security reasons we allow users to configure their VMs to run under
different UID/GID and also SELinux context. That means that whenever a
VM is being started up, libvirtd (our daemon we have) relabels all the
necessary paths that QEMU process (representing VM) can touch.
However, I'm facing an issue that I don't know how to fix. In some cases
QEMU can close & reopen a block device. However, closing a block device
triggers an event and hence if there is a rule that sets a security
label on a device the QEMU process is unable to reopen the device again.

My question is, whet we can do to prevent udev from mangling with our
security labels that we've set on the devices?

One of the ideas our lead developer had was for libvirt to set some kind
of udev label on devices managed by libvirt (when setting up security
labels) and then whenever udev sees such labelled device it won't touch
it at all (this could be achieved by a rule perhaps?). Later, when
domain is shutting down libvirt removes that label. But I don't think
setting an arbitrary label on devices is supported, is it?

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] fix parsing security labels from virt-aa-helper

[Christian Ehrhardt]

On Thu, Nov 3, 2016 at 6:15 PM, Guido Günther  wrote:

Thanks for your feedback Guido!

On Mon, Oct 31, 2016 at 11:32:44AM +0100, Christian Ehrhardt wrote:
> > When parsing labels virt-aa-helper does no more pass
> > VIR_DOMAIN_DEF_PARSE_INACTIVE due to dfbc9a83 that tried to mitigate the
> > changes of a89f05ba. For those it had to switch from
>
> I wouldn't call it mitigate. It was rather a fix.
>

True, I really meant no offense nor wanted to degrade the fix by wording it
badly.
I reworded the commit message locally so that the next re-submission (if
needed) will call it a fix correctly.

> VIR_DOMAIN_DEF_PARSE_INACTIVE to active since we need the domain id
> > (ctl->def->id) as it is part of the socket path now which is needed for
> the
> > aa profile.
> >
> > But that turned out to break non apparmor seclabels as well as apparmor
> > seclabels in xmls without labels.
>
> While I understand the "non apparmor seclabel" part I don't understand
> what you mean by "apparmor seclabels in xmls without labels".


Yeah what I meant with "apparmor seclabels in xmls without labels" was
misleading.
The whole reproduction of the case started very shaky for me which I think
has slipped into the description of this paragraph.
What I wanted to make clear is this:

If you are in the error case e.g. after adding:
  
Note: Remember the error is now "... cannot load AppArmor profile ..."
pointing to apparmor

That neither adding an "apparmor seclabel without label" ...
   

Nor adding "apparmor seclabel with label" ...
  
libvirt-a4b7c764-988b-4a88-a614-5399b745ca94
libvirt-a4b7c764-988b-4a88-a614-5399b745ca94
  

... will get you going again.

So while the message "...cannot load AppArmor profile..." is pointing to
apparmor, it actually is an error parsing the dac seclabel.


> On Debian
> based distros e.g. virtinst creates all VMs without seclabels and we let
> the dac and apparmor security drivers do the work. I.e. this gets added
> to the domains live xml upon start.
>

That works the same for my environment - if nothing is in the xml the
security drivers add their stuff as needed and it can be seen in the active
domain dumpxml with label and imagelabel set.
Once shut down all content of the seclabel is gone in the dumpxml.

That is the reason why in the common cases there is no issue to be seen.
There is nothing in the xml to be parsed and the drivers add their stuff.
But IMHO it is valid to add the seclabel to the xml explicitly and in that
case the parsing as called from virt-aa-helper fails.

> In those cases due to VIR_DOMAIN_DEF_PARSE_INACTIVE now not set anymore
> > virSecurityLabelDefParseXML insists on finding labels. Cases:
> > - non-apparmor seclabel - virt-aa-helper breaks
> > - apparmor seclabel without labels on a defined domain - virt-aa-helper
> breaks
> > This was not spotted due to labels getting dynamically created on
> > definition.
>
> As far as I understand it dynamic labels get created on domain start not
> domain definition (and are updated on e.g. device plug).


Yes I agree.
If I define an xml without a label the drivers add their stuff.
On live (dumpxml) I then see it completely with all labels just as you
posted.
And once I shut down the guest and dumpxml it again it does not contain the
seclabel anymore.


> > So "define, start, stop" works. But "define, edit (add label), start"
> > does not.
>
> What do you add during the edit step. Can you provide an example?
>

As shown above add a dac seclabel without label/imagelabel child elements:
  

[...]

>
> > Testcase with virt-aa-helper on xml file:
> >  virt-aa-helper -d -r -p 0 -u libvirt- < your-guest.xml
> >virt-aa-helper: error: could not parse XML
> >virt-aa-helper: error: could not get VM definition
> > (That should have printed a valid apparmor profile)
>
> /usr/lib/libvirt/virt-aa-helper -d -r -p 0 -u 
> libvirt-a9287b6e-ca06-42fe-b1a2-06830752843a
> < /etc/libvirt/qemu/wheezy.xml
> virt-aa-helper:
> /etc/apparmor.d/libvirt/libvirt-a9287b6e-ca06-42fe-b1a2-06830752843a.files
> virt-aa-helper:
>   "/var/log/libvirt/**/wheezy.log" w,
>
[...]

Yep that is how the good case.
As outlined that is either without seclabel in the xml (default) or with
fully complete seclabels (+imagelabel +label).
But as soon as there is the simple dac seclabel added it should show the
issue.

I don't understand why VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE is not sufficient.
>

As far as I understand the reason is that It is not a part of the
validation that fails.
The flag VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE does not skip the parsing of
the seclabels, but that is where it fails already.
In the function virSecurityLabelDefParseXML the only flag that skips the
insisting on labels being present always was VIR_DOMAIN_DEF_PARSE_INACTIVE.

Now I understand that you had to drop VIR_DOMAIN_DEF_PARSE_INACTIVE for the
fix in dfbc9a83.
But that caused the regression that "" can no more be added explicitly.
So since we now have this