search for: backcompat

...lting file is > a > > qcow2 version 2 (compat=0.10) file. Example: > > > > [root@gdanti-lenovo vmimages]# virsh vol-create-as default zzz.qcow2 > > 8589934592 --format=qcow2 --backing-vol /mnt/vmimages/centos6.img > > Vol zzz.qcow2 created > > Yes, for sake of backcompat we default to v2 unless something > requires v3. You can't use vol-create-as to create a v3 image, > you need to use the XML input. > BTW: in virt-manager of CentOS 7.4 by default qcow2 disks (see below for zzz3.qcow2) are created with compatibility 1.1 (probably indirectly because o...

...OVERFLOW; conversely, > EOVERFLOW is only documented as being reasonable for the server to send > in response to a client using NBD_CMD_FLAG_DF to NBD_CMD_READ (again, > which implies the client negotiated structured replies), and not all > clients support structured replies. OTOH, for backcompat reasons it is reasonable to state that older versions of nbd-server could send pretty much anything over the wire[1], and that clients should therefore treat any nonzero value as an unknown error. I think that might also be a correct way to deal with error numbers in cases where the client does no...

...e-pci-0000:04:00.0 -> ../../vda platform-a003c00.virtio_mmio -> ../../vdb platform-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb virtio-pci-a003c00.virtio_mmio -> ../../vdb virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb So that appears to be working as designed - the 4 backcompat symlinks are still there, and the new symlinks all live under the platform- prefix and don't have a bogus 'pci' in the name for mmio links Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o-...

...e-pci-0000:04:00.0 -> ../../vda platform-a003c00.virtio_mmio -> ../../vdb platform-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb virtio-pci-a003c00.virtio_mmio -> ../../vdb virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb So that appears to be working as designed - the 4 backcompat symlinks are still there, and the new symlinks all live under the platform- prefix and don't have a bogus 'pci' in the name for mmio links Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o-...

Hi all, on a fully patched CentOS 7.4 x86-64, I see the following behavior: - when creating a new volumes using vol-create-as, the resulting file is a qcow2 version 2 (compat=0.10) file. Example: [root@gdanti-lenovo vmimages]# virsh vol-create-as default zzz.qcow2 8589934592 --format=qcow2 --backing-vol /mnt/vmimages/centos6.img Vol zzz.qcow2 created [root@gdanti-lenovo vmimages]# file

...irtio_mmio -> ../../vdb > platform-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb these look as expected > virtio-pci-a003c00.virtio_mmio -> ../../vdb > virtio-pci-a003e00.virtio_mmio-scsi-0:0:0:0 -> ../../sdb stale > > So that appears to be working as designed - the 4 backcompat symlinks are > still there, and the new symlinks all live under the platform- prefix > and don't have a bogus 'pci' in the name for mmio links the patch only provide compat symlinks for the pci path ids traditionally seen on x86 systems, but I think we don't want those for pla...

...lumes using vol-create-as, the resulting file is a > qcow2 version 2 (compat=0.10) file. Example: > > [root at gdanti-lenovo vmimages]# virsh vol-create-as default zzz.qcow2 > 8589934592 --format=qcow2 --backing-vol /mnt/vmimages/centos6.img > Vol zzz.qcow2 created Yes, for sake of backcompat we default to v2 unless something requires v3. You can't use vol-create-as to create a v3 image, you need to use the XML input. Either force the use of v3: <volume> <name>demo.qcow2</name> <capacity>1073741824</capacity> <target> <for...

...uing we'd want more >> than just TRUE or FALSE for debugging state, >> just so one could apply differing behaviour in the above cases. > Or the alternative: expand the use of the tracingState() flag to affect > RDEBUG as well. Indeed. If we additionally want to remain backcompatible, I think, we'd need to add new values in addition to {TRUE, FALSE} (and NULL for input). E.g., --- making up something to be improved --- using bit patterns which when added give an integer "tracing+debugging-state" 1 : tracing-turned-off 2 : debugging turned off, allowing brows...

gives an error in R. In both S+3 and S+5, it "works" by returning NULL or logical(0), respectively. As a consequence, all(x == y) returns TRUE in Splus, when x <- y <- NULL but gives an error in R. Do we have a good reason *not* to return logical(0) ? Martin Maechler <maechler@stat.math.ethz.ch> http://stat.ethz.ch/~maechler/ Seminar fuer Statistik, ETH-Zentrum LEO

On Mon, Apr 22, 2019 at 07:50:22PM -0500, Eric Blake wrote: > Previously, we were squashing EOVERFLOW into EINVAL; continue to do so > at points in the protocol where the client may not be expecting > EOVERFLOW. > > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > server/protocol.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) >

On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote: > On 01.03.2017 04:30, Zbigniew J?drzejewski-Szmek wrote: > > On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: > >>>>>> One could argue about back-level compatibility, but virtio by-path > >>>>>> naming has changed multiple times. We have seen

On Wed, Mar 01, 2017 at 04:02:53PM +0100, Viktor Mihajlovski wrote: > On 01.03.2017 04:30, Zbigniew J?drzejewski-Szmek wrote: > > On Tue, Feb 28, 2017 at 09:47:42AM +0100, Viktor Mihajlovski wrote: > >>>>>> One could argue about back-level compatibility, but virtio by-path > >>>>>> naming has changed multiple times. We have seen

On 2/22/23 19:20, Andrey Drobyshev wrote: > Since commits b28cd1dc ("Remove requested_guestcaps / rcaps"), f0afc439 > ("Remove guestcaps_block_type Virtio_SCSI") support for installing > virtio-scsi driver is missing in virt-v2v. AFAIU plans and demands for > bringing this feature back have been out there for a while. E.g. I've > found a corresponding issue

...s a format input to the linker that produces warnings, potentially errors (Werror) for users that they might want to maintain compatibility for. Seems like a higher bar. Feels to me like a bit more time could be spent on a design/size impact/etc to give a better chance of ongoing stability (and/or backcompat at least) for users. But just a thought. - Dave > > Because the requirements for ODR tables are simpler than those for > .gdb_index, I'd expect us to converge on a final format sooner, so in > practice the window of compatibility would end up being longer than a year. > > P...

I agree with Kasper, this is a 'big' issue. Does your method of taking only n PCs reduce the load on memory? The new addition to the summary looks like a good idea, but Proportion of Variance as you describe it may be confusing to new users. Am I correct in saying Proportion of variance describes the amount of variance with respect to the number of components the user chooses to show? So

...warnings, potentially errors >> (Werror) for users that they might want to maintain compatibility for. >> Seems like a higher bar. >> >> Feels to me like a bit more time could be spent on a design/size >> impact/etc to give a better chance of ongoing stability (and/or backcompat >> at least) for users. But just a thought. >> >> - Dave >> >> >>> >>> Because the requirements for ODR tables are simpler than those for >>> .gdb_index, I'd expect us to converge on a final format sooner, so in >>> practice the...

...errors (Werror) for users that they might want to maintain >>>> compatibility for. Seems like a higher bar. >>>> >>>> Feels to me like a bit more time could be spent on a design/size >>>> impact/etc to give a better chance of ongoing stability (and/or backcompat >>>> at least) for users. But just a thought. >>>> >>>> - Dave >>>> >>>> >>>>> >>>>> Because the requirements for ODR tables are simpler than those for >>>>> .gdb_index, I'd expect us to con...

On Tue, Jun 13, 2017, 11:30 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Jun 13, 2017 at 11:06 PM, David Blaikie <dblaikie at gmail.com> > wrote: > >> >> >> On Tue, Jun 13, 2017 at 10:05 PM Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> On Tue, Jun 13, 2017 at 8:48 PM, David Blaikie <dblaikie at