On 17.03.2017 23:21, Chris Friesen wrote:
> Hi,
>
> We've recently run into an issue with libvirt 1.2.17 in the context of
> an OpenStack deployment.
>
Let me just say that 1.2.17 is rather old libvirt. Can you try with one
of the latests one to see whether the bug still reproduces?
> Occasiona
Hi,
We've recently run into an issue with libvirt 1.2.17 in the context of an
OpenStack deployment.
Occasionally after doing live migrations from a compute node with libvirt 1.2.17
to a compute node with libvirt 2.0.0 we see libvirtd on the 1.2.17 side stop
responding. When this happens, if
On Wed, Mar 15, 2017 at 05:48:09PM -0300, Marcelo Tosatti wrote:
On Wed, Mar 15, 2017 at 08:49:57PM +0100, Martin Kletzander wrote:
On Wed, Mar 15, 2017 at 02:11:23PM -0300, Marcelo Tosatti wrote:
>On Wed, Mar 15, 2017 at 03:59:31PM +0100, Martin Kletzander wrote:
>>On Wed, Mar 15, 2017 at 02:23
On Wed, Mar 15, 2017 at 08:49:57PM +0100, Martin Kletzander wrote:
> On Wed, Mar 15, 2017 at 02:11:23PM -0300, Marcelo Tosatti wrote:
> >On Wed, Mar 15, 2017 at 03:59:31PM +0100, Martin Kletzander wrote:
> >>On Wed, Mar 15, 2017 at 02:23:26PM +, Daniel P. Berrange wrote:
> >>>On Wed, Mar 15, 20
https://bugzilla.redhat.com/show_bug.cgi?id=1300769
If the migration flags indicate this migration will be using TLS,
then while we have connection in the Begin phase check and setup the
TLS environment that will be used by virMigrationRun during the Perform
phase for the source to configure TLS.
If the migration flags indicate this migration will be using TLS,
then set up the destination during the prepare phase once the target
domain has been started to add the TLS objects to perform the migration.
This will create at least an "-object tls-creds-x509,endpoint=server,..."
and potentially
Create GET_CONFIG_TLS_CERT to set up the TLS for 'chardev' TLS setting.
Soon to be reused.
Signed-off-by: John Ferlan
---
src/qemu/qemu_conf.c | 39 +--
1 file changed, 25 insertions(+), 14 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
Add a new TLS X.509 certificate type - "migrate". This will handle the
creation of a TLS certificate capability (and possibly repository) to
be used for migrations. Similar to chardev's, credentials will be handled
via a libvirt secrets; however, unlike chardev's enablement and usage
will be via a
Add an asyncJob argument for add/delete TLS Objects. A future patch will
add/delete TLS objects from a migration which may hae a job to join.
Signed-off-by: John Ferlan
---
src/qemu/qemu_hotplug.c | 24
src/qemu/qemu_hotplug.h | 2 ++
2 files changed, 18 insertions(+),
v2: http://www.redhat.com/archives/libvir-list/2017-February/msg01374.html
NB: Parts of the original series were split out, patches posted, ACK'd,
and committed separately, see:
http://www.redhat.com/archives/libvir-list/2017-March/msg00037.html
Changes since v2:
First and foremost after some g
Add the fields to support setting tls-creds and tls-hostname during
a migration (either source or target). Modify the query migration
function to check for the presence and set the field for future
consumers to determine which of 3 conditions is being met (not
present, present and set to "", or pre
Signed-off-by: John Ferlan
---
include/libvirt/libvirt-domain.h | 8
src/qemu/qemu_migration.h| 3 ++-
tools/virsh-domain.c | 7 +++
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
On 03/17/2017 12:58 PM, Jiri Denemark wrote:
> On Fri, Mar 17, 2017 at 12:33:14 -0400, Laine Stump wrote:
>> It was pointed out here:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1331796#c4
>>
>> that we shouldn't be adding a "no-resolv" to the dnsmasq.conf file for
>> a network if there isn
On Fri, Mar 17, 2017 at 12:33:14 -0400, Laine Stump wrote:
> It was pointed out here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1331796#c4
>
> that we shouldn't be adding a "no-resolv" to the dnsmasq.conf file for
> a network if there isn't any element that specifies an IP
> address but
Signed-off-by: Jiri Denemark
---
tests/cputestdata/cpu-cpuid.py | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/tests/cputestdata/cpu-cpuid.py b/tests/cputestdata/cpu-cpuid.py
index 9ea858d98..f4cf6d440 100755
--- a/tests/cputestdata/cpu-cpuid.py
+++ b/t
Jiri Denemark (14):
cpu_conf: Introduce virCPUDefFreeFeatures
cpu: Introduce virCPUExpandFeatures
cpu: Drop unused flags from cpuArchDecode
cpu: Move feature expansion out of cpuBaseline
cpu: Do not pass virConnectBaselineCPUFlags to cpuBaseline
cputest: Move instantiation of JSONDecode
Generated with
(cd tests/cputestdata; ./cpu-cpuid.py diff x86_64-cpuid-*.json)
Signed-off-by: Jiri Denemark
---
tests/cputestdata/x86_64-cpuid-A10-5800K-disabled.xml | 7 +++
tests/cputestdata/x86_64-cpuid-A10-5800K-enabled.xml | 8
tests/cputestdata/x86_64-cpuid-Cor
Having to use cpuBaseline with VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES
flag to expand CPU features is strange. Not to mention that cpuBaseline
can only expand host CPU definitions (i.e., it completely ignores
feature policies). The new virCPUExpandFeatures API is designed to work
with both host an
Let's make the object local to the parseFeatureWords function which uses
it.
Signed-off-by: Jiri Denemark
---
tests/cputestdata/cpu-convert.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/cputestdata/cpu-convert.py b/tests/cputestdata/cpu-convert.py
index 898d42f
All CPU features which QEMU does not know about but libvirt knows them
(currently "cmt" is the only one) are implicitly disabled by QEMU and
should be present in x86_64-cpuid-*-disabled.xml.
Signed-off-by: Jiri Denemark
---
tests/cputestdata/cpu-cpuid.py | 1 +
tests/cp
The new script is going to be more general and the original
functionality can be requested by "cpu-cpuid.py convert".
Signed-off-by: Jiri Denemark
---
tests/cputestdata/{cpu-convert.py => cpu-cpuid.py} | 17 -
tests/cputestdata/cpu-parse.sh | 2 +-
2 files ch
Signed-off-by: Jiri Denemark
---
tests/cputestdata/cpu-cpuid.py | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/tests/cputestdata/cpu-cpuid.py b/tests/cputestdata/cpu-cpuid.py
index a4dc23378..9ea858d98 100755
--- a/tests/cputestdata
The test takes
x86-cpuid-Something-guest.xml CPU (the CPU libvirt would use for
host-model on a CPU described by x86_64-cpuid-Something.xml without
talking to QEMU about what it supports on the host)
and updates it according to CPUID data from QEMU:
x86_64-cpuid-Something-enabled.xml
cpuBaseline is responsible for computing a baseline CPU while feature
expansion is done by virCPUExpandFeatures. The cpuBaselineXML wrapper
(used by hypervisor drivers to implement virConnectBaselineCPU API)
calls cpuBaseline followed by virCPUExpandFeatures if requested by
VIR_CONNECT_BASELINE_CPU
Commit v3.1.0-26-gd60012b4e started filtering hle and rtm features from
broken Intel Haswell CPUs. QEMU implemented similar functionality and
thus it doesn't report rtm and hle features as enabled for Core i5-4670T
CPU anymore.
Signed-off-by: Jiri Denemark
---
tests/cputestdata/x86_64-cpuid-Core
The new command can be used to generate test data for virCPUUpdateLive.
When "cpu-cpuid.py diff x86-cpuid-Something.json" is run, it reads raw
CPUID data stored in x86-cpuid-Something.xml and CPUID data from QEMU
stored in x86-cpuid-Something.json to produce two more CPUID files:
x86-cpuid-Somethi
The public API flags are handled by the cpuBaselineXML wrapper. The
internal cpuBaseline API only needs to know whether it is supposed to
drop non-migratable features.
Signed-off-by: Jiri Denemark
---
src/cpu/cpu.c | 14 +-
src/cpu/cpu.h | 4 ++--
src/cpu/cpu_arm.c |
Signed-off-by: Jiri Denemark
---
src/cpu/cpu.c | 2 +-
src/cpu/cpu.h | 3 +--
src/cpu/cpu_ppc64.c | 7 ++-
src/cpu/cpu_x86.c | 7 +++
4 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c
index 5604db1d1..33581e5fe 100644
--- a/src/cpu
Signed-off-by: Jiri Denemark
---
src/conf/cpu_conf.c | 21 +++--
src/conf/cpu_conf.h | 3 +++
src/libvirt_private.syms | 1 +
3 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/src/conf/cpu_conf.c b/src/conf/cpu_conf.c
index d7c8b8ff2..b78531e60 100644
---
It was pointed out here:
https://bugzilla.redhat.com/show_bug.cgi?id=1331796#c4
that we shouldn't be adding a "no-resolv" to the dnsmasq.conf file for
a network if there isn't any element that specifies an IP
address but no qualifying domain. If there is such an element, it will
handle all DNS
On Fri, Mar 17, 2017 at 16:15:03 +, Daniel Berrange wrote:
> On Fri, Mar 17, 2017 at 04:48:48PM +0100, Peter Krempa wrote:
> > See patch 3 for explanation
> >
> > Peter Krempa (3):
> > rpc: socket: Add possibility to suppress errors on read hangup
> > rpc: serverclient: Add option to suppr
On Fri, Mar 17, 2017 at 04:48:48PM +0100, Peter Krempa wrote:
> See patch 3 for explanation
>
> Peter Krempa (3):
> rpc: socket: Add possibility to suppress errors on read hangup
> rpc: serverclient: Add option to suppress errors on EOF
> (log|lock)daemon: Don't spam logs with IO error messa
On Fri, Mar 17, 2017 at 16:10:35 +, Daniel Berrange wrote:
> On Fri, Mar 17, 2017 at 04:48:49PM +0100, Peter Krempa wrote:
> > In some cases a read error due to connection hangup is expected. This
> > patch adds a flag that removes the logging of a virError in such case.
> > ---
> > src/rpc/vi
On Fri, Mar 17, 2017 at 04:48:51PM +0100, Peter Krempa wrote:
> The log and lock protocol don't have an extra handshake to close the
> connection. Instead they just close the socket. Unfortunately that
> resulted into a lot of spurious garbage logged to the system log files:
>
> 2017-03-17 14:00:0
On Fri, Mar 17, 2017 at 04:48:49PM +0100, Peter Krempa wrote:
> In some cases a read error due to connection hangup is expected. This
> patch adds a flag that removes the logging of a virError in such case.
> ---
> src/rpc/virnetsocket.c | 33 +++--
> src/rpc/virnetsock
On 03/15/2017 10:45 AM, Cédric Bosdonnat wrote:
> Add a function getting the name of a network interface out of its index.
> ---
> src/libvirt_private.syms | 1 +
> src/util/virnetdev.c | 19 +++
> src/util/virnetdev.h | 2 ++
> 3 files changed, 22 insertions(+)
>
> diff
The log and lock protocol don't have an extra handshake to close the
connection. Instead they just close the socket. Unfortunately that
resulted into a lot of spurious garbage logged to the system log files:
2017-03-17 14:00:09.730+: 4714: error : virNetSocketReadWire:1800 : End of
file while
In some cases a read error due to connection hangup is expected. This
patch adds a flag that removes the logging of a virError in such case.
---
src/rpc/virnetsocket.c | 33 +++--
src/rpc/virnetsocket.h | 2 ++
2 files changed, 29 insertions(+), 6 deletions(-)
diff --
See patch 3 for explanation
Peter Krempa (3):
rpc: socket: Add possibility to suppress errors on read hangup
rpc: serverclient: Add option to suppress errors on EOF
(log|lock)daemon: Don't spam logs with IO error messages after client
disconnects
src/locking/lock_daemon.c| 3 +++
The protocol may not use an explicit API to close the connection and
just close the socket instead. Add option to suppress errors in such
case.
---
src/rpc/virnetserverclient.c | 13 +
src/rpc/virnetserverclient.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/src/rpc/virnets
On 03/16/2017 02:07 PM, John Ferlan wrote:
Repost after merging with latest changes of:
http://www.redhat.com/archives/libvir-list/2017-March/msg00305.html
Continuing down the pile of drivers from my RFC for making a common pool
object - we're now at storage... For reference see patch 3 of:
ht
On Fri, Mar 17, 2017 at 03:40:33PM +0100, Michal Privoznik wrote:
> On 03/17/2017 02:58 PM, Laine Stump wrote:
> >
> > Why JSON rather than XML though? I don't have a real preference over one
> > or the other, but libvirt lore is *steeped* in XML, and all the other
> > libvirt config files are XML
[...]
>
> Sorry, but these patches do not apply cleanly anymore. Should have
> reviewed later. Can you please rebase & resend?
>
> Michal
I already had done so:
http://www.redhat.com/archives/libvir-list/2017-March/msg00749.html
Just forgot to update this...
John
--
libvir-list mailing lis
On 03/17/2017 02:58 PM, Laine Stump wrote:
On 03/17/2017 09:32 AM, Michal Privoznik wrote:
On 03/10/2017 09:35 PM, Laine Stump wrote:
These three functions are destined to replace
virNetDev(Replace|Restore)NetConfig() and
virNetDev(Replace|Restore)MacAddress(), which both do the save and set
to
On 03/17/2017 09:32 AM, Michal Privoznik wrote:
> On 03/10/2017 09:35 PM, Laine Stump wrote:
>> * "administratively set" flag for the VF in the PF's
>> @@ -2109,6 +2172,7 @@ virNetDevSetNetConfig(const char *linkdev, int vf,
>> cleanup:
>> VIR_FREE(pfDevOrig);
>> VIR_FREE(
On 03/17/2017 09:32 AM, Michal Privoznik wrote:
> On 03/10/2017 09:35 PM, Laine Stump wrote:
>> Some PF drivers allow setting the admin MAC (that is the MAC address
>> that the VF will be initialized to the next time the VF's driver is
>> loaded) to 00:00:00:00:00:00, and some don't. Multiple drive
On 03/17/2017 09:32 AM, Michal Privoznik wrote:
> On 03/10/2017 09:35 PM, Laine Stump wrote:
>> This function unbinds a device from its driver, then immediately
>> rebinds it to its driver again.
>> ---
>> src/libvirt_private.syms | 1 +
>> src/util/virpci.c| 25 +
On 03/17/2017 09:32 AM, Michal Privoznik wrote:
> On 03/10/2017 09:35 PM, Laine Stump wrote:
>> These three functions are destined to replace
>> virNetDev(Replace|Restore)NetConfig() and
>> virNetDev(Replace|Restore)MacAddress(), which both do the save and set
>> together as a single step. We need
On 03/07/2017 10:35 PM, John Ferlan wrote:
Continuing down the pile of drivers from my RFC for making a common pool
object - we're now at storage... For reference see patch 3 of:
http://www.redhat.com/archives/libvir-list/2017-February/msg00519.html
This series works through the storage conf a
This is usable only on python >= 3.4 (or 3.3 with out-of-tree asyncio),
however it should be harmless for anyone with older python versions.
In simplest case, to have the callbacks queued on the default loop:
>>> import libvirtaio
>>> libvirtaio.virEventRegisterAsyncIOImpl()
The function
The documentation says:
> If the opaque user data requires free'ing when the handle is
> unregistered, then a 2nd callback can be supplied for this purpose.
> This callback needs to be invoked from a clean stack. If 'ff'
> callbacks are invoked directly from the virEventRemoveHandleFunc they
> will
Hello, libvirt-list,
This is second attempt at merging libvirtaio, an event loop implementation
which dispatches the callbacks via asyncio's event loop.
The first patch fixes the bug around freeing opaque objects [1][2], and the
second one is the actual implementation.
Since v1 series, as per Da
On 03/10/2017 09:35 PM, Laine Stump wrote:
We will want to allow silent failure of virNetDevSetMAC() in the case
that the SIOSIFHWADDR ioctl fails with errno == EADDRNOTAVAIL. (Yes,
that is very specific, but we really *do* want a logged failure in all
other circumstances, and don't want to dupli
On 03/10/2017 09:34 PM, Laine Stump wrote:
There are multiple bugs filed against both libvirt and the kernel
related to incorrect restoration of MAC addresses for SR-IOV VFs, both
when used via VFIO device assignment and when used for macvtap
passthrough mode
https://bugzilla.redhat.com/1415609
On 03/10/2017 09:35 PM, Laine Stump wrote:
Given an SRIOV PF netdev name (e.g. "enp2s0f0") and VF#, this new
function returns the netdev name of the referenced VF device
(e.g. "enp2s11f6"), or NULL if the device isn't bound to a net driver.
---
src/libvirt_private.syms | 1 +
src/util/virnetdev
On 03/10/2017 09:35 PM, Laine Stump wrote:
If an SRIOV VF has previously been used for VFIO device assignment,
the "admin MAC" that is stored in the PF driver's table of VF info
will have been set to the MAC address that the virtual machine wanted
the device to have. Setting the admin MAC for a V
On 03/10/2017 09:35 PM, Laine Stump wrote:
These three functions are destined to replace
virNetDev(Replace|Restore)NetConfig() and
virNetDev(Replace|Restore)MacAddress(), which both do the save and set
together as a single step. We need to separate the save, read, and set
steps because there will
On 03/10/2017 09:35 PM, Laine Stump wrote:
Some PF drivers allow setting the admin MAC (that is the MAC address
that the VF will be initialized to the next time the VF's driver is
loaded) to 00:00:00:00:00:00, and some don't. Multiple drivers
initialize the admin MACs to all 0, but don't allow se
On 03/10/2017 09:35 PM, Laine Stump wrote:
This function unbinds a device from its driver, then immediately
rebinds it to its driver again.
---
src/libvirt_private.syms | 1 +
src/util/virpci.c| 25 +
src/util/virpci.h| 1 +
3 files changed, 27 insertion
On 03/17/2017 05:06 AM, Andrea Bolognani wrote:
> On Thu, 2017-03-16 at 18:30 -0400, Laine Stump wrote:
>>> @@ -1861,7 +1863,12 @@
>>> qemuDomainPCIControllerSetDefaultModelName(virDomainControllerDefPtr cont)
>>> *modelName =
>>> VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_I82801B11_BRIDGE;
>
On 03/17/2017 01:57 AM, Chen, Xiaoguang wrote:
>
>
>> -Original Message-
>> From: sendmail [mailto:justsendmailnothinge...@gmail.com] On Behalf Of Laine
>> Stump
>> Sent: Thursday, March 16, 2017 10:01 PM
>> To: libvir-list@redhat.com
>> Cc: Chen, Xiaoguang ; Erik Skultety
>> ; He, Yongli
On Fri, Mar 17, 2017 at 02:16:37AM +0100, Wojtek Porczyk wrote:
> This is usable only on python >= 3.4 (or 3.3 with out-of-tree asyncio),
> however it should be harmless for anyone with older python versions.
>
> In simplest case, to have the callbacks queued on the default loop:
>
> >>> impo
On Wed, Mar 15, 2017 at 17:39:34 +0100, Ján Tomko wrote:
> On Tue, Mar 14, 2017 at 05:57:39PM +0100, Jiri Denemark wrote:
> >When starting a domain with custom guest CPU specification QEMU may add
> >or remove some CPU features. There are several reasons for this, e.g.,
> >QEMU/KVM does not support
On 03/17/2017 09:30 AM, Peter Krempa wrote:
Fix a crasher and an invalid configuration.
Peter Krempa (4):
qemu: Don't steal pointers from 'persistentDef' in
qemuDomainGetBlockIoTune
qemu: command: Extract blkdeviotune checks into a separate function
qemu: command: Extract tests for sub
On Fri, Mar 17, 2017 at 10:05:45AM +0100, Jiri Denemark wrote:
> On Thu, Mar 16, 2017 at 12:22:05 +0100, Guido Günther wrote:
> > This unbreaks emulators that don't support this command such as
> > qemu-system-mips*.
> >
> > Reference: http://bugs.debian.org/854125
>
> ACK
Pushed. Thanks. To to
emulatedType is not used in prlsdkAddDomainHardDisksInfo()
---
src/vz/vz_sdk.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index 3fd17db..8e6e89d 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -817,14 +817,9 @@ prlsdkAddDomainHardDisksInfo(vzDri
On 03/16/2017 12:55 PM, Nitesh Konkar wrote:
Currently 'virsh perf domain' errors out as the perf nparams is
incorrectly compared against REMOTE_DOMAIN_MEMORY_PARAMETERS_MAX
instead of REMOTE_DOMAIN_PERF_EVENTS_MAX.
Signed-off-by: Nitesh Konkar
---
daemon/remote.c | 2 +-
1 file changed, 1 ins
On Thu, 2017-03-16 at 18:30 -0400, Laine Stump wrote:
> > @@ -1861,7 +1863,12 @@
> > qemuDomainPCIControllerSetDefaultModelName(virDomainControllerDefPtr cont)
> > *modelName = VIR_DOMAIN_CONTROLLER_PCI_MODEL_NAME_I82801B11_BRIDGE;
> > break;
> > case VIR_DOMAIN_CONTROLLER_M
On Thu, Mar 16, 2017 at 12:22:05 +0100, Guido Günther wrote:
> This unbreaks emulators that don't support this command such as
> qemu-system-mips*.
>
> Reference: http://bugs.debian.org/854125
ACK
Jirka
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/l
On Thu, Mar 16, 2017 at 04:52:04PM +, Daniel P. Berrange wrote:
> On Thu, Mar 16, 2017 at 05:48:47PM +0100, Guido Günther wrote:
> > This is where e.g. Debian puts it.
> > ---
> > This adds lib64 as Dan suggested and also adds these two dirs to the
> > second invocations to make things actually
qemuBuildDriveStr grew into 'megamoth' proportions. Cut out some parts.
---
src/qemu/qemu_command.c | 149 ++--
1 file changed, 80 insertions(+), 69 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 61d9eb94a..300c51b39 1
When checking capabilities for qemu we need to check whether subsets of
the disk throttling settings are supported. Extract the checks into a
separate functions as they will be reused in next patch.
---
src/qemu/qemu_command.c | 59 +
1 file changed,
Fix a crasher and an invalid configuration.
Peter Krempa (4):
qemu: Don't steal pointers from 'persistentDef' in
qemuDomainGetBlockIoTune
qemu: command: Extract blkdeviotune checks into a separate function
qemu: command: Extract tests for subsets of blkdeviotune settings
qemu: command:
While the code path that queries the monitor allocates a separate copy
of the 'group_name' string the path querying the config would not copy
it. The call to virTypedParameterAssign would then steal the pointer
(without clearing it) and the RPC layer freed it. Any subsequent call
resulted into a cr
The disk tuning group parameter is ignored by qemu if no other
throttling options are set. Reject such configuration, since the name
would not be honored after setting parameters via the live tuning API.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1433180
---
src/qemu/qemu_command.c | 2
On Wed, 15 Mar 2017 14:29:13 -0400
Luiz Capitulino wrote:
> > ... we could consider to be the explicit request for
> > setting an infinite memory locking limit and letting users set a lower
> > limit with hard_limit if they want.
>
> That's exactly how I see it! It seems we're total agreement
76 matches
Mail list logo
