search for: bzs

...r, we would still like to know what the issue is and get a 'real' >> fix - I guess we could try creating a bug report with Redhat ... > > By bug report you mean BZ or a support request as paying RHEL customer? A BZ ... > Unfortunately I'm not too happy anymore with how BZs are handled these > days. Am I alone with this feeling? I've had mixed results with BZs - it appears if a bug 'tickles the fancy' of someone a Redhat that sees the ticket, then you can get good results - otherwise, they just sit there until the release goes out of support and the...

...ll gluster not to listen on an interface, and I > can't not have a public IP on the server. I really wish ther was a > simple "listen only on this IP/interface" option for this > > > What about this? > > transport.socket.bind-address > > I know the were some BZs on it with earlier Gluster Versions, so I assume its still there now. > > -bill > > > > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-users > --------...

...> I took a look at the libvirt code ([3] & [4]), and, from my limited >> understanding, I got the impression that plugging existing interfaces >> via `managed='no' ` is only possible for macvtap interfaces. No, it works for standard tap devices as well. The reason the BZs and commit logs talk mostly about macvtap rather than tap is because 1) that's what kubevirt people had asked for and 2) it already *mostly* worked for tap devices, so most of the work was related to macvtap (my memory is already fuzzy, but I think there were a couple privileged operations...

...le "/usr/lib64/python2.7/site-packages/libvirt.py", line 733, in blockJobAbort if ret == -1: raise libvirtError ('virDomainBlockJobAbort() failed', dom=self) libvirtError: block copy still active: disk 'vdb' not ready for pivot yet That exception observed in following BZs: https://bugzilla.redhat.com/1376580 https://bugzilla.redhat.com/1397122 I am trying to understand what this exception indicates in order to handle it appropriately when thrown by libvirt. Thanks, Ala

...sy way > that I know of to tell gluster not to listen on an interface, and I > can't not have a public IP on the server. I really wish ther was a > simple "listen only on this IP/interface" option for this What about this? transport.socket.bind-address I know the were some BZs on it with earlier Gluster Versions, so I assume its still there now. -bill -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170806/6f8fd0ed/attachment.html>

Simon Matter via CentOS wrote: > >> We are seeing a problem that occurs ~5% of the time when rebooting > > I see such issues on a quite large multi user system but when this > happens, after forced restarts for kernel updates, I usually don't have > the time to analyze and play doctor on it. My "solution" now is to simply > reboot the server again in such a

...I > > can't not have a public IP on the server. I really wish ther was a > > simple "listen only on this IP/interface" option for this > > > > > > What about this? > > > > transport.socket.bind-address > > > > I know the were some BZs on it with earlier Gluster Versions, so I assume its still there now. > > > > -bill > > > > > > > > > > _______________________________________________ > > Gluster-users mailing list > > Gluster-users at gluster.org > > http://lists.gluste...

> You should add VLANS, and/or overlay networks and/or Mac Address > filtering/locking/security which raises the bar quite a bit for hackers. > Perhaps your provider can help you with that. > Gluster already uses a vlan, the problem is that there is no easy way that I know of to tell gluster not to listen on an interface, and I can't not have a public IP on the server. I really

...eate some pool XML (taking the example I have) >> >> % cat nfs.xml >> <pool type='netfs'> >> <name>rootsquash</name> >> <source> >> <host name='localhost'/> >> <dir path='/home/bzs/rootsquash/nfs'/> >> <format type='nfs'/> >> </source> >> <target> >> <path>/tmp/netfs-rootsquash-pool</path> >> <permissions> >> <mode>0755</mode> &g...

...de ([3] & [4]), and, from my limited > >> understanding, I got the impression that plugging existing interfaces > >> via `managed='no' ` is only possible for macvtap interfaces. > > > No, it works for standard tap devices as well. > > > The reason the BZs and commit logs talk mostly about macvtap rather than > tap is because 1) that's what kubevirt people had asked for and 2) it > already *mostly* worked for tap devices, so most of the work was related > to macvtap (my memory is already fuzzy, but I think there were a couple > privil...

...> > >> understanding, I got the impression that plugging existing interfaces > > >> via `managed='no' ` is only possible for macvtap interfaces. > > > > > > No, it works for standard tap devices as well. > > > > > > The reason the BZs and commit logs talk mostly about macvtap rather than > > tap is because 1) that's what kubevirt people had asked for and 2) it > > already *mostly* worked for tap devices, so most of the work was related > > to macvtap (my memory is already fuzzy, but I think there were a cou...

On Tue, Feb 27, 2018 at 09:53:00 +0100, Michal Privoznik wrote: > On 02/27/2018 03:06 AM, Star Guo wrote: > > Hello Everyone, > > > > > > > > My pc run in CentOS 7.4 and install libvirt-4.0.0 + Qemu-kvm 2.9.0 + Ceph > > 10.2.10 ALL-in-One. > > > > > > > > I use python-sdk with libvirt and run [self.domain.updateDeviceFlags(xml,

...existing interfaces > > > > >> via `managed='no' ` is only possible for macvtap interfaces. > > > > > > > > > > > > No, it works for standard tap devices as well. > > > > > > > > > > > > The reason the BZs and commit logs talk mostly about macvtap rather than > > > > tap is because 1) that's what kubevirt people had asked for and 2) it > > > > already *mostly* worked for tap devices, so most of the work was related > > > > to macvtap (my memory is already fuzzy...

...y aren't freed they can't be allocated after > * kexec. There is no need to cleanup the mlx5_core software > * contexts. > > but most drivers don't have a shutdown callback how do they work then? > do you know which platforms these are? There used to be bzs that requires virtio drivers to add a shutdown to fix kexec: https://bugzilla.redhat.com/show_bug.cgi?id=2108406 Thanks > > I don't really know much about why shutdown callback is even necessary. > I guess this is to detect shutdown and do a faster cleanup than > the slow, gracef...

...5_core software > > ???????? * contexts. > > > > but most drivers don't have a shutdown callback how do they work then? > > do you know which platforms these are? > I don't. x86_64 is not one of them though. I will do some more digging ... > There used to be bzs that requires virtio drivers to add a shutdown to > fix kexec: > > https://bugzilla.redhat.com/show_bug.cgi?id=2108406 > I don't have access to this. What is it about? Thanks, Dragos > Thanks > > > > > I don't really know much about why shutdown callback i...

...squash via an NFS pool is "easy" (famous last words) Create some pool XML (taking the example I have) % cat nfs.xml <pool type='netfs'> <name>rootsquash</name> <source> <host name='localhost'/> <dir path='/home/bzs/rootsquash/nfs'/> <format type='nfs'/> </source> <target> <path>/tmp/netfs-rootsquash-pool</path> <permissions> <mode>0755</mode> <owner>107</owner> <gro...

...ge, in few cases, we see the following exception: [...] > libvirtError: block copy still active: disk 'vdb' not ready for pivot yet You can see if the block operation is still in progress or not by doing: `sudo virsh blockjob vm1 vdb --info`. > That exception observed in following BZs: > > https://bugzilla.redhat.com/1376580 > https://bugzilla.redhat.com/1397122 [I see, that the above are oVirt bugs.] > I am trying to understand what this exception indicates in order to handle > it appropriately when thrown by libvirt. Here's the commit that adds the above...

CentoOS 7 python-cryptography package is at version 0.8.2 It has a build-requires for python-cryptography-vectors of the same version (but different source tarball apparently) There is no python-cryptography-vectors in CentOS 7 base or updates. There is one in EPEL but it is version 0.8 -=- If you relax the BuildRequires to just require python-cryptography-vectors then the build fails

...to be a way via the (newer, but not supported in libvirt) blockdev-change-medium qmp command to tell it what the secret object id is. > There should be a upstream bugzilla tracking this and I'm planing to fix > this during my work on using the new blockdev stuff in qemu. > And yes, bzs would be good to track all this. John

On 9/20/19 8:58 AM, Eric Blake wrote: > On 9/12/19 12:41 PM, Richard W.M. Jones wrote: >> We have discovered a potential Denial of Service / Amplification Attack >> in nbdkit. > > Unfortunately, our fix for this issue cause another potential Denial of > Service attack: > >> >> Lifecycle >> --------- >> >> Reported: 2019-09-11 Fixed: