search for: backcompatible

On Tue, May 1, 2018 at 10:45 AM, Daniel P. Berrangé <berrange@redhat.com> wrote: > On Tue, Jan 30, 2018 at 01:17:21PM +0100, Gionatan Danti wrote: > > 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.

On Tue, Apr 23, 2019 at 07:38:41AM -0500, Eric Blake wrote: > [adding NBD list] > > On 4/23/19 2:36 AM, Richard W.M. Jones wrote: > > 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.

On Wed, Mar 01, 2017 at 07:28:46PM +0100, Viktor Mihajlovski wrote: > On 01.03.2017 16:58, Daniel P. Berrange wrote: > > given a basic Fedora 25 guest, with a virtio-mmio disk added as per the > > guide above... > > > > looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda': > > KERNEL=="vda" > >

On Wed, Mar 01, 2017 at 07:28:46PM +0100, Viktor Mihajlovski wrote: > On 01.03.2017 16:58, Daniel P. Berrange wrote: > > given a basic Fedora 25 guest, with a virtio-mmio disk added as per the > > guide above... > > > > looking at device '/devices/platform/a003e00.virtio_mmio/virtio3/block/vda': > > KERNEL=="vda" > >

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

On 01.03.2017 19:44, Daniel P. Berrange wrote: [...] replying on the list, a bit lengthy > > Ok, my guest has 4 disks > > - sda - virtio-scsi, over virtio-pci transport > - sdb - virtio-scsi, over virtio-mmio transport > - vda - virtio-scsi, over virtio-pci transport > - vdb - virtio-scsi, over virtio-mmio transport > > with systemd 231 I get these links >

On Tue, Jan 30, 2018 at 01:17:21PM +0100, Gionatan Danti wrote: > 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 at gdanti-lenovo vmimages]# virsh vol-create-as default zzz.qcow2 > 8589934592 --format=qcow2

...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 browser()...

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

On Wed, Jun 14, 2017 at 1:41 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > On Wed, Jun 14, 2017 at 12:47 PM, David Blaikie <dblaikie at gmail.com> > wrote: > >> >> >> 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

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

On Thu, Jun 15, 2017 at 1:14 AM, James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote: > I agree with Dave here. In the environment I work in, we regularly see > users ship objects and static archives to other users, and then never > update them, even though the linker moves on. If they did this with an > object file that had contents (such as the ODR information) that were

On Thu, Jun 15, 2017 at 10:44 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Jun 15, 2017 at 10:20 AM Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Thu, Jun 15, 2017 at 1:14 AM, James Henderson < >> jh7370.2008 at my.bristol.ac.uk> wrote: >> >>> I agree with Dave here. In the environment I work in, we

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