search for: backingfiles

In the guestfs_disk_create API we have traditionally allowed you to set backingfile without setting backingformat. The meaning of this is to let qemu autodetect the backing format when opening the overlay disk. However libvirt >= 6.0 refuses to even pass such disks to qemu (see https://bugzilla.redhat.com/show_bug.cgi?id=1798148). For this reason, move the autodetection earlier and make it

On Mon, Mar 09, 2020 at 11:07:20AM +0100, Pino Toscano wrote: > On Thursday, 6 February 2020 18:20:19 CET Richard W.M. Jones wrote: > > In the guestfs_disk_create API we have traditionally allowed you to > > set backingfile without setting backingformat. The meaning of this is > > to let qemu autodetect the backing format when opening the overlay > > disk. > >

On Mon, Mar 09, 2020 at 12:07:08PM +0100, Pino Toscano wrote: > On Monday, 9 March 2020 11:40:46 CET Richard W.M. Jones wrote: > > On Mon, Mar 09, 2020 at 11:07:20AM +0100, Pino Toscano wrote: > > > On Thursday, 6 February 2020 18:20:19 CET Richard W.M. Jones wrote: > > > > In the guestfs_disk_create API we have traditionally allowed you to > > > > set

On Thursday, 6 February 2020 18:20:19 CET Richard W.M. Jones wrote: > In the guestfs_disk_create API we have traditionally allowed you to > set backingfile without setting backingformat. The meaning of this is > to let qemu autodetect the backing format when opening the overlay > disk. > > However libvirt >= 6.0 refuses to even pass such disks to qemu (see >

A lot of code runs 'qemu-img create' or 'truncate' to create blank disk images. In the past I resisted adding an API to do this, since it essentially duplicates what you can already do using other tools (ie. qemu-img). However this does simplify calling code quite a lot since qemu-img is somewhat error-prone to use (eg: don't try to create a disk called "foo:bar")

On Monday, 9 March 2020 11:40:46 CET Richard W.M. Jones wrote: > On Mon, Mar 09, 2020 at 11:07:20AM +0100, Pino Toscano wrote: > > On Thursday, 6 February 2020 18:20:19 CET Richard W.M. Jones wrote: > > > In the guestfs_disk_create API we have traditionally allowed you to > > > set backingfile without setting backingformat. The meaning of this is > > > to let

Hi,guys, During a HVM''s running which take a qcow format image file as its own virtual disk, the qcow image file will be always read.In the situation that its qcow format image is based on a raw format image, if nesethe backingfile ,just that raw format image file,would be read .my purpose is to cache the data that is read from the backingfile when the hvm is running . Now what I concern

On Mon, Mar 09, 2020 at 11:19:39AM +0000, Richard W.M. Jones wrote: > On Mon, Mar 09, 2020 at 12:07:08PM +0100, Pino Toscano wrote: > > On Monday, 9 March 2020 11:40:46 CET Richard W.M. Jones wrote: > > > On Mon, Mar 09, 2020 at 11:07:20AM +0100, Pino Toscano wrote: > > > > On Thursday, 6 February 2020 18:20:19 CET Richard W.M. Jones wrote: > > > > > In

Support for RHEV with RHEL 6 nodes required us to output the old style qcow2 compat=0.10 images. Since RHEV 3.6 GA, RHEL 6 has not been supported as a RHEV node type. There are significant downsides to using qcow2 compat=0.10 instead of the modern default (compat=1.1), so stop forcing compat=0.10 for these targets. Thanks: Yaniv Kaul, Michal Skrivanek. --- v2v/output_rhev.ml | 4 ----

Libvirt >= 2.1.0 now allows you to open files which have a "json:" QEMU pseudo-URL as backingfile, whereas previously it would fail hard in this case (RHBZ#1134878). When virt-v2v performs conversions from Xen (over SSH) or vCenter (over HTTPS) it uses these pseudo-URLs as backingfiles. We had to tell people to use LIBGUESTFS_BACKEND=direct to avoid libvirt in this situation. This commit narrows the check so it will now only print the error if libvirt < 2.1.0 and LIBGUESTFS_BACKEND=direct is not set. Also the error is modified to tell users they can either upgrade libvirt o...

libselinux defaults to "targeted" when no SELINUXTYPE is specified in /etc/config/selinux. Hence do the same here, instead of failing because of the missing key. Add a slow test for checking SELinux relabeling on a Fedora 27 guest, both with no changes, and with a modified configuration. --- customize/Makefile.am | 2 ++ customize/SELinux_relabel.ml | 14 ++++++++++--

Hi everyone! I use the libvirt(version: 1.2.2) and QEMU(version: 2.2.1) to test qemu snapshot features: I tried virsh blockcommit when VM offline, the virsh blockcommit failed: the error messase as below: error: Requested operation is not valid: domain is not running when I start the VM, the virsh blockcommit work fine! my question is：we need

I have scoured the web and can't find anything on the topic: Is IPv6 supported for remote image targets? For example: guestfish --format=raw --ro -a rbd://[fd00::cefc:1]:6789/images/CentOS-7-x86_64-GenericCloud-1901 Does not work citing the following: libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: create: flags = 0, handle = 0x5560231bdfb0, program =

On Fri, Jun 23, 2017 at 04:12:35PM +0300, Pavel Butsykin wrote: > This feature allows you to use different image formats for the fixed > appliance. The raw format is used by default. > > Signed-off-by: Pavel Butsykin <pbutsykin@virtuozzo.com> > --- > lib/create.c | 5 +++-- > lib/guestfs-internal.h | 2 ++ > lib/launch-direct.c | 2 ++ >

This will hint what to do when any argument of a command starts with a dash. --- fish/guestfish.pod | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fish/guestfish.pod b/fish/guestfish.pod index ad98e975e..bbf43aad5 100644 --- a/fish/guestfish.pod +++ b/fish/guestfish.pod @@ -458,6 +458,13 @@ command that gives an error causes the whole shell to exit. In interactive mode (with a

Hi everyone! I use the libvirt(version: 1.2.2) and QEMU(version: 2.2.1) to test qemu snapshot features: I tried virsh blockcommit when VM offline, the virsh blockcommit failed: the error messase as below: error: Requested operation is not valid: domain is not running when I start the VM, the virsh blockcommit work fine! my question is : we

Hi everyone! I use the libvirt(version: 1.2.2) and QEMU(version: 2.2.1) to test qemu snapshot features: I tried virsh blockcommit when VM offline, the virsh blockcommit failed: the error messase as below: * error: Requested operation is not valid: domain is not running* when I start the VM, the virsh blockcommit work fine! my question is : we

Hi everyone! I use the libvirt(version: 1.2.2) and QEMU(version: 2.2.1) to test qemu snapshot features: I tried virsh blockcommit when VM offline, the virsh blockcommit failed: the error messase as below: * error: Requested operation is not valid: domain is not running* when I start the VM, the virsh blockcommit work fine! my question is : we

On Tue, Oct 13, 2015 at 10:39:58AM +0800, justlibvirt@gmail.com wrote: > Hi everyone! Hi, Firstly, please don't post the same message multiple times in a row. If someone hasn't responded, they're either busy, or haven't noticed this message. > I use the libvirt(version: 1.2.2) and QEMU(version: 2.2.1) to > test qemu snapshot features: > > I

Hi, all, I have a really big matrix that I want to run k-means on. I tried: >data <- read.big.memory('mydata.csv',type='double',backingfile='mydata.bin',descriptorfile='mydata.desc') I'm using doMC to register multicore. >library(doMC) >registerDoMC(cores=8) >ans<-bigkmeans(data,k) In system monitor, it seems only one thread running R. Is