similar to: Cannot pass secret id for backing file after taking external snapshot on encrypted qcow2 file

Hey, guys I've been working on whether libvirt supports encrypted snapshots,Here are my versions of libvirt and qemu [root@xx ~]# libvirtd -V libvirtd (libvirt) 4.5.0 [root@xx ~]# qemu-img -V qemu-img version 2.12.0 (qemu-kvm-ev-2.12.0-33.1.el7_7.4) Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers 1. assign $MYSECRET to libvirt secret using the secret-define and

On Wed, Apr 15, 2020 at 10:53:05 +0800, 18781374080 wrote: > > > > Hey, guys > > I've been working on whether libvirt supports encrypted snapshots,Here are my versions of libvirt and qemu > > [root@xx ~]# libvirtd -V > > libvirtd (libvirt) 4.5.0 This is too-old encrypted backing files work starting from libvirt-5.10 (but I strongly suggest using at least

Hi, Recently I have installed Debian Lenny on two different machines (different ram size, disks, Xeon dual and quad core, filesystems both xfs and ext3, etc). Packages versions: Dom0: ii libc6-xen 2.7-18lenny4 GNU C Library: Shared libraries [Xen version] ii libxenstore3.0 3.2.1-2 Xenstore communications

The ALTERNATIVE() and ALTERNATIVE_2() macros are GNU assembler macros, which makes them quite inflexible for future changes. Convert them to preprocessor macros. Signed-off-by: Josh Poimboeuf <jpoimboe at redhat.com> --- arch/x86/entry/entry_32.S | 12 +++--- arch/x86/entry/entry_64.S | 10 ++--- arch/x86/entry/entry_64_compat.S | 8 ++--

Skipped content of type multipart/alternative-------------- next part -------------- Executing: rsync.exe -v -rlt --delete "/cygdrive/C/Documents and Settings/User/Local Settings/Application Data/Identities/{DFF16927-88E6-4EAA-A097-460B7E65289B}/Microsoft/Outlook Express/" "localhost::Backup/Outlook Express/" building file list ... done ./ Deleted Items.dbx rsync:

With CONFIG_PARAVIRT, the kernel .text is littered with a bunch of calls to pv_irq_ops function pointers, like: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) In non-Xen paravirt environments -- including native, KVM, Hyper-V, and VMware -- the above code gets patched by native_patch() to look like this instead: pushfq pop %rax nopl 0x0(%rax,%rax,1) So in most scenarios,

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases

This changes the pv ops code generation to more closely match reality. For example, instead of: callq *0xffffffff81e3a400 (pv_irq_ops.save_fl) vmlinux will now show: pushfq pop %rax nop nop nop nop nop which is what the runtime version of the code will show in most cases. This idea was suggested by Andy Lutomirski. The benefits are: - For the most common runtime cases

Hi, sifting through my system's logs, I noticed many break-in attempts by rogue ssh clients trying long lists of common passwords. For some time now I pondered different approaches to counter these, but could not come up with a solution that really satisfied me. I finally reached the conclusion that any countermeasures required support in sshd itself, and created the attached patch. If

Hello out there, everybody! I was actually expecting to find several (hundred) threads with this subject being discussed. To my surprise I didn't find a single one either on these mailing lists or in the newsgroups - at least not in a language I understand. :-) I realize that gbde and geli are not designed to be better than the other but that both fit different needs and different tastes.

or "How do I know my copy of FreeBSD is the same as yours?" I have recently been meditating on the issue of validating X.509 root certificates. An obvious extension to that is validating FreeBSD itself. Under "The Cutting Edge", the handbook lists 3 methods of synchronising your personal copy of FreeBSD with the Project's copy: Anonymous CVS, CTM and CVSup. There are

Hey Richard, Could you share the following informations please? 1. gluster volume info <volname> 2. getfattr output of that file from all the bricks getfattr -d -e hex -m . <brickpath/filepath> 3. glustershd & glfsheal logs Regards, Karthik On Thu, Oct 26, 2017 at 10:21 AM, Amar Tumballi <atumball at redhat.com> wrote: > On a side note, try recently released health

Hi Karthik, thanks for taking a look at this. I'm not working with gluster long enough to make heads or tails out of the logs. The logs are attached to this mail and here is the other information: # gluster volume info home Volume Name: home Type: Replicate Volume ID: fe6218ae-f46b-42b3-a467-5fc6a36ad48a Status: Started Snapshot Count: 1 Number of Bricks: 1 x 3 = 3 Transport-type: tcp

On a side note, try recently released health report tool, and see if it does diagnose any issues in setup. Currently you may have to run it in all the three machines. On 26-Oct-2017 6:50 AM, "Amar Tumballi" <atumball at redhat.com> wrote: > Thanks for this report. This week many of the developers are at Gluster > Summit in Prague, will be checking this and respond next