[PATCH v6 0/3] Fix virtio console port assignment issue
by Aaron M. Brown
Changelog:
---
v6:
- Fixed issue with console auto port index starting from 1 instead of 0
---
v5:
- Added xml tests to tests/qemuxmlconfdata
- Fixed virito -> virtio typo in commit message
---
v4:
- Update commit messages
---
v3:
- Added Reviewed-By
- Included CI Results Link
---
v2:
- Split patch into two commits
- Added fixes tag
---
This libvirt patch series does the following:
1. fixes an issue with virtio console device port auto assignment on virtio-serial buses
2. updates console port reservation comment and changes the allowZero variable to allowPortZero for clarity
3. Adds tests for virtio console on the vioserial bus
Currently in libvirt, a virtio console device cannot be auto assigned a port number greater than zero on a virtio-serial bus. This leads to port collision errors when adding more than 1 virtio console device on a single virtio-serial bus.
After applying this patch, one can add multiple console ports under a single virtio-serial bus.
Here is a link to CI results for this series: https://gitlab.com/aaronbmalik/libvirt/-/pipelines/1942021076
Aaron M. Brown (3):
tests: Add console-virtio-vioserial tests
domain_addr: Fix virtio console port autoassign on virtio-serial bus
domain_addr: update virtconsole port reservation comment and allowZero
var
src/conf/domain_addr.c | 50 ++++++++++-----
...rial-autoassign-address.x86_64-latest.args | 44 +++++++++++++
...erial-autoassign-address.x86_64-latest.xml | 63 +++++++++++++++++++
...nsole-virtio-serial-autoassign-address.xml | 48 ++++++++++++++
tests/qemuxmlconftest.c | 1 +
5 files changed, 192 insertions(+), 14 deletions(-)
create mode 100644 tests/qemuxmlconfdata/console-virtio-serial-autoassign-address.x86_64-latest.args
create mode 100644 tests/qemuxmlconfdata/console-virtio-serial-autoassign-address.x86_64-latest.xml
create mode 100644 tests/qemuxmlconfdata/console-virtio-serial-autoassign-address.xml
--
2.39.5 (Apple Git-154)
5 hours, 58 minutes
[PATCH] NEWS: document bhyve changes for the release
by Roman Bogorodskiy
Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com>
---
NEWS.rst | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 6cc8f23225..447259d66e 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -40,6 +40,17 @@ v11.6.0 (unreleased)
be modified by setting the ``default_cpu_deprecated_features`` option in
the qemu.conf file.
+ * bhyve: Add TCP console support
+
+ TCP serial devices can now be configured with ``<serial type='tcp'>``::
+
+ <serial type='tcp'>
+ <source mode='bind' host='127.0.0.1' service='12345'/>
+ <target type='serial' port='0'/>
+ </serial>
+
+ Additionally, number of supported consoles increased to 4.
+
* **Improvements**
* qemu: Change default SCSI controller model to ``virtio-scsi`` for ARM and RISC-V
@@ -54,8 +65,16 @@ v11.6.0 (unreleased)
supposed to be called on one of the hosts represented in the input CPU
definitions. Otherwise the API will give unexpected results.
+ * bhyve: Add timeout handling for bhyveload
+
+ It is now possible to run ``bhyveload`` with the ``timeout`` tool, which
+ can send ``SIGTERM`` and ``SIGKILL`` signals when timeout is reached.
+ Timeout values are set using the ``bhyveload_timeout`` and
+ ``bhyveload_timeout_kill`` configuration options in ``bhyve.conf``.
+
* **Bug fixes**
+ * bhyve: Fix resetting of the autostart flag of the domain on destroy.
v11.5.0 (2025-07-01)
====================
--
2.49.0
13 hours, 42 minutes
[PATCH v5 0/5] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling
Changelog
v5
- dropped the "none" test in qemuxmlactivetest (see commit for
details)
- reordered patches to introduce some tests first, then add
qemu.conf changes
v4
- added qemu.conf option to dictate the default behavior for the
deprecated_features attribute (Boris)
- added qemuxmlactivetests (Boris)
- snuck in missing documentation for deprecated_features in
formatdomain.rst
v3
- added qemu caps check to avoid breaking s390 guests trying to
default deprecated_features='off' on QEMU versions that
do not support reporting these features
v2
- changed behavior from disabling features on the host model to
instead flagging the guest CPU to disable deprecated features
- removed disabling deprecated features on host model in
virQEMUCapsInitCPUModelS390
- added flagging deprecated_feats in qemuProcessUpdateGuestCPU
- added tests for deprecated_features='on'
- split virQEMUCapsUpdateCPUDeprecatedFeatures update and
qemuProcessUpdateGuestCPU changes
The intention of reporting deprecated features and modifying the guest
CPU model was to alleviate the user from the burden of preparing a guest
with the necessary amendments to assure migration to newer hardware.
While that goal was met by way of the "deprecated_features='on|off'"
attribute, it still adds an extra step that the user must be aware to
prepare a guest for migration and the errors that stem from an
unsuccessful migration (due to feature incompatibility) is not always
clear how to resolve.
These patches make s390 CPU *host models* migration ready from the get-go
by introducing a qemu.conf option for disabling deprecated features by
default. They may still be disabled for other model types via the
respective attribute, or reenabled if desired. The configured behavior
may be overridden by explicitly providing the attribute within the
guest XML.
Boris Fiuczynski (2):
tests: new qemuxmlactive tests for s390x
qemu: add default_cpu_deprecated_features configuration option
Collin Walling (3):
docs: domain: document deprecated_features attribute
qemu: caps: add virCPUFeaturePolicy param to
virQEMUCapsUpdateCPUDeprecatedFeatures
qemu: process: refactor deprecated features code
docs/formatdomain.rst | 8 ++++
src/qemu/libvirtd_qemu.aug | 3 ++
src/qemu/qemu.conf.in | 14 ++++++
src/qemu/qemu_capabilities.c | 6 +--
src/qemu/qemu_capabilities.h | 3 +-
src/qemu/qemu_conf.c | 33 +++++++++++++
src/qemu/qemu_conf.h | 12 +++++
src/qemu/qemu_driver.c | 3 +-
src/qemu/qemu_process.c | 46 +++++++++++++++----
src/qemu/test_libvirtd_qemu.aug.in | 1 +
...cated-features-off-active.s390x-latest.xml | 25 ++++++++++
...ted-features-off-inactive.s390x-latest.xml | 25 ++++++++++
...ecated-features-on-active.s390x-latest.xml | 25 ++++++++++
...ated-features-on-inactive.s390x-latest.xml | 25 ++++++++++
tests/qemuxmlactivetest.c | 10 +++-
...deprecated-features-none.s390x-latest.args | 32 +++++++++++++
...-deprecated-features-none.s390x-latest.xml | 25 ++++++++++
.../cpu-model-deprecated-features-none.xml | 15 ++++++
...l-deprecated-features-on.s390x-latest.args | 32 +++++++++++++
...el-deprecated-features-on.s390x-latest.xml | 25 ++++++++++
.../cpu-model-deprecated-features-on.xml | 15 ++++++
...default-video-type-s390x.s390x-latest.args | 2 +-
...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +-
.../launch-security-s390-pv.s390x-latest.args | 2 +-
...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +-
.../s390-defaultconsole.s390x-latest.args | 2 +-
.../s390-panic.s390x-latest.args | 2 +-
tests/qemuxmlconftest.c | 2 +
28 files changed, 375 insertions(+), 22 deletions(-)
create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-off-active.s390x-latest.xml
create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-off-inactive.s390x-latest.xml
create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-on-active.s390x-latest.xml
create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-on-inactive.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-none.s390x-latest.args
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-none.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-none.xml
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.args
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.xml
--
2.49.0
16 hours, 7 minutes
[PATCH] NEWS: mention disabling deprecated features by default on s390 CPU models
by Collin Walling
Signed-off-by: Collin Walling <walling(a)linux.ibm.com>
---
NEWS.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index e5e8626729..6cc8f23225 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -32,6 +32,14 @@ v11.6.0 (unreleased)
that is liable to cause crashes of the source QEMU when performing long
running live migration operations with TLS enabled.
+ * Add support for disabling deprecated CPU model features by default for s390 domains
+
+ Starting an s390 domain with host-model will now default to setting the
+ ``deprecated_features`` attribute to ``off``, ensuring the domain starts
+ with a migration-compatible CPU model to newer systems. This behavior can
+ be modified by setting the ``default_cpu_deprecated_features`` option in
+ the qemu.conf file.
+
* **Improvements**
* qemu: Change default SCSI controller model to ``virtio-scsi`` for ARM and RISC-V
--
2.49.0
17 hours, 24 minutes
[RFC] x86 Host CPU features detection by MSRs
by Hector Cao
Hello,
This mail is a Request for Comment.
On recent Intel CPUs, some of the CPU features (mostly vmx-* subfeatures)
are listed and controlled
via the MSRs (Model Specific Registers) instead of the traditional CPUID
instruction method.
Right now, libvirt reads the MSR's values via /dev/cpu/*/cpu populated by
the msr kernel module.
src/cpu/cpu_x86.c:
...
/* This is best effort since there might be no way to read the MSR
* when we are not running as root. */
for (i = 0; i < nmsrs; i++) {
if (virHostCPUGetMSR(msrs[i], &msr) == 0) {
virCPUx86DataItem item = {
.type = VIR_CPU_X86_DATA_MSR,
.data.msr = {
...
There are 2 potential issues:
1) As stated in the source code comment above, MSR values read might fail
when libvirt is not run as root.
2) MSR values read might fail if the MSR kernel module is not loaded, this
is still the case in some of the Linux distros.
The issue 2) has been brought up in Ubuntu/Debian :
https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/271
but the feedback was to try to fix the issue in the libvirt source code
itself. Indeed, libvirt already loads some kernel modules it depends on.
For example the NBD kernel module in src/util/virtfile.c
...
static bool
virFileNBDLoadDriver(void)
{
if (virKModIsProhibited(NBD_DRIVER)) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Failed to load nbd module: administratively
prohibited"));
return false;
} else {
g_autofree char *errbuf = NULL;
if ((errbuf = virKModLoad(NBD_DRIVER))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Failed to load nbd module"));
...
Andrea Bolognani's proposal of an approach that could work:
1. try using the unprivileged KVM API is available (or maybe the
necessary information is exposed via QMP too?) like how QEMU does;
2. if that fails, try using the privileged /dev API;
3. if that fails too, load the msr module and try again;
I would like to have some feedback from the libvirt community about if that
is worth tackling these issues and the right way to do that.
If we can end up with an agreement in this mail thread, I can work on the
solution implementation and send it in a separate submission.
Best regards,
Hector
17 hours, 28 minutes
Re: Clarification Needed: virsh snapshot-delete Behavior with
External Snapshots (--disk-only)
by Peter Krempa
On Wed, Jul 23, 2025 at 04:57:57 +0000, P, Rajasekar via Users wrote:
> Hello libvirt community,
>
> I am seeking clarification on the behavior of `virsh snapshot-delete` when used with external snapshots (created with the `--disk-only` option).
>
> **Environment:**
> - libvirt version: 10.5.0
Note that this was released almost a year ago.
> - Kernel version: 5.14.0-503.22.1.el9_5.x86_64
> - Disk image format: qcow2
> - Host OS: RHEL 9.5
>
> **Steps to reproduce:**
> 1. Create an external snapshot:
> virsh snapshot-create-as --domain <vm> --name snap1 --disk-only --atomic
> 2. Delete the snapshot:
> virsh snapshot-delete <vm> --snapshotname snap1
>
> **Observed behavior:**
> - Changes from the overlay (snapshot) file are merged into the base image.
> - The snapshot metadata is removed from libvirt.
> - The snapshot file remains on disk (appears orphaned).
You mean that the original overlay images remained on disk? e.g.
/path/to/originalimage.snap1 ?
> **Questions:**
> - Is the observed automatic merge of the overlay file into the base image during `snapshot-delete` the intended behavior for external snapshots in recent libvirt versions? Or we need separate `blockcommit` step.
Yes it is intended, because deleting a snapshot is effectively meaning
"I don't want to return to this point any more" so the extra overlay
makes no sense.
> - Should the snapshot file be deleted automatically, or is manual cleanup required?
If you mean the overlay, then yes it should have been deleted.
> - Is there any official documentation that clarifies this behavior for external snapshots, as most documentation seems to focus on internal snapshots?
The semantics of external and internal snapshots are supposed to be
indentical. I don't think we document to a deep extent the actual
behaviour WRT to the disk files.
17 hours, 30 minutes
[PATCH v4 00/23] LIBVIRT: X86: TDX support
by Zhenzhong Duan
Hi,
This series brings libvirt the x86 TDX support.
* What's TDX?
TDX stands for Trust Domain Extensions which isolates VMs from
the virtual-machine manager (VMM)/hypervisor and any other software on
the platform.
This patchset extends libvirt to support TDX, with which one can start a TDX
guest from high level rather than running qemu directly.
* Misc
As QEMU use a software emulated way to reset guest which isn't supported by TDX
guest for security reason. We simulate reboot for TDX guest by kill and create a
new one in FakeReboot framework.
Complete code can be found at [1].
* Test
Tested with upstream qemu v10.0.0-1724-gf9a3def17b
shutdown/reboot/reset with virsh
shutdown/reboot trigger in guest
shutdown with on_poweroff=destroy/restart
reboot with on_reboot=destroy/restart
GUEST_PANICKED event processing
auto firmware matching
* Patch organization
- patch 1-4: Some preparing work
- patch 5-6: Support query of TDX capabilities
- patch 7-15: Add TDX type to launchsecurity framework
- patch 16-21: Add reboot/reset support to TDX guest
- patch 22: Add conf test dump/cases for '+inteltdx' variant
- patch 23: Add docs
TODO:
- add reconnect logic in virsh command
[1] https://github.com/intel/libvirt-tdx/commits/tdx_for_upstream_v4
Thanks
Zhenzhong
Changelog:
v4:
- add QGS config to qemuxmlconftest (Daniel)
- use 0x10000000 policy value in test as debug isn't supported yet (Daniel)
- s/mrowner/mrOwner/ s/mrownerconfig/mrOwnerConfig/ (Daniel)
- s/quoteGenerationSocket/quoteGenerationService/ (Daniel)
- handle "GUEST_PANICKED" event of type tdx (Daniel)
- add automatic firmware matching (Daniel)
v3:
- fix a hiden failure in qemuBuildTDXQGSCommandLine() (Peter Krempa)
- avoid the use of the ternary operator (Peter Krempa)
- add capability test dump before capability introduced (Peter Krempa)
- change tests version number from 11.0.0 to 10.1.0 (Peter Krempa)
v2:
- add capability and xmlconf test (Peter Krempa)
v1:
- s/virQEMUCapsKVMSupportsSecureGuestINTEL/virQEMUCapsKVMSupportsSecureGuestTDX (Daniel)
- make policy element optional and expose to QEMU directly (Daniel)
- s/qemuProcessSecFakeReboot/qemuProcessFakeRebootViaRecreate (Daniel)
- simplify QGS element schema by supporting only UNIX socket (Daniel)
- add new events VIR_DOMAIN_EVENT_[STOPPED|STARTED] for control plane (Daniel)
- s/quoteGenerationService/quoteGenerationSocket as QEMU
- add virsh reset support
rfcv4:
- add a check to tools/virt-host-validate-qemu.c (Daniel)
- remove check of q35 (Daniel)
- model 'SocktetAddress' QAPI in xml schema (Daniel)
- s/Quote-Generation-Service/quoteGenerationService/ (Daniel)
- define bits in tdx->policy and add validating logic (Daniel)
- presume QEMU choose split kernel irqchip for TDX guest by default (Daniel)
- utilize existing FakeReboot framework to do reboot for TDX guest (Daniel)
- drop patch11 'conf: Add support to keep same domid for hard reboot' (Daniel)
- add test in tests/ to validate parsing and formatting logic (Daniel)
- add doc in docs/formatdomain.rst (Daniel)
- add R-B
rfcv3:
- Change to generate qemu cmdline with -bios
- drop firmware auto match as -bios is used
- add a hard reboot method to reboot TDX guest
rfcv3: https://www.mail-archive.com/devel@lists.libvirt.org/msg00385.html
rfcv2:
- give up using qmp cmd and check TDX directly on host for TDX capabilities.
- use launchsecurity framework to support TDX
- use <os>.<loader> for general loader
- add auto firmware match feature for TDX
A example TDVF fimware description file 70-edk2-x86_64-tdx.json:
{
"description": "UEFI firmware for x86_64, supporting Intel TDX",
"interface-types": [
"uefi"
],
"mapping": {
"device": "generic",
"filename": "/usr/share/OVMF/OVMF_CODE-tdx.fd"
},
"targets": [
{
"architecture": "x86_64",
"machines": [
"pc-q35-*"
]
}
],
"features": [
"intel-tdx",
"verbose-dynamic"
],
"tags": [
]
}
rfcv2: https://www.mail-archive.com/libvir-list@redhat.com/msg219378.html
Zhenzhong Duan (23):
tools: Secure guest check for Intel in virt-host-validate
qemu: Check if INTEL Trust Domain Extention support is enabled
qemucapabilitiesdata: Document '+inteltdx' variant
qemucapabilitiestest: Add data for the qemu-10.1.0 dev cycle on x86_64
for the '+inteltdx' variant
qemu: Add QEMU_CAPS_TDX_GUEST capability
conf: Expose TDX feature in domain capabilities
conf: Add tdx as launch security type
conf: Validate TDX launchSecurity element
mrConfigId/mrOwner/mrOwnerConfig
qemu: Add command line and validation for TDX type
conf: Expose TDX type in domain launch security capability
qemu: Force special parameters enabled for TDX guest
qemu: log the crash information for TDX
qemu_firmware: Pick the right firmware for TDX guests
conf: Add Intel TDX Quote Generation Service(QGS) support
qemu: Add command line for TDX Quote Generation Service(QGS)
qemu: Add FakeReboot support for TDX guest
qemu: Support reboot command in guest
qemu: Avoid duplicate FakeReboot for secure guest
qemu: Send event VIR_DOMAIN_EVENT_[STOPPED|STARTED] during recreation
qemu: Bypass sending VIR_DOMAIN_EVENT_RESUMED event when TD VM reboot
qemu: Support domain reset command for TDX guest
qemuxmlconftest: Add latest version of 'launch-security-tdx*' test
data
docs: domain: Add documentation for Intel TDX guest
docs/formatdomain.rst | 63 +
docs/formatdomaincaps.rst | 1 +
examples/c/misc/event-test.c | 6 +
include/libvirt/libvirt-domain.h | 2 +
src/conf/domain_capabilities.c | 1 +
src/conf/domain_capabilities.h | 1 +
src/conf/domain_conf.c | 82 +
src/conf/domain_conf.h | 21 +
src/conf/domain_validate.c | 11 +
src/conf/schemas/domaincaps.rng | 9 +
src/conf/schemas/domaincommon.rng | 41 +
src/conf/virconftypes.h | 2 +
src/qemu/qemu_capabilities.c | 38 +-
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_cgroup.c | 1 +
src/qemu/qemu_command.c | 43 +
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_driver.c | 11 +-
src/qemu/qemu_firmware.c | 20 +
src/qemu/qemu_monitor.c | 50 +-
src/qemu/qemu_monitor.h | 13 +-
src/qemu/qemu_monitor_json.c | 38 +-
src/qemu/qemu_namespace.c | 1 +
src/qemu/qemu_process.c | 104 +-
src/qemu/qemu_process.h | 2 +
src/qemu/qemu_validate.c | 45 +
src/security/security_dac.c | 2 +
.../qemu_10.1.0-q35.x86_64+inteltdx.xml | 783 +
.../domaincapsdata/qemu_10.1.0-q35.x86_64.xml | 7 +-
.../qemu_10.1.0-tcg.x86_64+inteltdx.xml | 1830 +
.../domaincapsdata/qemu_10.1.0-tcg.x86_64.xml | 6 +-
.../qemu_10.1.0.x86_64+inteltdx.xml | 783 +
tests/domaincapsdata/qemu_10.1.0.x86_64.xml | 7 +-
tests/domaincapsmock.c | 3 +-
tests/qemucapabilitiesdata/README.rst | 5 +
.../caps_10.1.0_x86_64+inteltdx.replies | 44552 ++++++++++++++++
.../caps_10.1.0_x86_64+inteltdx.xml | 3585 ++
.../caps_10.1.0_x86_64.xml | 1 +
.../caps.x86_64+inteltdx.xml | 29 +
.../firmware/60-edk2-ovmf-x64-inteltdx.json | 1 +
...h-security-tdx.x86_64-latest+inteltdx.args | 44 +
...ch-security-tdx.x86_64-latest+inteltdx.xml | 75 +
tests/qemuxmlconfdata/launch-security-tdx.xml | 28 +
tests/qemuxmlconftest.c | 3 +
tools/virsh-domain-event.c | 6 +-
tools/virt-host-validate-common.c | 31 +-
tools/virt-host-validate-common.h | 1 +
47 files changed, 52372 insertions(+), 18 deletions(-)
create mode 100644 tests/domaincapsdata/qemu_10.1.0-q35.x86_64+inteltdx.xml
create mode 100644 tests/domaincapsdata/qemu_10.1.0-tcg.x86_64+inteltdx.xml
create mode 100644 tests/domaincapsdata/qemu_10.1.0.x86_64+inteltdx.xml
create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_x86_64+inteltdx.replies
create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_x86_64+inteltdx.xml
create mode 100644 tests/qemucaps2xmloutdata/caps.x86_64+inteltdx.xml
create mode 100644 tests/qemuxmlconfdata/launch-security-tdx.x86_64-latest+inteltdx.args
create mode 100644 tests/qemuxmlconfdata/launch-security-tdx.x86_64-latest+inteltdx.xml
create mode 100644 tests/qemuxmlconfdata/launch-security-tdx.xml
--
2.47.1
19 hours, 46 minutes
شهادة الأبوة في المغرب
by walid falcon
كل ما تحتاج معرفته حول شهادة الأبوة بالمغرب
يمكنك تحميل الطلب من خلال الرابط المباشر
https://www.targir.com/2025/04/blog-post_14.html
معلومات شاملة لاستخراج شهادة الأبوة والإجراءات القانونية المرتبطة بها
ما هي شهادة الأبوة في المغرب؟
شهادة الأبوة وثيقة قانونية تصدر بناءً على حكم قضائي، وتُثبت العلاقة البنوية
بين الطفل ووالده البيولوجي، في حال عدم وجود عقد زواج رسمي أو تسجيل سابق.
تُعَد هذه الشهادة جزءًا من الإجراءات القضائية التي تدخل ضمن قضايا الحالة
المدنية.
الحالات التي تستوجب استخراج شهادة الأبوة
1. الأطفال غير المسجلين في الحالة المدنية
عندما يولد طفل خارج إطار الزواج أو لم يُسجَّل بصفة قانونية في دفتر الحالة
المدنية، يحتاج الأب إلى رفع دعوى للحصول على شهادة الأبوة.
2. إثبات النسب في غياب عقد زواج
في حالات عدم توفر وثيقة الزواج بين الأبوين، يُلجأ إلى المحكمة لتقديم
التصريح بالأبوة.
إجراءات الحصول على شهادة الأبوة
أولا: رفع دعوى أمام المحكمة
يتوجب على الأب أو ولي أمر الطفل تقديم طلب إلى المحكمة الابتدائية التي يقع
فيها مقر سكن الطفل أو الأب، وذلك من أجل إصدار حكم قضائي بإثبات الأبوة.
ثانياً: الوثائق المطلوبة
نسخة من بطاقة التعريف الوطنية
عقد الازدياد الخاص بالطفل (إن وُجد)
شهادة طبية للولادة
شهادة السكنى
وثائق أو إثباتات تدعم علاقة الأب بالطفل
نموذج شهادة الأبوة pdf
تتيح بعض المواقع الإلكترونية تحميل نموذج شهادة الأبوة PDF قابل للطباعة، غير
أن إصدارها الرسمي لا يتم إلا بعد حكم قضائي، ويتم توجيهها لمصلحة الحالة
المدنية لتسجيل الطفل.
الأسئلة الشائعة حول شهادة الأبوة
هل يمكن تقديم طلب شهادة الأبوة إلكترونياً؟
لا، المسطرة تظل قضائية وتتطلب الحضور أمام المحكمة.
ما هي مدة الحصول على شهادة الأبوة؟
قد تختلف المدة حسب عدد الجلسات، ولكن عادة ما تستغرق بين شهر إلى ثلاثة أشهر،
حسب تعقيد الملف.
صلة بين شهادة الأبوة وبعض التصاريح القانونية الأخرى
تم الربط ضمن هذا الدليل بين شهادة الأبوة وبعض المفاهيم القانونية الأخرى
التي يبحث عنها الكثير، مثل:
1. التصريح الأمني وتصريح السفر
غالباً ما يُطلب في بعض الحالات القانونية توفير تصريح أمني عند استخراج أوراق
ثبوتية، كما هو الحال في:
الأوراق المطلوبة لاستخراج تصريح السفر من منطقة التجنيد
تصريح أمني مستعجل
التصريح الأمني الإلكتروني
2. استبدال التصريح برخصة قيادة
في حالات مثل شروط إصدار رخصة قيادة بعد التصريح أو تجديد التصريح إلى رخصة،
من المهم التأكد من إثبات الهوية القانونية، وهو ما يجعل شهادة الأبوة ضرورية
في بعض الحالات القانونية الخاصة.
شهادة الأبوة
الغاية من هذه الوثيقة هي إثبات علاقة الأبوة بالابن سواء كان راشدا أم قاصرا
وغالبا ما تطلب في بعض المساطر الإدارية.
صاحب الطلب
المغربي المقيم بالخارج
الوثائق المطلوبة
بالنسبة للراشد :
· بطاقة التسجيل ؛
· الدفتر العائلي
بالنسبة للقاصر :
· بطاقة تسجيل الأب ؛
· الدفتر العائلي .
المصلحة المكلفة باستلام الوثائق المطلوبة
المصالح القنصلية التابعة لمحل إقامة صاحب الطلب
المصلحة المكلفة بتقديم الخدمة
المصالح القنصلية التابعة لمحل إقامة صاحب الطلب
في حالة تعذر الحصول على الخدمة
مؤسسة الوسيط
لأجل الاتصال
وزارة الشؤون الخارجية والتعاون
مصدر المعلومات (الإدارة المعنية)
وزارة الشؤون الخارجية والتعاون_أرشيف
يمكنك تحميل الطلب من خلال الرابط المباشر
نموذج شهادة الأبوة بالمغرب
محكمة الأسرة بـ: [اسم المدينة]
رقم الملف: [يُترك للمحكمة]
رقم القضية: [يُترك للمحكمة]
بيان تصريح بالأبوة
أنا الموقع أسفله:
الاسم الكامل: [الاسم الكامل للأب]
رقم بطاقة التعريف الوطنية: [رقم CIN]
تاريخ ومكان الازدياد: [تاريخ ومكان ولادة الأب]
العنوان الكامل: [عنوان الإقامة]
المهنة: [المهنة الحالية]
أُصرّح بموجب هذا، وبكامل قواي العقلية والقانونية، بما يلي:
أن الطفل (ة) المسمى (ة): [اسم الطفل/ة]
المولود (ة) بتاريخ: [تاريخ الولادة]
بـ: [مكان الولادة]
هو(هي) ابني/ابنتي البيولوجي(ة)، وقد وُلد(ت) نتيجة علاقة أبوية قائمة بيني
وبين السيدة:
[اسم الأم]، المولودة بتاريخ: [تاريخ ميلاد الأم]، والحاملة لرقم بطاقة
التعريف الوطنية: [رقم CIN الأم].
وأتحمل كامل المسؤولية القانونية والأبوية تجاه هذا الطفل/ة، وأطلب من المحكمة
الموقرة إصدار حكم قضائي يثبت نسب الطفل لي، وتمكينه من التسجيل في الحالة
المدنية.
الإمضاء
الإسم الكامل: _____________________
التوقيع: ___________________________
التاريخ: ____ / ____ / ________
ملاحظات :
يُرفق هذا النموذج بالوثائق الداعمة كـ: نسخة البطاقة الوطنية، شهادة السكنى،
شهادة الولادة، وغيرها.
يُودَع لدى كتابة ضبط المحكمة الابتدائية (قسم قضاء الأسرة) التي يقع ضمن
اختصاصها محل ولادة الطفل أو محل سكن الأب.
1 day, 12 hours
[PATCH] Storage: ZFS: implement `resizeVol` method to support native resize
by George Melikov
From: George Melikov <mail(a)gmelikov.ru>
ZFS doesn't have thick allocations, every allocation is
thin-provisioned, so resize operation is essentially
a zvol size limit change
(`zfs set volsize=X pool/zvol_name`).
Shrink is allowed too (which leads to data destruction),
but shrink restriction is already implemented in libvirt,
so this function doesn't need to check anything.
This patch is posted via PR too and has green test runs
https://gitlab.com/libvirt/libvirt/-/merge_requests/495
Signed-off-by: George Melikov <mail(a)gmelikov.ru>
---
src/storage/storage_backend_zfs.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/src/storage/storage_backend_zfs.c b/src/storage/storage_backend_zfs.c
index 178b505e92..33434d0cac 100644
--- a/src/storage/storage_backend_zfs.c
+++ b/src/storage/storage_backend_zfs.c
@@ -439,6 +439,25 @@ virStorageBackendZFSDeletePool(virStoragePoolObj *pool,
return virCommandRun(cmd, NULL);
}
+static int
+virStorageBackendZFSResizeVol(virStoragePoolObj *pool,
+ virStorageVolDef *vol,
+ unsigned long long capacity,
+ unsigned int flags)
+{
+ virStoragePoolDef *def = virStoragePoolObjGetDef(pool);
+ g_autoptr(virCommand) resize_cmd = NULL;
+
+ virCheckFlags(0, -1);
+
+ resize_cmd = virCommandNewArgList(ZFS, "set", NULL);
+ virCommandAddArgFormat(resize_cmd, "volsize=%llu", capacity);
+ virCommandAddArgFormat(resize_cmd, "%s/%s",
+ def->source.name, vol->name);
+
+ return virCommandRun(resize_cmd, NULL);
+}
+
virStorageBackend virStorageBackendZFS = {
.type = VIR_STORAGE_POOL_ZFS,
@@ -450,6 +469,7 @@ virStorageBackend virStorageBackendZFS = {
.deletePool = virStorageBackendZFSDeletePool,
.uploadVol = virStorageBackendVolUploadLocal,
.downloadVol = virStorageBackendVolDownloadLocal,
+ .resizeVol = virStorageBackendZFSResizeVol,
};
--
2.47.2
1 day, 16 hours
[PATCH 0/2] qemu: Match firmware with fully resolved and canonicalized paths
by James Le Cuirot
From: James Le Cuirot <jlecuirot(a)microsoft.com>
Distros may provide compatibility symlinks after moving firmware files
around, but they won't work for existing VMs when doing a straight
string comparison.
virFileComparePaths has been used to do this, but it was previously
only resolving the last path component, despite what the description
says.
James Le Cuirot (2):
util: Fully resolve paths with virFileComparePaths
qemu: Match firmware with fully resolved and canonicalized paths
src/qemu/qemu_firmware.c | 11 ++++++-----
src/util/virfile.c | 4 ++--
2 files changed, 8 insertions(+), 7 deletions(-)
--
2.49.0
1 day, 17 hours
