Live migration works?
> +Limitations:
> +
> +* Memory usage on host is always wrong and around 82% Usage
> +* Snapshots do not work
> +* edk2-OVMF required
> +* Recommendable: VirtIO RNG for more entropy (VMs sometimes will not
___
pve-devel mailing li
> Can we avoid showing them? I don't think they offer any insight, because
> as I understand it, when starting, the current affinity list is always
> all available cores.
Yes, I have made this change and will add it to my next patch. The change
is simple
adding the 'quiet => 1' argument to the PVE
> Is a string the best way of entering the CPUs in the GUI? Maybe a
> dropdown where you can (un)select the cores?
It would be a nice gui element to have a list of CPU cores with the ability
to select individual ones. Such a feature would require the Options.js to
know how many CPU cores the syste
with Wolfgang's A-B, thanks!
On June 9, 2022 2:31 pm, Fabian Ebner wrote:
> Otherwise, we might run into an abort via bdrv_co_yield_to_drain()
> (can at least happen when a disk with iothread is used):
>> #0 0x7fef4f5dece1 __GI_raise (libc.so.6 + 0x3bce1)
>> #1 0x7fef4f5c8537 __GI_abort
On Thu, Jun 09, 2022 at 02:31:13PM +0200, Fabian Ebner wrote:
> Otherwise, we might run into an abort via bdrv_co_yield_to_drain()
> (can at least happen when a disk with iothread is used):
> > #0 0x7fef4f5dece1 __GI_raise (libc.so.6 + 0x3bce1)
> > #1 0x7fef4f5c8537 __GI_abort (libc.so.6
Otherwise, we might run into an abort via bdrv_co_yield_to_drain()
(can at least happen when a disk with iothread is used):
> #0 0x7fef4f5dece1 __GI_raise (libc.so.6 + 0x3bce1)
> #1 0x7fef4f5c8537 __GI_abort (libc.so.6 + 0x25537)
> #2 0x5641bce3c71f error_exit (qemu-system-x86_64 + 0
minor nit
but otherwise LGTM
On Thu, Jun 09, 2022 at 01:55:38PM +0200, Fabian Ebner wrote:
> Otherwise, we might not run into an abort via bdrv_co_yield_to_drain()
> (can at least happen when a disk with iothread is used):
> > #0 0x7fef4f5dece1 __GI_raise (libc.so.6 + 0x3bce1)
> > #1 0x
Am 09.06.22 um 13:55 schrieb Fabian Ebner:
> Otherwise, we might not run into an abort via bdrv_co_yield_to_drain()
Sorry, the "not" should not be here.
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/li
Otherwise, we might not run into an abort via bdrv_co_yield_to_drain()
(can at least happen when a disk with iothread is used):
> #0 0x7fef4f5dece1 __GI_raise (libc.so.6 + 0x3bce1)
> #1 0x7fef4f5c8537 __GI_abort (libc.so.6 + 0x25537)
> #2 0x5641bce3c71f error_exit (qemu-system-x86_64
This Patch is for enabling AMD SEV (Secure Encrypted Virtualization) support in
QEMU and for supporting other memory encryption technologies like INTEL MKTME
(Multi-key Total Memory Encryption) and AMD-SNP in the future.
Config-Example:
memory_encryption: type=sev,cbitpos=47,policy=0x0005,reduced-
added AMD SEV documentation for "[PATCH qemu-server] QEMU AMD SEV
enable"
Signed-off-by: Markus Frank
---
qm.adoc | 59 +
1 file changed, 59 insertions(+)
diff --git a/qm.adoc b/qm.adoc
index e666d7d..027d0a1 100644
--- a/qm.adoc
+++ b/qm.
On 08.06.2022 17:34, Stefan Hrdlicka wrote:
8<--
+In a ZFS dRAID (declustered RAID) the hot spare drive(s) participate in the
RAID.
+Their spare capacity is reserved and used for rebuilding when one drive fails.
+This provides, depending on the configuration, faster rebuilding compared to a
+RA
12 matches
Mail list logo
