[libvirt] [PATCH] lxc: fix 2 issue around cpuset
by Luyao Huang
There are two bugs in this function:
1. cannot start a vm with cpuset but without numatune settings
# virsh -c lxc:/// start helloworld
error: Failed to start domain helloworld
error: internal error: guest failed to start: Invalid value '1-3' for 'cpuset.mems': Invalid argument
we don't free &mask after use it for virCgroupSetCpusetCpus() and
then virDomainNumatuneMaybeFormatNodeset() do not get a new &mask,
then we use it in virCgroupSetCpusetMems().
2. when start a lxc with numatune memory mode not strict
# virsh -c lxc:/// start helloworld
error: Failed to start domain helloworld
error: internal error: guest failed to start: Unknown failure in libvirt_lxc startup
We shouldn't set anything in cpuset.mems for these mode.
Signed-off-by: Luyao Huang <lhuang(a)redhat.com>
---
src/lxc/lxc_cgroup.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/lxc/lxc_cgroup.c b/src/lxc/lxc_cgroup.c
index c1813e2..5e959a2 100644
--- a/src/lxc/lxc_cgroup.c
+++ b/src/lxc/lxc_cgroup.c
@@ -77,11 +77,15 @@ static int virLXCCgroupSetupCpusetTune(virDomainDefPtr def,
if (virCgroupSetCpusetCpus(cgroup, mask) < 0)
goto cleanup;
+ /* free mask to make sure we won't use it in a wrong way later */
+ VIR_FREE(mask);
}
if (virDomainNumatuneGetMode(def->numa, -1) !=
- VIR_DOMAIN_NUMATUNE_MEM_STRICT)
+ VIR_DOMAIN_NUMATUNE_MEM_STRICT) {
+ ret = 0;
goto cleanup;
+ }
if (virDomainNumatuneMaybeFormatNodeset(def->numa, nodemask,
&mask, -1) < 0)
--
1.8.3.1
10 years
[libvirt] [PATCH] qemu: set macvtap physdevs online when macvtap is set online
by Laine Stump
A further fix for:
https://bugzilla.redhat.com/show_bug.cgi?id=1113474
Since there is no possibility that any type of macvtap will work if
the parent physdev it's attached to is offline, we should bring the
physdev online at the same time as the macvtap. When taking the
macvtap offline, it's also necessary to take the physdev offline for
macvtap passthrough mode (because the physdev has the same MAC address
as the macvtap device, so could potentially cause problems with
misdirected packets during migration, as outlined in commits 829770
and 879c13). We can't set the physdev offline for other macvtap modes
1) because there may be other macvtap devices attached to the same
physdev in the other modes whereas passthrough mode is exclusive to
one macvtap at a time, and 2) there's no practical reason to do so
anyway.
---
src/qemu/qemu_hotplug.c | 8 +++-----
src/qemu/qemu_interface.c | 29 +++++++++++++++++++++++++++--
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 2f0549e..9be2ea3 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -3931,11 +3931,9 @@ qemuDomainDetachNetDevice(virQEMUDriverPtr driver,
VIR_WARN("cannot clear bandwidth setting for device : %s",
detach->ifname);
- /* deactivate the tap/macvtap device on the host (currently this
- * isn't necessary, as everything done in
- * qemuInterfaceStopDevice() is made meaningless when the device
- * is deleted anyway, but in the future it may be important, and
- * doesn't hurt anything for now)
+ /* deactivate the tap/macvtap device on the host, which could also
+ * affect the parent device (e.g. macvtap passthrough mode sets
+ * the parent device offline)
*/
ignore_value(qemuInterfaceStopDevice(detach));
diff --git a/src/qemu/qemu_interface.c b/src/qemu/qemu_interface.c
index 201a7dd..01226ac 100644
--- a/src/qemu/qemu_interface.c
+++ b/src/qemu/qemu_interface.c
@@ -63,7 +63,20 @@ qemuInterfaceStartDevice(virDomainNetDefPtr net)
goto cleanup;
}
break;
- case VIR_DOMAIN_NET_TYPE_DIRECT:
+
+ case VIR_DOMAIN_NET_TYPE_DIRECT: {
+ const char *physdev = virDomainNetGetActualDirectDev(net);
+ bool isOnline = true;
+
+ /* set the physdev online if necessary. It may already be up,
+ * in which case we shouldn't re-up it just in case that causes
+ * some sort of "blip" in the physdev's status.
+ */
+ if (physdev && virNetDevGetOnline(physdev, &isOnline) < 0)
+ goto cleanup;
+ if (!isOnline && virNetDevSetOnline(physdev, true) < 0)
+ goto cleanup;
+
/* macvtap devices share their MAC address with the guest
* domain, and if they are set online prior to the domain CPUs
* being started, the host may send out traffic from this
@@ -79,6 +92,7 @@ qemuInterfaceStartDevice(virDomainNetDefPtr net)
if (virNetDevSetOnline(net->ifname, true) < 0)
goto cleanup;
break;
+ }
case VIR_DOMAIN_NET_TYPE_USER:
case VIR_DOMAIN_NET_TYPE_ETHERNET:
@@ -146,7 +160,9 @@ qemuInterfaceStopDevice(virDomainNetDefPtr net)
}
break;
- case VIR_DOMAIN_NET_TYPE_DIRECT:
+ case VIR_DOMAIN_NET_TYPE_DIRECT: {
+ const char *physdev = virDomainNetGetActualDirectDev(net);
+
/* macvtap interfaces need to be marked !IFF_UP (ie "down") to
* prevent any host-generated traffic sent from this interface
* from putting bad info into the arp caches of other machines
@@ -154,7 +170,16 @@ qemuInterfaceStopDevice(virDomainNetDefPtr net)
*/
if (virNetDevSetOnline(net->ifname, false) < 0)
goto cleanup;
+
+ /* also mark the physdev down for passthrough macvtap, as the
+ * physdev has the same MAC address as the macvtap device.
+ */
+ if (virDomainNetGetActualDirectMode(net) ==
+ VIR_NETDEV_MACVLAN_MODE_PASSTHRU &&
+ physdev && virNetDevSetOnline(physdev, false) < 0)
+ goto cleanup;
break;
+ }
case VIR_DOMAIN_NET_TYPE_USER:
case VIR_DOMAIN_NET_TYPE_ETHERNET:
--
2.1.0
10 years
[libvirt] [PATCH 0/7] QoS: Adapt to changing MAC
by Michal Privoznik
While we taught libvirt to listen to MAC address changes from
guests we forgot to update our QoS hierarchy accordingly.
The first 3 patches are pure bug fixes and can go in regardless of
state of the rest.
The 4th patch is a slight improvement as it makes filter priority
predictable.
Then, patches 5-7 actually fix the bug.
Michal Privoznik (7):
virNetDevBandwidthPlug: Update function description
RNG schema: allow plain @floor to <bandwidth/>
virDomainActualNetDefContentsFormat: Format class_id more frequently
virNetDevBandwidthSet: Add priority to filter
virnetdevbandwidth.c: Separate tc filter creation to a function
Introduce virNetDevBandwidthUpdateFilter
processNicRxFilterChangedEvent: Take appropriate actions for
NET_TYPE_NETWORK too
docs/schemas/networkcommon.rng | 8 +-
src/conf/domain_conf.c | 3 +-
src/libvirt_private.syms | 1 +
src/qemu/qemu_driver.c | 22 +++
src/util/virnetdevbandwidth.c | 186 ++++++++++++++++-----
src/util/virnetdevbandwidth.h | 6 +
.../qemuxml2argv-net-bandwidth2.xml | 65 +++++++
tests/qemuxml2xmltest.c | 1 +
tests/virnetdevbandwidthtest.c | 4 +-
9 files changed, 250 insertions(+), 46 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-bandwidth2.xml
--
2.0.5
10 years
[libvirt] [PATCH] parallels: make device addressing consistent
by Nikolay Shirokovskiy
In Parallels we do not support device name hints
aka <target dev=../> option and full-fledged device
disk device addressing through
<address type=.. controller=.. bus=.. target=.. unit=../>
and have only one index instead.
In this situation to be consistent we can only take
one-to-one mapping from some reasonable subset
of full address. Values outside this subset are
invalid to create Parallels VMs.
Reasonable mapping is default one defined in virDomainDiskDefAssignAddress.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)parallels.com>
---
src/parallels/parallels_sdk.c | 72 ++++++++++++++++++++++++++++++++++------
1 files changed, 61 insertions(+), 11 deletions(-)
diff --git a/src/parallels/parallels_sdk.c b/src/parallels/parallels_sdk.c
index d199898..80e9d00 100644
--- a/src/parallels/parallels_sdk.c
+++ b/src/parallels/parallels_sdk.c
@@ -462,7 +462,7 @@ prlsdkGetDiskInfo(PRL_HANDLE prldisk,
PRL_UINT32 emulatedType;
PRL_UINT32 ifType;
PRL_UINT32 pos;
- PRL_UINT32 prldiskIndex;
+ virDomainDeviceDriveAddressPtr address;
int ret = -1;
pret = PrlVmDev_GetEmulatedType(prldisk, &emulatedType);
@@ -499,15 +499,32 @@ prlsdkGetDiskInfo(PRL_HANDLE prldisk,
pret = PrlVmDev_GetIfaceType(prldisk, &ifType);
prlsdkCheckRetGoto(pret, cleanup);
+
+ pret = PrlVmDev_GetStackIndex(prldisk, &pos);
+ prlsdkCheckRetGoto(pret, cleanup);
+
+ address = &disk->info.addr.drive;
switch (ifType) {
case PMS_IDE_DEVICE:
disk->bus = VIR_DOMAIN_DISK_BUS_IDE;
+ disk->dst = virIndexToDiskName(pos, "hd");
+ address->bus = pos / 2;
+ address->target = 0;
+ address->unit = pos % 2;
break;
case PMS_SCSI_DEVICE:
disk->bus = VIR_DOMAIN_DISK_BUS_SCSI;
+ disk->dst = virIndexToDiskName(pos, "sd");
+ address->bus = 0;
+ address->target = 0;
+ address->unit = pos;
break;
case PMS_SATA_DEVICE:
disk->bus = VIR_DOMAIN_DISK_BUS_SATA;
+ disk->dst = virIndexToDiskName(pos, "sd");
+ address->bus = 0;
+ address->target = 0;
+ address->unit = pos;
break;
default:
virReportError(VIR_ERR_INTERNAL_ERROR,
@@ -516,17 +533,10 @@ prlsdkGetDiskInfo(PRL_HANDLE prldisk,
break;
}
- pret = PrlVmDev_GetStackIndex(prldisk, &pos);
- prlsdkCheckRetGoto(pret, cleanup);
+ if (!disk->dst)
+ goto cleanup;
disk->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DRIVE;
- disk->info.addr.drive.target = pos;
-
- pret = PrlVmDev_GetIndex(prldisk, &prldiskIndex);
- prlsdkCheckRetGoto(pret, cleanup);
-
- if (!(disk->dst = virIndexToDiskName(prldiskIndex, "sd")))
- goto cleanup;
ret = 0;
@@ -2852,6 +2862,7 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool bootD
virDomainDeviceDriveAddressPtr drive;
PRL_UINT32 devIndex;
PRL_DEVICE_TYPE devType;
+ char *dst = NULL;
if (prlsdkCheckDiskUnsupportedParams(disk) < 0)
return -1;
@@ -2909,22 +2920,50 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool bootD
/* We have only one controller of each type */
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid drive "
"address of disk %s, Parallels Cloud Server has "
- "only one controller."), disk->src->path);
+ "only one controller."), disk->dst);
+ goto cleanup;
+ }
+
+ if (drive->target > 0) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid drive "
+ "address of disk %s, Parallels Cloud Server has "
+ "only target 0."), disk->dst);
goto cleanup;
}
switch (disk->bus) {
case VIR_DOMAIN_DISK_BUS_IDE:
+ if (drive->unit > 1) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid drive "
+ "address of disk %s, Parallels Cloud Server has "
+ "only units 0-1 for IDE bus."), disk->dst);
+ goto cleanup;
+ }
sdkbus = PMS_IDE_DEVICE;
idx = 2 * drive->bus + drive->unit;
+ dst = virIndexToDiskName(idx, "hd");
break;
case VIR_DOMAIN_DISK_BUS_SCSI:
+ if (drive->bus > 0) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid drive "
+ "address of disk %s, Parallels Cloud Server has "
+ "only bus 0 for SCSI bus."), disk->dst);
+ goto cleanup;
+ }
sdkbus = PMS_SCSI_DEVICE;
idx = drive->unit;
+ dst = virIndexToDiskName(idx, "sd");
break;
case VIR_DOMAIN_DISK_BUS_SATA:
+ if (drive->bus > 0) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid drive "
+ "address of disk %s, Parallels Cloud Server has "
+ "only bus 0 for SATA bus."), disk->dst);
+ goto cleanup;
+ }
sdkbus = PMS_SATA_DEVICE;
idx = drive->unit;
+ dst = virIndexToDiskName(idx, "sd");
break;
default:
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
@@ -2933,6 +2972,16 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool bootD
goto cleanup;
}
+ if (!dst)
+ goto cleanup;
+
+ if (STRNEQ(dst, disk->dst)) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid drive "
+ "address of disk %s, Parallels Cloud Server supports "
+ "only defaults address to logical device name."), disk->dst);
+ goto cleanup;
+ }
+
pret = PrlVmDev_SetIfaceType(sdkdisk, sdkbus);
prlsdkCheckRetGoto(pret, cleanup);
@@ -2968,6 +3017,7 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk, bool bootD
return 0;
cleanup:
PrlHandle_Free(sdkdisk);
+ VIR_FREE(dst);
return ret;
}
--
1.7.1
10 years
[libvirt] [PATCH] parallels: fix return status for parallelsConnectOpen
by Nikolay Shirokovskiy
We should return VIR_DRV_OPEN_ERROR in case
if we handle scheme in query but some
error occur. Previously we sometimes
return VIR_DRV_OPEN_DECLINE.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)parallels.com>
---
src/parallels/parallels_network.c | 2 +-
src/parallels/parallels_storage.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/parallels/parallels_network.c b/src/parallels/parallels_network.c
index 47f4886..42ef836 100644
--- a/src/parallels/parallels_network.c
+++ b/src/parallels/parallels_network.c
@@ -349,7 +349,7 @@ parallelsNetworkOpen(virConnectPtr conn,
error:
virObjectUnref(privconn->networks);
privconn->networks = NULL;
- return VIR_DRV_OPEN_DECLINED;
+ return VIR_DRV_OPEN_ERROR;
}
int parallelsNetworkClose(virConnectPtr conn)
diff --git a/src/parallels/parallels_storage.c b/src/parallels/parallels_storage.c
index 6397601..4091124 100644
--- a/src/parallels/parallels_storage.c
+++ b/src/parallels/parallels_storage.c
@@ -494,7 +494,7 @@ parallelsStorageOpen(virConnectPtr conn,
error:
parallelsStorageUnlock(storageState);
parallelsStorageClose(conn);
- return -1;
+ return VIR_DRV_OPEN_ERROR;
}
static int
--
1.7.1
10 years
[libvirt] [PATCH v2] parallels: use SDK disks system names for paths
by Nikolay Shirokovskiy
For block devices SDK friendly name do not
refer to block device path but rather some
description while system name refer to
device path.
For ploop devices both names refer to
image path.
Thus system name is better choice.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)parallels.com>
---
src/parallels/parallels_sdk.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/parallels/parallels_sdk.c b/src/parallels/parallels_sdk.c
index 72c1773..e1ba7cf 100644
--- a/src/parallels/parallels_sdk.c
+++ b/src/parallels/parallels_sdk.c
@@ -485,13 +485,13 @@ prlsdkGetDiskInfo(PRL_HANDLE prldisk,
disk->device = VIR_DOMAIN_DISK_DEVICE_DISK;
}
- pret = PrlVmDev_GetFriendlyName(prldisk, NULL, &buflen);
+ pret = PrlVmDev_GetSysName(prldisk, NULL, &buflen);
prlsdkCheckRetGoto(pret, cleanup);
if (VIR_ALLOC_N(buf, buflen) < 0)
goto cleanup;
- pret = PrlVmDev_GetFriendlyName(prldisk, buf, &buflen);
+ pret = PrlVmDev_GetSysName(prldisk, buf, &buflen);
prlsdkCheckRetGoto(pret, cleanup);
if (virDomainDiskSetSource(disk, buf) < 0)
--
1.7.1
10 years
[libvirt] [PATCH] domtop: Properly free cpu status
by Michal Privoznik
So, in the example the cpu stats are collected within a function
called do_top. At the beginning of the function we ask the daemon for
how much vCPUs can we get stats, and how many stats for a vCPU can we
get. This is because it's how our API works - users are required to
preallocate a chunk of memory for the results. Now, at the end, we try
to free the allocated array, but we are not doing it correctly.
There's this virTypedParamsFree() function which gets a pointer to the
array and the length of the array. However, if there was an error in
getting vCPU stats we pass a negative number instead of the originally
computed value. This flaw results in SIGSEGV:
libvirt: QEMU Driver error : Requested operation is not valid: domain is not running
ERROR do_top:333 : Unable to get cpu stats
==29201== Invalid read of size 4
==29201== at 0x4F1DF8B: virTypedParamsClear (virtypedparam.c:1145)
==29201== by 0x4F1DFEB: virTypedParamsFree (virtypedparam.c:1165)
==29201== by 0x4023C3: do_top (domtop.c:349)
==29201== by 0x40260B: main (domtop.c:386)
==29201== Address 0x131cd7c0 is 16 bytes after a block of size 768 alloc'd
==29201== at 0x4C2C070: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==29201== by 0x401FF1: do_top (domtop.c:295)
==29201== by 0x40260B: main (domtop.c:386)
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
examples/domtop/domtop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/examples/domtop/domtop.c b/examples/domtop/domtop.c
index e50988e..2283994 100644
--- a/examples/domtop/domtop.c
+++ b/examples/domtop/domtop.c
@@ -346,8 +346,8 @@ do_top(virConnectPtr conn,
ret = 0;
cleanup:
- virTypedParamsFree(now_params, now_nparams * max_id);
- virTypedParamsFree(then_params, then_nparams * max_id);
+ virTypedParamsFree(now_params, nparams * max_id);
+ virTypedParamsFree(then_params, nparams * max_id);
if (dom)
virDomainFree(dom);
return ret;
--
2.0.5
10 years
[libvirt] [PATCH 0/5] Add vmport feature (v3)
by Marc-André Lureau
Hi,
The QEMU machine vmport option allows to set the VMWare IO port
emulation. This emulation is useful for absolute pointer input when the
guest has vmware input drivers, and is enabled by default for kvm.
However it is unnecessary for Spice-enabled VM, since the agent already
handles absolute pointer and multi-monitors. Furthermore, it prevents
Spice from switching to relative input since the regular ps/2 pointer
driver is replaced by the vmware driver. It is thus advised to disable
vmport when using a Spice VM. This will permit the Spice client to
switch from absolute to relative pointer, as it may be required for
certain games or applications.
The following patch series allows to configure the vmport feature.
The first version sent used a domain attribute, Daniel Berrange
suggested to use a feature instead. I sent a second version that
didn't receive reviews. Hopefully this one will stand more chances!
cheers
Marc-André Lureau (5):
docs: add domain vmport feature
domain/conf: add VIR_DOMAIN_FEATURE_VMPORT
qemu: add QEMU_CAPS_MACHINE_VMPORT_OPT
qemu: add machine vmport argument
tests: add machine-vmport-opt qemu test
docs/formatdomain.html.in | 6 +++++
docs/schemas/domaincommon.rng | 9 +++++++
src/conf/domain_conf.c | 5 +++-
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 6 +++++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 14 +++++++++++
.../qemuxml2argv-machine-vmport-opt.args | 6 +++++
.../qemuxml2argv-machine-vmport-opt.xml | 28 ++++++++++++++++++++++
tests/qemuxml2argvtest.c | 2 ++
10 files changed, 77 insertions(+), 1 deletion(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-vmport-opt.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-vmport-opt.xml
--
2.1.0
10 years
[libvirt] Building libvirt under Windows
by Pavel Fedin
Hello!
I am currently building libvirt under Windows64, and i would like to ask
for correct way to do it.
The first thing to resolve is absence of RPC XDR library. From configure
source i figured out that portablexdr library may help. I have downloaded
it, but it comes with a different RPC code generator named portable-rpcgen.
I managed to use it, but i had to patch both libvirt (in order to recognize
this generator and handle it properly) and portable-rpcgen (in order to
correctly work under Windows, as well as get rid of some crashes).
Initially i wanted to upstream portablexdr fixes and emailed the author.
But the author replied that he is not going to fix portablexdr because it's
now deprecated, since original XDR code comes under free license now. So, i
have all necessary fixes in my own fork. He suggested me to come here to ask
about these things.
So, guys, how do you do it ? I cannot find any rpcgen package usable under
Windows (MinGW, not Cygwin).
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
10 years
Re: [libvirt] [libvirt-php] memory overflow when using libvirt_list_networks
by Kash Pande
On 18/04/15 04:25 AM, Michal Novotny wrote:
> Hi Kash,
>
> there were no patches for libvirt-php for a long time. Are you sure
> this is libvirt-php related and not a bug in libvirt itself?
>
> Thanks,
> Michal
>
I've just started using libvirt-php this week but I've been using
libvirt for ages.
I did learn last night, the difference between my two systems that is
relevant is that the overflow system ran Gentoo while the "working"
system ran Debian. I was missing a USE flag for "virt-network" on the
Gentoo machine. It is a development environment that I am attempting to
create a supported configuration with, so these kinds of missing USE
flags and other things are just facts of life I must accept.
Unfortunately, it was kind-of difficult to get this information or even
workaround it without rebuilding libvirt on the Gentoo machine, which
means I won't be able to give a proper error message to users who
encounter this problem as well.
It's a problem in libvirt-php to overflow when requesting
libvirt_networks_list on a machine without networking support compiled
in. The PHP bindings should error out properly, not memory overflow and
put errors in httpd log with cryptic results in the interpreter :-)
I do like the PHP bindings but they appear to be lacking attention. Am I
the only one using it? ;-)
Kash Pande
Jentu Technologies, Inc
http://jentu-networks.com
10 years