I noticed that raw is intentionally used as image format for appliance image. So I would like to ask, is there any reason to use raw as image format for appliance? I would suggest that choice is related with the performance, so I did several test runs (./run utils/boot-benchmark/boot-benchmark) /appliance/root.raw: Result: 1342.9ms ±2.9ms Result: 1370.1ms ±17.3ms Result: 1365.1ms ±11.0ms appliance/root.qcow2: Result: 1353.1ms ±2.4ms Result: 1350.2ms ±5.3ms Result: 1374.7ms ±5.4ms But even theoretically there should not be much difference, because qcow2 uses a cache to internal tables. Also -drive configured to use the host cache: if (has_appliance_drive) { ADD_CMDLINE ("-drive"); ADD_CMDLINE_PRINTF ("file=%s,snapshot=on,id=appliance," "cache=unsafe,if=none,format=raw",
On Tue, Jun 20, 2017 at 05:04:53PM +0300, Pavel Butsykin wrote:
I noticed that raw is intentionally used as image format for appliance image. So I would like to ask, is there any reason to use raw as image format for appliance?
The simple answer is because we create the appliance image (it's an ext2/3/4 filesystem) using e2fsprogs, and that library wouldn't know how to create anything else since it always assumes it's writing directly to a device. https://github.com/libguestfs/supermin/blob/master/src/format_ext2.mli#L22-L... HTH, Rich.
I would suggest that choice is related with the performance, so I did several test runs (./run utils/boot-benchmark/boot-benchmark)
/appliance/root.raw: Result: 1342.9ms ±2.9ms Result: 1370.1ms ±17.3ms Result: 1365.1ms ±11.0ms
appliance/root.qcow2: Result: 1353.1ms ±2.4ms Result: 1350.2ms ±5.3ms Result: 1374.7ms ±5.4ms
But even theoretically there should not be much difference, because qcow2 uses a cache to internal tables. Also -drive configured to use the host cache: if (has_appliance_drive) { ADD_CMDLINE ("-drive"); ADD_CMDLINE_PRINTF ("file=%s,snapshot=on,id=appliance," "cache=unsafe,if=none,format=raw",
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
On 20.06.2017 17:47, Richard W.M. Jones wrote:
On Tue, Jun 20, 2017 at 05:04:53PM +0300, Pavel Butsykin wrote:
I noticed that raw is intentionally used as image format for appliance image. So I would like to ask, is there any reason to use raw as image format for appliance?
The simple answer is because we create the appliance image (it's an ext2/3/4 filesystem) using e2fsprogs, and that library wouldn't know how to create anything else since it always assumes it's writing directly to a device.
https://github.com/libguestfs/supermin/blob/master/src/format_ext2.mli#L22-L...
HTH,
Yes, the main point is clear, thanks. I asked because we supply the prepared appliance, so would like to use qcow2. Given that the applaince image is completely controlled, for supermin and fixed appliance, in both the cases. We could use autodetect, it is already implemented in qemu, so to add it to libguestfs will simply. I'm going to prepare the patches, what do you think?
Rich.
On Tue, Jun 20, 2017 at 06:34:28PM +0300, Pavel Butsykin wrote:
On 20.06.2017 17:47, Richard W.M. Jones wrote:
On Tue, Jun 20, 2017 at 05:04:53PM +0300, Pavel Butsykin wrote:
I noticed that raw is intentionally used as image format for appliance image. So I would like to ask, is there any reason to use raw as image format for appliance?
The simple answer is because we create the appliance image (it's an ext2/3/4 filesystem) using e2fsprogs, and that library wouldn't know how to create anything else since it always assumes it's writing directly to a device.
https://github.com/libguestfs/supermin/blob/master/src/format_ext2.mli#L22-L...
HTH,
Yes, the main point is clear, thanks.
I asked because we supply the prepared appliance, so would like to use qcow2. Given that the applaince image is completely controlled, for supermin and fixed appliance, in both the cases. We could use autodetect, it is already implemented in qemu, so to add it to libguestfs will simply. I'm going to prepare the patches, what do you think?
./configure-time option? Autodetection is actually not insecure with modern qemu, but people still think it is ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
On 20.06.2017 18:41, Richard W.M. Jones wrote:
On Tue, Jun 20, 2017 at 06:34:28PM +0300, Pavel Butsykin wrote:
On 20.06.2017 17:47, Richard W.M. Jones wrote:
On Tue, Jun 20, 2017 at 05:04:53PM +0300, Pavel Butsykin wrote:
I noticed that raw is intentionally used as image format for appliance image. So I would like to ask, is there any reason to use raw as image format for appliance?
The simple answer is because we create the appliance image (it's an ext2/3/4 filesystem) using e2fsprogs, and that library wouldn't know how to create anything else since it always assumes it's writing directly to a device.
https://github.com/libguestfs/supermin/blob/master/src/format_ext2.mli#L22-L...
HTH,
Yes, the main point is clear, thanks.
I asked because we supply the prepared appliance, so would like to use qcow2. Given that the applaince image is completely controlled, for supermin and fixed appliance, in both the cases. We could use autodetect, it is already implemented in qemu, so to add it to libguestfs will simply. I'm going to prepare the patches, what do you think?
./configure-time option? > Autodetection is actually not insecure with modern qemu, but people still think it is ...
Yes, but in our case it will be safe, because we have full control over appliance image.
Rich.
On Tue, Jun 20, 2017 at 06:48:16PM +0300, Pavel Butsykin wrote:
On 20.06.2017 18:41, Richard W.M. Jones wrote:
On Tue, Jun 20, 2017 at 06:34:28PM +0300, Pavel Butsykin wrote:
On 20.06.2017 17:47, Richard W.M. Jones wrote:
On Tue, Jun 20, 2017 at 05:04:53PM +0300, Pavel Butsykin wrote:
I noticed that raw is intentionally used as image format for appliance image. So I would like to ask, is there any reason to use raw as image format for appliance?
The simple answer is because we create the appliance image (it's an ext2/3/4 filesystem) using e2fsprogs, and that library wouldn't know how to create anything else since it always assumes it's writing directly to a device.
https://github.com/libguestfs/supermin/blob/master/src/format_ext2.mli#L22-L...
HTH,
Yes, the main point is clear, thanks.
I asked because we supply the prepared appliance, so would like to use qcow2. Given that the applaince image is completely controlled, for supermin and fixed appliance, in both the cases. We could use autodetect, it is already implemented in qemu, so to add it to libguestfs will simply. I'm going to prepare the patches, what do you think?
./configure-time option? > Autodetection is actually not insecure with modern qemu, but people still think it is ...
Yes, but in our case it will be safe, because we have full control over appliance image.
As long as a configure time option will work for you, I'd prefer to do that. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/
On 20.06.2017 19:06, Richard W.M. Jones wrote:
On Tue, Jun 20, 2017 at 06:48:16PM +0300, Pavel Butsykin wrote:
On 20.06.2017 18:41, Richard W.M. Jones wrote:
On Tue, Jun 20, 2017 at 06:34:28PM +0300, Pavel Butsykin wrote:
On 20.06.2017 17:47, Richard W.M. Jones wrote:
On Tue, Jun 20, 2017 at 05:04:53PM +0300, Pavel Butsykin wrote:
I noticed that raw is intentionally used as image format for appliance image. So I would like to ask, is there any reason to use raw as image format for appliance?
The simple answer is because we create the appliance image (it's an ext2/3/4 filesystem) using e2fsprogs, and that library wouldn't know how to create anything else since it always assumes it's writing directly to a device.
https://github.com/libguestfs/supermin/blob/master/src/format_ext2.mli#L22-L...
HTH,
Yes, the main point is clear, thanks.
I asked because we supply the prepared appliance, so would like to use qcow2. Given that the applaince image is completely controlled, for supermin and fixed appliance, in both the cases. We could use autodetect, it is already implemented in qemu, so to add it to libguestfs will simply. I'm going to prepare the patches, what do you think?
./configure-time option? > Autodetection is actually not insecure with modern qemu, but people still think it is ...
Yes, but in our case it will be safe, because we have full control over appliance image.
As long as a configure time option will work for you, I'd prefer to do that.
Yes, the configure time option to enable autodetection of appliance image format will be fine, thanks!
Rich.
On Tuesday, 20 June 2017 16:04:53 CEST Pavel Butsykin wrote:
I noticed that raw is intentionally used as image format for appliance image. So I would like to ask, is there any reason to use raw as image format for appliance?
In addition to what Rich already said, there are a couple of points: a) a raw image is generally always faster, since it is a direct bit-by-bit representation of the disk b) because (a), raw is generally more universally understood; the UML backend (not much tested these days) supports only raw disks (which include the appliance), since that's what the kernel can handle -- Pino Toscano
participants (3)
-
Pavel Butsykin -
Pino Toscano -
Richard W.M. Jones