Thank you, Daniel !
I appreciate that.
Signed-off-by: Zhang Bo
Signed-off-by: Wu Qingliang
> -Original Message-
> From: Daniel P. Berrangé [mailto:berra...@redhat.com]
> Sent: Thursday, March 12, 2020 12:22 AM
> To: Zhangbo (Oscar)
> Cc: libvir-list@redhat.com; dengkai
Zhangbo (Oscar) 将撤回邮件“[PATCH 6/6] docs: update virt-admin.rst for
server-update-tls”。
Zhangbo (Oscar) 将撤回邮件“[PATCH 5/6] virt-admin: Introduce command srv-update-tls”。
Zhangbo (Oscar) 将撤回邮件“[PATCH 1/6] virnettlscontext: refactoring
virNetTLSContextLoadCredentials”。
Zhangbo (Oscar) 将撤回邮件“[PATCH 4/6] admin: support server cert update mode”。
Zhangbo (Oscar) 将撤回邮件“[PATCH 3/6] admin: Introduce virAdmServerUpdateTlsFiles”。
Zhangbo (Oscar) 将撤回邮件“[PATCH 2/6] virnetserver: Introduce
virNetServerUpdateTlsFiles”。
Zhangbo (Oscar) 将撤回邮件“[PATCH 0/6] update tls files without restarting libvirtd”。
wire-up virAdmServerUpdateTlsFiles API into virt-admin client.
---
tools/virt-admin.c | 88 ++
1 file changed, 88 insertions(+)
diff --git a/tools/virt-admin.c b/tools/virt-admin.c
index 32edfe5757..85235ae03d 100644
--- a/tools/virt-admin.c
+++
Update the manpage for the 'server-update-tls' command
---
docs/manpages/virt-admin.rst | 21 +
1 file changed, 21 insertions(+)
diff --git a/docs/manpages/virt-admin.rst b/docs/manpages/virt-admin.rst
index 51c3d3917e..e19d1f1577 100644
--- a/docs/manpages/virt-admin.rst
+++
virAdmServerUpdateTlsFiles:
@flags specifies how to update server cert/key in tls service.
Two modes are currently supported: append mode and clear mode, means
whether to clear the original cert then add the new one, or just append
to the original one.
---
include/libvirt/libvirt-admin.h | 14
The server needs to use CA certificate, CRL, server certificate/key to
complete the TLS handshake. If these files change, we need to restart
libvirtd for them to take effect. This API can update the TLS context
without restarting libvirtd.
---
include/libvirt/libvirt-admin.h | 4
Encapsulate the code for setting TLS-related files into functions,
which is convenient for other modules to call.
---
src/rpc/virnettlscontext.c | 135 ++---
1 file changed, 82 insertions(+), 53 deletions(-)
diff --git a/src/rpc/virnettlscontext.c
Add an API to update server's tls context before admin method can be
introduced.
---
include/libvirt/libvirt-admin.h | 8
src/libvirt_remote.syms | 1 +
src/rpc/virnetserver.c | 72 +
src/rpc/virnetserver.h | 3 ++
When a client wants to establish a TLS connection with libvirtd, a CRL
file， CA cert and server cert/key are used. Right
now, if these files are changed, you must restart libvirtd to make them
take effect. The restart behavior of libvirtd will cause clients
connecting with libvirtd to fail.
In a
This is an RFC request for supporting virt-admin to update cacrl without
restarting libvirtd.
When a client wants to establish a TLS connection with libvirtd, a CRL file is
used by libvirtd to verify the client's certificate. Right now, if the CRL file
is changed, you must restart libvirtd to
>[...]
>
>> >>This does not play well with the fact that processes as the PR helper
>> >>are always required.
>> >>
>> >>Merging them into libvirtd would make the VM stop until libvirtd is
>> >>running again. Additionally if any of the operations require persistent
>> >>kernel state as e.g. file
>>> qemu-pr-helper exits to help qemu do the high-privileged scsi related
>>> jobs.
>>LIBVIRTD is responsible to launch qemu-pr-helper and qemu, and set
>>selinux/DAC labels for them and their socket.
>>>
>>> #
>>> #
>>> #
>>> #
>>> # ___
>>> #
>> qemu-pr-helper exits to help qemu do the high-privileged scsi related
>> jobs.
>LIBVIRTD is responsible to launch qemu-pr-helper and qemu, and set
>selinux/DAC labels for them and their socket.
>>
>> #
>> #
>> #
>> #
>> # ___
>> #
>> Hi all:
>> qemu-pr-helper exits to help qemu do the high-privileged scsi related
>> jobs.
>LIBVIRTD is responsible to launch qemu-pr-helper and qemu, and set
>selinux/DAC labels for them and their socket.
>>
>> #
>> #
>> #
>> #
>> # ___
>> #
Hi all:
qemu-pr-helper exits to help qemu do the high-privileged scsi related
jobs. LIBVIRTD is responsible to launch qemu-pr-helper and qemu, and set
selinux/DAC labels for them and their socket.
#
#
#
#
# ___
#
>>>Host can read all of the guest's memory or mount the image and modify
>>>the guest agent. Or even add their own communication program that can
>>>do anything.
>>>
>>
>>I get your point now! :) Thanks a lot!!
>>
>>Further more, kvm seems not as secure as xen, because xen isolates dom0 and
>On Fri, Aug 25, 2017 at 08:52:16 +0000, Zhangbo (Oscar) wrote:
>> >On Fri, Aug 25, 2017 at 06:45:18 +0000, Zhangbo (Oscar) wrote:
>
>[...]
>
>> >> The Administrator also can use other commands such as "
>> >guest-file-open" that also caus
>
>Host can read all of the guest's memory or mount the image and modify
>the guest agent. Or even add their own communication program that can
>do anything.
>
I get your point now! :) Thanks a lot!!
Further more, kvm seems not as secure as xen, because xen isolates dom0 and
domU well,
The
>On Fri, Aug 25, 2017 at 06:45:18AM +0000, Zhangbo (Oscar) wrote:
>>Hi all:
>> The Host Administrator is capable of running any exec in guests via the
>qemu-ga command "guest-exec", eg:
>>
>>virsh qemu-agent-command test_guest '{"execute&quo
>On Fri, Aug 25, 2017 at 06:45:18 +0000, Zhangbo (Oscar) wrote:
>> Hi all:
>> The Host Administrator is capable of running any exec in guests via the
>qemu-ga command "guest-exec", eg:
>>
>> virsh qemu-agent-command test_guest '{"
Hi all:
The Host Administrator is capable of running any exec in guests via the
qemu-ga command "guest-exec", eg:
virsh qemu-agent-command test_guest '{"execute": "guest-exec",
"arguments": {"path": "ifconfig", "arg": [ "eth1", "192.168.0.99"
],"capture-output": true } }'
Ping
As REBOOT is concerned with both qemu and libvirtd, it's not atomic job, thus,
it maybe not just qemu's bug.
Maybe libvirtd should also send RESET qmp command after migration, what do you
think of that?
We've tried to send fakeReboot to dest side to fix this problem, it seems to
have
>>> Hi all:
>>> Here's the steps we produce the problem:
>>> 1 reboot guest with the flag of
>VIR_DOMAIN_REBOOT_ACPI_POWER_BTN
>>> 2 sleep 1 second (so that the guest is still rebooting, although the API
>>already returned.)
>>> 3 migrate the guest
>>>
>>> The problem is that : the
>> Hi all:
>> Here's the steps we produce the problem:
>> 1 reboot guest with the flag of VIR_DOMAIN_REBOOT_ACPI_POWER_BTN
>> 2 sleep 1 second (so that the guest is still rebooting, although the API
>already returned.)
>> 3 migrate the guest
>>
>> The problem is that : the guest failed
Hi all:
Here's the steps we produce the problem:
1 reboot guest with the flag of VIR_DOMAIN_REBOOT_ACPI_POWER_BTN
2 sleep 1 second (so that the guest is still rebooting, although the API
already returned.)
3 migrate the guest
The problem is that : the guest failed to migrate to the
>> Hi all:
>> I downloaded libvirt v1.3.4 from http://libvirt.org/sources, and try to
>make syntax-check inside the code tree.
>> But I encounted with many problems, first, I need to have file .gitignore
>and directory .git, and then have gnulib, many problems still comes out after
>that.
Hi all:
I downloaded libvirt v1.3.4 from http://libvirt.org/sources, and try to
make syntax-check inside the code tree.
But I encounted with many problems, first, I need to have file .gitignore
and directory .git, and then have gnulib, many problems still comes out after
that.
I
Hi all:
As we know, "32768~61000" are random ports reserved for customized use.
49152-49215 is in that range.
We think that setting migration port into this range, is a little
risky. Because other applications may have already taken these ports before we
migrate a guest, then the
Hi all:
Suppose we have a guest domain which is pvops, for example, rhel6.4.
Steps to produce the problem:
1 start the guest by virDomainCreate()
2 the API returns before the guest domain fully available, which
>means,
>>> the disks, network interfaces
>>Hi all:
>>I want to get the coverage result of 'make check', here is my way:
>>1. ./configure *
>>2. make clean -j
>>*3*. find ./ -name Makefile |xargs sed -i "s/\= gcc/= gcc -fprofile-arcs
>-ftest-coverage/g" # add gcov-related cflags
>>4. make check -j
>>5.
Hi all:
I want to get the coverage result of 'make check', here is my way:
1. ./configure *
2. make clean -j
*3*. find ./ -name Makefile |xargs sed -i "s/\= gcc/= gcc -fprofile-arcs
-ftest-coverage/g" # add gcov-related cflags
4. make check -j
5. lcov -d . -c
>> Hi all:
>> Suppose we have a guest domain which is pvops, for example, rhel6.4.
>>
>> Steps to produce the problem:
>> 1 start the guest by virDomainCreate()
>> 2 the API returns before the guest domain fully available, which means,
>the disks, network interfaces and some import
Hi all:
Suppose we have a guest domain which is pvops, for example, rhel6.4.
Steps to produce the problem:
1 start the guest by virDomainCreate()
2 the API returns before the guest domain fully available, which means, the
disks, network interfaces and some import services are
>
>On Fri, Mar 11, 2016 at 09:26:23 +, Zhangbo (Oscar) wrote:
>> After rethinking, I guess there's still a problem:
>>
>>Suggest that
>>1 the device got detached in qemu after 10 secs,
>>2 the func virDomainDetachDeviceFlags() has already
Fri, Mar 11, 2016 at 07:40:54 +0000, Zhangbo (Oscar) wrote:
>>> Hi,all:
>>>
>>>I find that we remove devices only after DEVICE_DELETED
>>event.(patch:3fbf78bd).
>>>And it treats TIMEOUT as success. The detailed codes are shown as
>&
>
>On Fri, Mar 11, 2016 at 07:40:54 +, Zhangbo (Oscar) wrote:
>> Hi,all:
>>
>>I find that we remove devices only after DEVICE_DELETED
>event.(patch:3fbf78bd).
>>And it treats TIMEOUT as success. The detailed codes are shown as
>below:
>>
Hi,all:
I find that we remove devices only after DEVICE_DELETED
event.(patch:3fbf78bd).
And it treats TIMEOUT as success. The detailed codes are shown as below:
rc = qemuDomainWaitForDeviceRemoval(vm);
if (rc == 0 || rc == 1)
ret =
>> Hi all:
>> AFAIK, there're several ways to test libvirt:
>> 1) virt-test, which is driven by autotest or avocado-vt, based on
>qemu-kvm
>> 2) test driver which is parall to other drivers such as qemu_driver and
>libxl_driver in libvirt.
>> 3) make -c tests, which aims to do low
>On Wed, Feb 24, 2016 at 07:31:56AM +0000, Zhangbo (Oscar) wrote:
>> Hi all:
>> AFAIK, there're several ways to test libvirt:
>> 1) virt-test, which is driven by autotest or avocado-vt, based on
>qemu-kvm
>> 2) test driver which is parall to oth
Hi all:
AFAIK, there're several ways to test libvirt:
1) virt-test, which is driven by autotest or avocado-vt, based on qemu-kvm
2) test driver which is parall to other drivers such as qemu_driver and
libxl_driver in libvirt.
3) make -c tests, which aims to do low level tests, that
46 matches
Mail list logo
