9:05 a.m.
VDSM sync meeting Monday June 17th 2013
=======================================
- Dan requests reviews for pending patches from Mei Liu and himself (
http://gerrit.ovirt.org/#/c/15356/8 ) for mom.
- Toni to fix the problem with Mark's patch that Dan reviewed so that it can
be merged together with the smaller following patches.
- Federico has three high priority patches for features and two lower priority
ones that need reviews in order to make it for the release deadline. They are
related to disk extension and image upload/download (glance):
+ http://gerrit.ovirt.org/#/c/15442 - constants: unify the BLANK_UUID def...
+ http://gerrit.ovirt.org/#/c/14589 - volume: add the BLOCK_SIZE constant +1
+ http://gerrit.ovirt.org/#/c/14590 - volume: add the extendVolumeSize method
+ http://gerrit.ovirt.org/#/c/15614 - vm: add the live diskSizeExtend method +1
+ http://gerrit.ovirt.org/#/c/14955 - image: add support to upload/download images
- Adam and others to review Gluster patches:
+ http://gerrit.ovirt.org/#/c/13785/
+ http://gerrit.ovirt.org/#/c/11094/
- Is there a filing for Qemu image handling reported by virt team?
- Reminder to follow wiki feature page process closely to maximize changes to
have features added to a release.
- Multiple gateways are being worked on to fix dhcp races and comments by
reviewers.
- NetReloaded after multiple gateways. Try to get up to iproute2 configurator.
- Cross-distro support:
+ Netreloaded with iproute2 plus persistence would help.
+ init scripts separation (proposed by Yaniv to make ready for 3.3).
- Cloud-init integration by Greg Padgett. There is a vdsm patch that should be
taken care of in terms of reviewing http://gerrit.ovirt.org/#/c/14347/
1:29 a.m.
----- Original Message -----
VDSM sync meeting Monday June 17th 2013
=======================================
- Dan requests reviews for pending patches from Mei Liu and himself (
http://gerrit.ovirt.org/#/c/15356/8 ) for mom.
- Toni to fix the problem with Mark's patch that Dan reviewed so that it can
be merged together with the smaller following patches.
- Federico has three high priority patches for features and two lower
priority
ones that need reviews in order to make it for the release deadline. They
are
related to disk extension and image upload/download (glance):
+ http://gerrit.ovirt.org/#/c/15442 - constants: unify the BLANK_UUID
def...
+ http://gerrit.ovirt.org/#/c/14589 - volume: add the BLOCK_SIZE constant
+1
+ http://gerrit.ovirt.org/#/c/14590 - volume: add the extendVolumeSize
method
+ http://gerrit.ovirt.org/#/c/15614 - vm: add the live diskSizeExtend
method +1
+ http://gerrit.ovirt.org/#/c/14955 - image: add support to upload/download
images
- Adam and others to review Gluster patches:
+ http://gerrit.ovirt.org/#/c/13785/
+ http://gerrit.ovirt.org/#/c/11094/
- Is there a filing for Qemu image handling reported by virt team?
Background about the problem:
As part of the ram snapshots feature (http://wiki.ovirt.org/Features/RAM_Snapshots)
we pass a path to file to libvirt, where the memory of the VM should be saved as
part of the snapshot creation.
the output file is identical to the one that is created to store the memory on
hibernate command.
When VM with snapshot(s) that has memory is being exported, we want the snapshot's
memory file to be exported to the export domain as well. when trying to export such
memory file, we saw that the file is being truncated to the closest size that is
a multiple of block size (512). we found that the file is being truncated by
qemu-img that is being used to copy the file to the export domain.
We previously thought that it is a problem in qemu - not handling files with size
that is not a multiple of block size, and a bug to qemu was opened (bz 970559).
We now understand that the issue described above might be a problem in qemu that
needs to be solved, but it is not the problem in our case:
treating the memory file as qemu image is wrong - the created file is not a qemu
image. the file has a special format: it contains xml part at the beginning and
the memory dump as a binary data right after that.
So basically it seems that we need the following things in vdsm:
1. The creation of the file that is expected to store the memory as qemu image
seems to be redundant. instead, we need to have a way to create a file in a
similar way to 'touch' command - just to verify that the file in the path we
pass to libvirt is created with the right permissions. (it's probably true for
the hibernation volume creation as well btw).
2. The more important issue is that we need to have a way to export files which
are not qemu images to the export domain, which means without using the qemu-img
process, just copy the file.
- Reminder to follow wiki feature page process closely to maximize changes to
have features added to a release.
- Multiple gateways are being worked on to fix dhcp races and comments by
reviewers.
- NetReloaded after multiple gateways. Try to get up to iproute2
configurator.
- Cross-distro support:
+ Netreloaded with iproute2 plus persistence would help.
+ init scripts separation (proposed by Yaniv to make ready for 3.3).
- Cloud-init integration by Greg Padgett. There is a vdsm patch that should
be
taken care of in terms of reviewing http://gerrit.ovirt.org/#/c/14347/
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
6:27 a.m.
On 06/18/2013 09:29 AM, Arik Hadas wrote:
----- Original Message -----
> VDSM sync meeting Monday June 17th 2013
> =======================================
>
> - Dan requests reviews for pending patches from Mei Liu and himself (
> http://gerrit.ovirt.org/#/c/15356/8 ) for mom.
>
> - Toni to fix the problem with Mark's patch that Dan reviewed so that it can
> be merged together with the smaller following patches.
>
> - Federico has three high priority patches for features and two lower
> priority
> ones that need reviews in order to make it for the release deadline. They
> are
> related to disk extension and image upload/download (glance):
> + http://gerrit.ovirt.org/#/c/15442 - constants: unify the BLANK_UUID
> def...
> + http://gerrit.ovirt.org/#/c/14589 - volume: add the BLOCK_SIZE constant
> +1
> + http://gerrit.ovirt.org/#/c/14590 - volume: add the extendVolumeSize
> method
> + http://gerrit.ovirt.org/#/c/15614 - vm: add the live diskSizeExtend
> method +1
> + http://gerrit.ovirt.org/#/c/14955 - image: add support to upload/download
> images
>
> - Adam and others to review Gluster patches:
> + http://gerrit.ovirt.org/#/c/13785/
> + http://gerrit.ovirt.org/#/c/11094/
>
> - Is there a filing for Qemu image handling reported by virt team?
Background about the problem:
As part of the ram snapshots feature (http://wiki.ovirt.org/Features/RAM_Snapshots)
we pass a path to file to libvirt, where the memory of the VM should be saved as
part of the snapshot creation.
the output file is identical to the one that is created to store the memory on
hibernate command.
When VM with snapshot(s) that has memory is being exported, we want the snapshot's
memory file to be exported to the export domain as well. when trying to export such
memory file, we saw that the file is being truncated to the closest size that is
a multiple of block size (512). we found that the file is being truncated by
qemu-img that is being used to copy the file to the export domain.
We previously thought that it is a problem in qemu - not handling files with size
that is not a multiple of block size, and a bug to qemu was opened (bz 970559).
We now understand that the issue described above might be a problem in qemu that
needs to be solved, but it is not the problem in our case:
treating the memory file as qemu image is wrong - the created file is not a qemu
image. the file has a special format: it contains xml part at the beginning and
the memory dump as a binary data right after that.
So basically it seems that we need the following things in vdsm:
1. The creation of the file that is expected to store the memory as qemu image
seems to be redundant. instead, we need to have a way to create a file in a
similar way to 'touch' command - just to verify that the file in the path we
pass to libvirt is created with the right permissions. (it's probably true for
the hibernation volume creation as well btw).
how would this look for block devices?
2. The more important issue is that we need to have a way to export files which
are not qemu images to the export domain, which means without using the qemu-img
process, just copy the file.
ayal - anything close to this today - i remember various qemu-img vs. dd
patches in the past for copy operations?
>
> - Reminder to follow wiki feature page process closely to maximize changes to
> have features added to a release.
>
> - Multiple gateways are being worked on to fix dhcp races and comments by
> reviewers.
>
> - NetReloaded after multiple gateways. Try to get up to iproute2
> configurator.
>
> - Cross-distro support:
> + Netreloaded with iproute2 plus persistence would help.
> + init scripts separation (proposed by Yaniv to make ready for 3.3).
>
> - Cloud-init integration by Greg Padgett. There is a vdsm patch that should
> be
> taken care of in terms of reviewing http://gerrit.ovirt.org/#/c/14347/
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
3:56 a.m.
----- Original Message -----
On 06/18/2013 09:29 AM, Arik Hadas wrote:
>
> ----- Original Message -----
>> VDSM sync meeting Monday June 17th 2013
>> =======================================
>>
>> - Dan requests reviews for pending patches from Mei Liu and himself (
>> http://gerrit.ovirt.org/#/c/15356/8 ) for mom.
>>
>> - Toni to fix the problem with Mark's patch that Dan reviewed so that it
>> can
>> be merged together with the smaller following patches.
>>
>> - Federico has three high priority patches for features and two lower
>> priority
>> ones that need reviews in order to make it for the release deadline.
>> They
>> are
>> related to disk extension and image upload/download (glance):
>> + http://gerrit.ovirt.org/#/c/15442 - constants: unify the BLANK_UUID
>> def...
>> + http://gerrit.ovirt.org/#/c/14589 - volume: add the BLOCK_SIZE
>> constant
>> +1
>> + http://gerrit.ovirt.org/#/c/14590 - volume: add the extendVolumeSize
>> method
>> + http://gerrit.ovirt.org/#/c/15614 - vm: add the live diskSizeExtend
>> method +1
>> + http://gerrit.ovirt.org/#/c/14955 - image: add support to
>> upload/download
>> images
>>
>> - Adam and others to review Gluster patches:
>> + http://gerrit.ovirt.org/#/c/13785/
>> + http://gerrit.ovirt.org/#/c/11094/
>>
>> - Is there a filing for Qemu image handling reported by virt team?
>
> Background about the problem:
>
> As part of the ram snapshots feature
> (http://wiki.ovirt.org/Features/RAM_Snapshots)
> we pass a path to file to libvirt, where the memory of the VM should be
> saved as
> part of the snapshot creation.
> the output file is identical to the one that is created to store the memory
> on
> hibernate command.
>
> When VM with snapshot(s) that has memory is being exported, we want the
> snapshot's
> memory file to be exported to the export domain as well. when trying to
> export such
> memory file, we saw that the file is being truncated to the closest size
> that is
> a multiple of block size (512). we found that the file is being truncated
> by
> qemu-img that is being used to copy the file to the export domain.
>
> We previously thought that it is a problem in qemu - not handling files
> with size
> that is not a multiple of block size, and a bug to qemu was opened (bz
> 970559).
>
> We now understand that the issue described above might be a problem in qemu
> that
> needs to be solved, but it is not the problem in our case:
> treating the memory file as qemu image is wrong - the created file is not a
> qemu
> image. the file has a special format: it contains xml part at the beginning
> and
> the memory dump as a binary data right after that.
>
> So basically it seems that we need the following things in vdsm:
>
> 1. The creation of the file that is expected to store the memory as qemu
> image
> seems to be redundant. instead, we need to have a way to create a file in a
> similar way to 'touch' command - just to verify that the file in the path
> we
> pass to libvirt is created with the right permissions. (it's probably true
> for
> the hibernation volume creation as well btw).
how would this look for block devices?
It is working as expected on block devices
(tested).
When dumping the memory the file, libvirt is doing O_TRUNC and the resultant
file have a random lenght which can be odd. This is erronously treated by the
qemu-img utility.
>
> 2. The more important issue is that we need to have a way to export files
> which
> are not qemu images to the export domain, which means without using the
> qemu-img
> process, just copy the file.
qemu-img is capable to deal with raw images, as
we are doing today, provided that
the files are a block size multiples, as can be expected for a file which is used
like a volume.
Having two export paths can be very cumbersome, we should find a less disruptive
solution.
ayal - anything close to this today - i remember various qemu-img vs. dd
patches in the past for copy operations?
>
>>
>> - Reminder to follow wiki feature page process closely to maximize changes
>> to
>> have features added to a release.
>>
>> - Multiple gateways are being worked on to fix dhcp races and comments by
>> reviewers.
>>
>> - NetReloaded after multiple gateways. Try to get up to iproute2
>> configurator.
>>
>> - Cross-distro support:
>> + Netreloaded with iproute2 plus persistence would help.
>> + init scripts separation (proposed by Yaniv to make ready for 3.3).
>>
>> - Cloud-init integration by Greg Padgett. There is a vdsm patch that
>> should
>> be
>> taken care of in terms of reviewing http://gerrit.ovirt.org/#/c/14347/
>> _______________________________________________
>> vdsm-devel mailing list
>> vdsm-devel(a)lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
4:02 a.m.
On Fri, Jun 21, 2013 at 02:27:39PM +0300, Itamar Heim wrote:
On 06/18/2013 09:29 AM, Arik Hadas wrote:
>
>>- Is there a filing for Qemu image handling reported by virt team?
>
>Background about the problem:
>
>As part of the ram snapshots feature (http://wiki.ovirt.org/Features/RAM_Snapshots)
>we pass a path to file to libvirt, where the memory of the VM should be saved as
>part of the snapshot creation.
>the output file is identical to the one that is created to store the memory on
>hibernate command.
>
>When VM with snapshot(s) that has memory is being exported, we want the
snapshot's
>memory file to be exported to the export domain as well. when trying to export such
>memory file, we saw that the file is being truncated to the closest size that is
>a multiple of block size (512). we found that the file is being truncated by
>qemu-img that is being used to copy the file to the export domain.
>
>We previously thought that it is a problem in qemu - not handling files with size
>that is not a multiple of block size, and a bug to qemu was opened (bz 970559).
>
>We now understand that the issue described above might be a problem in qemu that
>needs to be solved, but it is not the problem in our case:
>treating the memory file as qemu image is wrong - the created file is not a qemu
>image. the file has a special format: it contains xml part at the beginning and
>the memory dump as a binary data right after that.
>
>So basically it seems that we need the following things in vdsm:
>
>1. The creation of the file that is expected to store the memory as qemu image
>seems to be redundant. instead, we need to have a way to create a file in a
>similar way to 'touch' command - just to verify that the file in the path we
>pass to libvirt is created with the right permissions. (it's probably true for
>the hibernation volume creation as well btw).
how would this look for block devices?
>
>2. The more important issue is that we need to have a way to export files which
>are not qemu images to the export domain, which means without using the qemu-img
>process, just copy the file.
ayal - anything close to this today - i remember various qemu-img
vs. dd patches in the past for copy operations?
Indeed, the problematic qemu-img call was introduced by
http://gerrit.ovirt.org/#/c/10979/5/vdsm/storage/image.py
In my opinion, replacing it with "cp" (that implies --sparse=auto) would
do the right thing for all combinations of file/block
qemu-disk/snapshot-ram-data.
Regards,
Dan.
4:29 a.m.
----- Original Message -----
On Fri, Jun 21, 2013 at 02:27:39PM +0300, Itamar Heim wrote:
> On 06/18/2013 09:29 AM, Arik Hadas wrote:
> >
> >>- Is there a filing for Qemu image handling reported by virt team?
> >
> >Background about the problem:
> >
> >As part of the ram snapshots feature
> >(http://wiki.ovirt.org/Features/RAM_Snapshots)
> >we pass a path to file to libvirt, where the memory of the VM should be
> >saved as
> >part of the snapshot creation.
> >the output file is identical to the one that is created to store the
> >memory on
> >hibernate command.
> >
> >When VM with snapshot(s) that has memory is being exported, we want the
> >snapshot's
> >memory file to be exported to the export domain as well. when trying to
> >export such
> >memory file, we saw that the file is being truncated to the closest size
> >that is
> >a multiple of block size (512). we found that the file is being truncated
> >by
> >qemu-img that is being used to copy the file to the export domain.
> >
> >We previously thought that it is a problem in qemu - not handling files
> >with size
> >that is not a multiple of block size, and a bug to qemu was opened (bz
> >970559).
> >
> >We now understand that the issue described above might be a problem in
> >qemu that
> >needs to be solved, but it is not the problem in our case:
> >treating the memory file as qemu image is wrong - the created file is not
> >a qemu
> >image. the file has a special format: it contains xml part at the
> >beginning and
> >the memory dump as a binary data right after that.
> >
> >So basically it seems that we need the following things in vdsm:
> >
> >1. The creation of the file that is expected to store the memory as qemu
> >image
> >seems to be redundant. instead, we need to have a way to create a file in
> >a
> >similar way to 'touch' command - just to verify that the file in the
path
> >we
> >pass to libvirt is created with the right permissions. (it's probably true
> >for
> >the hibernation volume creation as well btw).
>
> how would this look for block devices?
>
> >
> >2. The more important issue is that we need to have a way to export files
> >which
> >are not qemu images to the export domain, which means without using the
> >qemu-img
> >process, just copy the file.
>
> ayal - anything close to this today - i remember various qemu-img
> vs. dd patches in the past for copy operations?
Indeed, the problematic qemu-img call was introduced by
http://gerrit.ovirt.org/#/c/10979/5/vdsm/storage/image.py
In my opinion, replacing it with "cp" (that implies --sparse=auto) would
do the right thing for all combinations of file/block
qemu-disk/snapshot-ram-data.
No, for qcow images it would not dedup zeros (and reclaim space where relevant)
It would also not be able to collapse images.
Regards,
Dan.
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
5:12 a.m.
On Sun, Jun 23, 2013 at 05:29:40AM -0400, Ayal Baron wrote:
----- Original Message -----
> On Fri, Jun 21, 2013 at 02:27:39PM +0300, Itamar Heim wrote:
> > On 06/18/2013 09:29 AM, Arik Hadas wrote:
> > >
> > >>- Is there a filing for Qemu image handling reported by virt team?
> > >
> > >Background about the problem:
> > >
> > >As part of the ram snapshots feature
> > >(http://wiki.ovirt.org/Features/RAM_Snapshots)
> > >we pass a path to file to libvirt, where the memory of the VM should be
> > >saved as
> > >part of the snapshot creation.
> > >the output file is identical to the one that is created to store the
> > >memory on
> > >hibernate command.
> > >
> > >When VM with snapshot(s) that has memory is being exported, we want the
> > >snapshot's
> > >memory file to be exported to the export domain as well. when trying to
> > >export such
> > >memory file, we saw that the file is being truncated to the closest size
> > >that is
> > >a multiple of block size (512). we found that the file is being truncated
> > >by
> > >qemu-img that is being used to copy the file to the export domain.
> > >
> > >We previously thought that it is a problem in qemu - not handling files
> > >with size
> > >that is not a multiple of block size, and a bug to qemu was opened (bz
> > >970559).
> > >
> > >We now understand that the issue described above might be a problem in
> > >qemu that
> > >needs to be solved, but it is not the problem in our case:
> > >treating the memory file as qemu image is wrong - the created file is not
> > >a qemu
> > >image. the file has a special format: it contains xml part at the
> > >beginning and
> > >the memory dump as a binary data right after that.
> > >
> > >So basically it seems that we need the following things in vdsm:
> > >
> > >1. The creation of the file that is expected to store the memory as qemu
> > >image
> > >seems to be redundant. instead, we need to have a way to create a file in
> > >a
> > >similar way to 'touch' command - just to verify that the file in
the path
> > >we
> > >pass to libvirt is created with the right permissions. (it's probably
true
> > >for
> > >the hibernation volume creation as well btw).
> >
> > how would this look for block devices?
> >
> > >
> > >2. The more important issue is that we need to have a way to export files
> > >which
> > >are not qemu images to the export domain, which means without using the
> > >qemu-img
> > >process, just copy the file.
> >
> > ayal - anything close to this today - i remember various qemu-img
> > vs. dd patches in the past for copy operations?
>
> Indeed, the problematic qemu-img call was introduced by
> http://gerrit.ovirt.org/#/c/10979/5/vdsm/storage/image.py
>
> In my opinion, replacing it with "cp" (that implies --sparse=auto) would
> do the right thing for all combinations of file/block
> qemu-disk/snapshot-ram-data.
No, for qcow images it would not dedup zeros (and reclaim space where relevant)
It would also not be able to collapse images.
The relevant code runs for RAW file format. I.e., no qcow at the
source and no chains.
4:25 a.m.
----- Original Message -----
On 06/18/2013 09:29 AM, Arik Hadas wrote:
>
> ----- Original Message -----
>> VDSM sync meeting Monday June 17th 2013
>> =======================================
>>
>> - Dan requests reviews for pending patches from Mei Liu and himself (
>> http://gerrit.ovirt.org/#/c/15356/8 ) for mom.
>>
>> - Toni to fix the problem with Mark's patch that Dan reviewed so that it
>> can
>> be merged together with the smaller following patches.
>>
>> - Federico has three high priority patches for features and two lower
>> priority
>> ones that need reviews in order to make it for the release deadline.
>> They
>> are
>> related to disk extension and image upload/download (glance):
>> + http://gerrit.ovirt.org/#/c/15442 - constants: unify the BLANK_UUID
>> def...
>> + http://gerrit.ovirt.org/#/c/14589 - volume: add the BLOCK_SIZE
>> constant
>> +1
>> + http://gerrit.ovirt.org/#/c/14590 - volume: add the extendVolumeSize
>> method
>> + http://gerrit.ovirt.org/#/c/15614 - vm: add the live diskSizeExtend
>> method +1
>> + http://gerrit.ovirt.org/#/c/14955 - image: add support to
>> upload/download
>> images
>>
>> - Adam and others to review Gluster patches:
>> + http://gerrit.ovirt.org/#/c/13785/
>> + http://gerrit.ovirt.org/#/c/11094/
>>
>> - Is there a filing for Qemu image handling reported by virt team?
>
> Background about the problem:
>
> As part of the ram snapshots feature
> (http://wiki.ovirt.org/Features/RAM_Snapshots)
> we pass a path to file to libvirt, where the memory of the VM should be
> saved as
> part of the snapshot creation.
> the output file is identical to the one that is created to store the memory
> on
> hibernate command.
>
> When VM with snapshot(s) that has memory is being exported, we want the
> snapshot's
> memory file to be exported to the export domain as well. when trying to
> export such
> memory file, we saw that the file is being truncated to the closest size
> that is
> a multiple of block size (512). we found that the file is being truncated
> by
> qemu-img that is being used to copy the file to the export domain.
>
> We previously thought that it is a problem in qemu - not handling files
> with size
> that is not a multiple of block size, and a bug to qemu was opened (bz
> 970559).
>
> We now understand that the issue described above might be a problem in qemu
> that
> needs to be solved, but it is not the problem in our case:
> treating the memory file as qemu image is wrong - the created file is not a
> qemu
> image. the file has a special format: it contains xml part at the beginning
> and
> the memory dump as a binary data right after that.
>
> So basically it seems that we need the following things in vdsm:
>
> 1. The creation of the file that is expected to store the memory as qemu
> image
> seems to be redundant. instead, we need to have a way to create a file in a
> similar way to 'touch' command - just to verify that the file in the path
> we
> pass to libvirt is created with the right permissions. (it's probably true
> for
> the hibernation volume creation as well btw).
how would this look for block devices?
yes, it will work only for NFS.. on block devices we'll have to keep creating
the file or implement our own version for 'touch' which doesn't make so much
sense.. so maybe it's not such a good idea to drop the image creation part
>
> 2. The more important issue is that we need to have a way to export files
> which
> are not qemu images to the export domain, which means without using the
> qemu-img
> process, just copy the file.
ayal - anything close to this today - i remember various qemu-img vs. dd
patches in the past for copy operations?
>
>>
>> - Reminder to follow wiki feature page process closely to maximize changes
>> to
>> have features added to a release.
>>
>> - Multiple gateways are being worked on to fix dhcp races and comments by
>> reviewers.
>>
>> - NetReloaded after multiple gateways. Try to get up to iproute2
>> configurator.
>>
>> - Cross-distro support:
>> + Netreloaded with iproute2 plus persistence would help.
>> + init scripts separation (proposed by Yaniv to make ready for 3.3).
>>
>> - Cloud-init integration by Greg Padgett. There is a vdsm patch that
>> should
>> be
>> taken care of in terms of reviewing http://gerrit.ovirt.org/#/c/14347/
>> _______________________________________________
>> vdsm-devel mailing list
>> vdsm-devel(a)lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
3:44 a.m.
----- Original Message -----
----- Original Message -----
> VDSM sync meeting Monday June 17th 2013
> =======================================
>
> - Dan requests reviews for pending patches from Mei Liu and himself (
> http://gerrit.ovirt.org/#/c/15356/8 ) for mom.
>
> - Toni to fix the problem with Mark's patch that Dan reviewed so that it
> can
> be merged together with the smaller following patches.
>
> - Federico has three high priority patches for features and two lower
> priority
> ones that need reviews in order to make it for the release deadline. They
> are
> related to disk extension and image upload/download (glance):
> + http://gerrit.ovirt.org/#/c/15442 - constants: unify the BLANK_UUID
> def...
> + http://gerrit.ovirt.org/#/c/14589 - volume: add the BLOCK_SIZE constant
> +1
> + http://gerrit.ovirt.org/#/c/14590 - volume: add the extendVolumeSize
> method
> + http://gerrit.ovirt.org/#/c/15614 - vm: add the live diskSizeExtend
> method +1
> + http://gerrit.ovirt.org/#/c/14955 - image: add support to
> upload/download
> images
>
> - Adam and others to review Gluster patches:
> + http://gerrit.ovirt.org/#/c/13785/
> + http://gerrit.ovirt.org/#/c/11094/
>
> - Is there a filing for Qemu image handling reported by virt team?
Background about the problem:
As part of the ram snapshots feature
(http://wiki.ovirt.org/Features/RAM_Snapshots)
we pass a path to file to libvirt, where the memory of the VM should be saved
as
part of the snapshot creation.
the output file is identical to the one that is created to store the memory
on
hibernate command.
When VM with snapshot(s) that has memory is being exported, we want the
snapshot's
memory file to be exported to the export domain as well. when trying to
export such
memory file, we saw that the file is being truncated to the closest size that
is
a multiple of block size (512). we found that the file is being truncated by
qemu-img that is being used to copy the file to the export domain.
We previously thought that it is a problem in qemu - not handling files with
size
that is not a multiple of block size, and a bug to qemu was opened (bz
970559).
We now understand that the issue described above might be a problem in qemu
that
needs to be solved, but it is not the problem in our case:
treating the memory file as qemu image is wrong - the created file is not a
qemu
image. the file has a special format: it contains xml part at the beginning
and
the memory dump as a binary data right after that.
This is not correct.
qemu-img is a utility to manage images. There is no format limitation on images, and the
content of this file/device is no exception and no reason to treat it as one. This is a
raw device/file, we don't and shouldn't care about whether it has xml,
compression, encryption, qcow, whatever.
This is an image we pass to libvirt to use in order to dump the memory.
qemu-img manages raw files/devices and is used to keep sparseness, dedup zeros, etc.
So basically it seems that we need the following things in vdsm:
1. The creation of the file that is expected to store the memory as qemu
image
seems to be redundant. instead, we need to have a way to create a file in a
similar way to 'touch' command - just to verify that the file in the path we
pass to libvirt is created with the right permissions. (it's probably true
for
the hibernation volume creation as well btw).
2. The more important issue is that we need to have a way to export files
which
are not qemu images to the export domain, which means without using the
qemu-img
process, just copy the file.
>
> - Reminder to follow wiki feature page process closely to maximize changes
> to
> have features added to a release.
>
> - Multiple gateways are being worked on to fix dhcp races and comments by
> reviewers.
>
> - NetReloaded after multiple gateways. Try to get up to iproute2
> configurator.
>
> - Cross-distro support:
> + Netreloaded with iproute2 plus persistence would help.
> + init scripts separation (proposed by Yaniv to make ready for 3.3).
>
> - Cloud-init integration by Greg Padgett. There is a vdsm patch that should
> be
> taken care of in terms of reviewing http://gerrit.ovirt.org/#/c/14347/
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
5:19 a.m.
On Sun, Jun 23, 2013 at 04:44:19AM -0400, Ayal Baron wrote:
----- Original Message -----
>
> ----- Original Message -----
> > VDSM sync meeting Monday June 17th 2013
> > =======================================
> >
> > - Dan requests reviews for pending patches from Mei Liu and himself (
> > http://gerrit.ovirt.org/#/c/15356/8 ) for mom.
> >
> > - Toni to fix the problem with Mark's patch that Dan reviewed so that it
> > can
> > be merged together with the smaller following patches.
> >
> > - Federico has three high priority patches for features and two lower
> > priority
> > ones that need reviews in order to make it for the release deadline. They
> > are
> > related to disk extension and image upload/download (glance):
> > + http://gerrit.ovirt.org/#/c/15442 - constants: unify the BLANK_UUID
> > def...
> > + http://gerrit.ovirt.org/#/c/14589 - volume: add the BLOCK_SIZE constant
> > +1
> > + http://gerrit.ovirt.org/#/c/14590 - volume: add the extendVolumeSize
> > method
> > + http://gerrit.ovirt.org/#/c/15614 - vm: add the live diskSizeExtend
> > method +1
> > + http://gerrit.ovirt.org/#/c/14955 - image: add support to
> > upload/download
> > images
> >
> > - Adam and others to review Gluster patches:
> > + http://gerrit.ovirt.org/#/c/13785/
> > + http://gerrit.ovirt.org/#/c/11094/
> >
> > - Is there a filing for Qemu image handling reported by virt team?
>
> Background about the problem:
>
> As part of the ram snapshots feature
> (http://wiki.ovirt.org/Features/RAM_Snapshots)
> we pass a path to file to libvirt, where the memory of the VM should be saved
> as
> part of the snapshot creation.
> the output file is identical to the one that is created to store the memory
> on
> hibernate command.
>
> When VM with snapshot(s) that has memory is being exported, we want the
> snapshot's
> memory file to be exported to the export domain as well. when trying to
> export such
> memory file, we saw that the file is being truncated to the closest size that
> is
> a multiple of block size (512). we found that the file is being truncated by
> qemu-img that is being used to copy the file to the export domain.
>
> We previously thought that it is a problem in qemu - not handling files with
> size
> that is not a multiple of block size, and a bug to qemu was opened (bz
> 970559).
>
> We now understand that the issue described above might be a problem in qemu
> that
> needs to be solved, but it is not the problem in our case:
> treating the memory file as qemu image is wrong - the created file is not a
> qemu
> image. the file has a special format: it contains xml part at the beginning
> and
> the memory dump as a binary data right after that.
This is not correct.
qemu-img is a utility to manage images.
And here, we are trying to use it to copy something that is not a qemu
image.
There is no format limitation on images, and the content of this
file/device is no exception and no reason to treat it as one. This is a raw device/file,
we don't and shouldn't care about whether it has xml, compression, encryption,
qcow, whatever.
This is an image we pass to libvirt to use in order to dump the memory.
qemu-img manages raw files/devices and is used to keep sparseness, dedup zeros, etc.
It should not be hard to fix qemu-img to work with binary files of any
length. The only question is whether handling non-qemu-images is the
job for qemu-img.
Dan.
5:24 a.m.
----- Original Message -----
On Sun, Jun 23, 2013 at 04:44:19AM -0400, Ayal Baron wrote:
>
>
> ----- Original Message -----
> >
> > ----- Original Message -----
> > > VDSM sync meeting Monday June 17th 2013
> > > =======================================
> > >
> > > - Dan requests reviews for pending patches from Mei Liu and himself (
> > > http://gerrit.ovirt.org/#/c/15356/8 ) for mom.
> > >
> > > - Toni to fix the problem with Mark's patch that Dan reviewed so that
> > > it
> > > can
> > > be merged together with the smaller following patches.
> > >
> > > - Federico has three high priority patches for features and two lower
> > > priority
> > > ones that need reviews in order to make it for the release deadline.
> > > They
> > > are
> > > related to disk extension and image upload/download (glance):
> > > + http://gerrit.ovirt.org/#/c/15442 - constants: unify the BLANK_UUID
> > > def...
> > > + http://gerrit.ovirt.org/#/c/14589 - volume: add the BLOCK_SIZE
> > > constant
> > > +1
> > > + http://gerrit.ovirt.org/#/c/14590 - volume: add the
> > > extendVolumeSize
> > > method
> > > + http://gerrit.ovirt.org/#/c/15614 - vm: add the live diskSizeExtend
> > > method +1
> > > + http://gerrit.ovirt.org/#/c/14955 - image: add support to
> > > upload/download
> > > images
> > >
> > > - Adam and others to review Gluster patches:
> > > + http://gerrit.ovirt.org/#/c/13785/
> > > + http://gerrit.ovirt.org/#/c/11094/
> > >
> > > - Is there a filing for Qemu image handling reported by virt team?
> >
> > Background about the problem:
> >
> > As part of the ram snapshots feature
> > (http://wiki.ovirt.org/Features/RAM_Snapshots)
> > we pass a path to file to libvirt, where the memory of the VM should be
> > saved
> > as
> > part of the snapshot creation.
> > the output file is identical to the one that is created to store the
> > memory
> > on
> > hibernate command.
> >
> > When VM with snapshot(s) that has memory is being exported, we want the
> > snapshot's
> > memory file to be exported to the export domain as well. when trying to
> > export such
> > memory file, we saw that the file is being truncated to the closest size
> > that
> > is
> > a multiple of block size (512). we found that the file is being truncated
> > by
> > qemu-img that is being used to copy the file to the export domain.
> >
> > We previously thought that it is a problem in qemu - not handling files
> > with
> > size
> > that is not a multiple of block size, and a bug to qemu was opened (bz
> > 970559).
> >
> > We now understand that the issue described above might be a problem in
> > qemu
> > that
> > needs to be solved, but it is not the problem in our case:
> > treating the memory file as qemu image is wrong - the created file is not
> > a
> > qemu
> > image. the file has a special format: it contains xml part at the
> > beginning
> > and
> > the memory dump as a binary data right after that.
>
> This is not correct.
> qemu-img is a utility to manage images.
And here, we are trying to use it to copy something that is not a qemu
image.
This is a file created by qemu/libvirt and represents part of the VM. If that is not a
qemu image then I'm not sure what is.
> There is no format limitation on images, and the content of this
> file/device is no exception and no reason to treat it as one. This is a
> raw device/file, we don't and shouldn't care about whether it has xml,
> compression, encryption, qcow, whatever.
> This is an image we pass to libvirt to use in order to dump the memory.
> qemu-img manages raw files/devices and is used to keep sparseness, dedup
> zeros, etc.
It should not be hard to fix qemu-img to work with binary files of any
length. The only question is whether handling non-qemu-images is the
job for qemu-img.
Dan.
5:38 a.m.
On Sun, Jun 23, 2013 at 06:24:50AM -0400, Ayal Baron wrote:
----- Original Message -----
> On Sun, Jun 23, 2013 at 04:44:19AM -0400, Ayal Baron wrote:
> >
> >
> > ----- Original Message -----
> > >
> > > ----- Original Message -----
> > > > VDSM sync meeting Monday June 17th 2013
> > > > =======================================
> > > >
> > > > - Dan requests reviews for pending patches from Mei Liu and himself
(
> > > > http://gerrit.ovirt.org/#/c/15356/8 ) for mom.
> > > >
> > > > - Toni to fix the problem with Mark's patch that Dan reviewed so
that
> > > > it
> > > > can
> > > > be merged together with the smaller following patches.
> > > >
> > > > - Federico has three high priority patches for features and two
lower
> > > > priority
> > > > ones that need reviews in order to make it for the release
deadline.
> > > > They
> > > > are
> > > > related to disk extension and image upload/download (glance):
> > > > + http://gerrit.ovirt.org/#/c/15442 - constants: unify the
BLANK_UUID
> > > > def...
> > > > + http://gerrit.ovirt.org/#/c/14589 - volume: add the BLOCK_SIZE
> > > > constant
> > > > +1
> > > > + http://gerrit.ovirt.org/#/c/14590 - volume: add the
> > > > extendVolumeSize
> > > > method
> > > > + http://gerrit.ovirt.org/#/c/15614 - vm: add the live
diskSizeExtend
> > > > method +1
> > > > + http://gerrit.ovirt.org/#/c/14955 - image: add support to
> > > > upload/download
> > > > images
> > > >
> > > > - Adam and others to review Gluster patches:
> > > > + http://gerrit.ovirt.org/#/c/13785/
> > > > + http://gerrit.ovirt.org/#/c/11094/
> > > >
> > > > - Is there a filing for Qemu image handling reported by virt team?
> > >
> > > Background about the problem:
> > >
> > > As part of the ram snapshots feature
> > > (http://wiki.ovirt.org/Features/RAM_Snapshots)
> > > we pass a path to file to libvirt, where the memory of the VM should be
> > > saved
> > > as
> > > part of the snapshot creation.
> > > the output file is identical to the one that is created to store the
> > > memory
> > > on
> > > hibernate command.
> > >
> > > When VM with snapshot(s) that has memory is being exported, we want the
> > > snapshot's
> > > memory file to be exported to the export domain as well. when trying to
> > > export such
> > > memory file, we saw that the file is being truncated to the closest size
> > > that
> > > is
> > > a multiple of block size (512). we found that the file is being truncated
> > > by
> > > qemu-img that is being used to copy the file to the export domain.
> > >
> > > We previously thought that it is a problem in qemu - not handling files
> > > with
> > > size
> > > that is not a multiple of block size, and a bug to qemu was opened (bz
> > > 970559).
> > >
> > > We now understand that the issue described above might be a problem in
> > > qemu
> > > that
> > > needs to be solved, but it is not the problem in our case:
> > > treating the memory file as qemu image is wrong - the created file is not
> > > a
> > > qemu
> > > image. the file has a special format: it contains xml part at the
> > > beginning
> > > and
> > > the memory dump as a binary data right after that.
> >
> > This is not correct.
> > qemu-img is a utility to manage images.
>
> And here, we are trying to use it to copy something that is not a qemu
> image.
This is a file created by qemu/libvirt and represents part of the VM.
If that is not a qemu image then I'm not sure what is.
The file is created by libvirt, concatenating VM memory dump to its
metadata. That something else to the qemu disk images which qemu-img was
designed for (and named after).
5:45 a.m.
----- Original Message -----
On Sun, Jun 23, 2013 at 06:24:50AM -0400, Ayal Baron wrote:
>
>
> ----- Original Message -----
> > On Sun, Jun 23, 2013 at 04:44:19AM -0400, Ayal Baron wrote:
> > >
> > >
> > > ----- Original Message -----
> > > >
> > > > ----- Original Message -----
> > > > > VDSM sync meeting Monday June 17th 2013
> > > > > =======================================
> > > > >
> > > > > - Dan requests reviews for pending patches from Mei Liu and
himself
> > > > > (
> > > > > http://gerrit.ovirt.org/#/c/15356/8 ) for mom.
> > > > >
> > > > > - Toni to fix the problem with Mark's patch that Dan
reviewed so
> > > > > that
> > > > > it
> > > > > can
> > > > > be merged together with the smaller following patches.
> > > > >
> > > > > - Federico has three high priority patches for features and two
> > > > > lower
> > > > > priority
> > > > > ones that need reviews in order to make it for the release
> > > > > deadline.
> > > > > They
> > > > > are
> > > > > related to disk extension and image upload/download (glance):
> > > > > + http://gerrit.ovirt.org/#/c/15442 - constants: unify the
> > > > > BLANK_UUID
> > > > > def...
> > > > > + http://gerrit.ovirt.org/#/c/14589 - volume: add the
BLOCK_SIZE
> > > > > constant
> > > > > +1
> > > > > + http://gerrit.ovirt.org/#/c/14590 - volume: add the
> > > > > extendVolumeSize
> > > > > method
> > > > > + http://gerrit.ovirt.org/#/c/15614 - vm: add the live
> > > > > diskSizeExtend
> > > > > method +1
> > > > > + http://gerrit.ovirt.org/#/c/14955 - image: add support to
> > > > > upload/download
> > > > > images
> > > > >
> > > > > - Adam and others to review Gluster patches:
> > > > > + http://gerrit.ovirt.org/#/c/13785/
> > > > > + http://gerrit.ovirt.org/#/c/11094/
> > > > >
> > > > > - Is there a filing for Qemu image handling reported by virt
team?
> > > >
> > > > Background about the problem:
> > > >
> > > > As part of the ram snapshots feature
> > > > (http://wiki.ovirt.org/Features/RAM_Snapshots)
> > > > we pass a path to file to libvirt, where the memory of the VM should
> > > > be
> > > > saved
> > > > as
> > > > part of the snapshot creation.
> > > > the output file is identical to the one that is created to store the
> > > > memory
> > > > on
> > > > hibernate command.
> > > >
> > > > When VM with snapshot(s) that has memory is being exported, we want
> > > > the
> > > > snapshot's
> > > > memory file to be exported to the export domain as well. when trying
> > > > to
> > > > export such
> > > > memory file, we saw that the file is being truncated to the closest
> > > > size
> > > > that
> > > > is
> > > > a multiple of block size (512). we found that the file is being
> > > > truncated
> > > > by
> > > > qemu-img that is being used to copy the file to the export domain.
> > > >
> > > > We previously thought that it is a problem in qemu - not handling
> > > > files
> > > > with
> > > > size
> > > > that is not a multiple of block size, and a bug to qemu was opened
> > > > (bz
> > > > 970559).
> > > >
> > > > We now understand that the issue described above might be a problem
> > > > in
> > > > qemu
> > > > that
> > > > needs to be solved, but it is not the problem in our case:
> > > > treating the memory file as qemu image is wrong - the created file
is
> > > > not
> > > > a
> > > > qemu
> > > > image. the file has a special format: it contains xml part at the
> > > > beginning
> > > > and
> > > > the memory dump as a binary data right after that.
> > >
> > > This is not correct.
> > > qemu-img is a utility to manage images.
> >
> > And here, we are trying to use it to copy something that is not a qemu
> > image.
>
> This is a file created by qemu/libvirt and represents part of the VM.
> If that is not a qemu image then I'm not sure what is.
The file is created by libvirt, concatenating VM memory dump to its
metadata. That something else to the qemu disk images which qemu-img was
designed for (and named after).
A raw file is a raw file, the data inside it is irrelevant.
This is part of the VM.
qemu-img was also not originally designed for block devices, nor was qemu...
4:50 a.m.
Hi Kevin,
That's the thread I told you about
Can you please sound your opinion on this?
Thanks,
Arik
----- Original Message -----
----- Original Message -----
> On Sun, Jun 23, 2013 at 06:24:50AM -0400, Ayal Baron wrote:
> >
> >
> > ----- Original Message -----
> > > On Sun, Jun 23, 2013 at 04:44:19AM -0400, Ayal Baron wrote:
> > > >
> > > >
> > > > ----- Original Message -----
> > > > >
> > > > > ----- Original Message -----
> > > > > > VDSM sync meeting Monday June 17th 2013
> > > > > > =======================================
> > > > > >
> > > > > > - Dan requests reviews for pending patches from Mei Liu
and
> > > > > > himself
> > > > > > (
> > > > > > http://gerrit.ovirt.org/#/c/15356/8 ) for mom.
> > > > > >
> > > > > > - Toni to fix the problem with Mark's patch that Dan
reviewed so
> > > > > > that
> > > > > > it
> > > > > > can
> > > > > > be merged together with the smaller following patches.
> > > > > >
> > > > > > - Federico has three high priority patches for features and
two
> > > > > > lower
> > > > > > priority
> > > > > > ones that need reviews in order to make it for the
release
> > > > > > deadline.
> > > > > > They
> > > > > > are
> > > > > > related to disk extension and image upload/download
(glance):
> > > > > > + http://gerrit.ovirt.org/#/c/15442 - constants: unify
the
> > > > > > BLANK_UUID
> > > > > > def...
> > > > > > + http://gerrit.ovirt.org/#/c/14589 - volume: add the
> > > > > > BLOCK_SIZE
> > > > > > constant
> > > > > > +1
> > > > > > + http://gerrit.ovirt.org/#/c/14590 - volume: add the
> > > > > > extendVolumeSize
> > > > > > method
> > > > > > + http://gerrit.ovirt.org/#/c/15614 - vm: add the live
> > > > > > diskSizeExtend
> > > > > > method +1
> > > > > > + http://gerrit.ovirt.org/#/c/14955 - image: add support
to
> > > > > > upload/download
> > > > > > images
> > > > > >
> > > > > > - Adam and others to review Gluster patches:
> > > > > > + http://gerrit.ovirt.org/#/c/13785/
> > > > > > + http://gerrit.ovirt.org/#/c/11094/
> > > > > >
> > > > > > - Is there a filing for Qemu image handling reported by
virt
> > > > > > team?
> > > > >
> > > > > Background about the problem:
> > > > >
> > > > > As part of the ram snapshots feature
> > > > > (http://wiki.ovirt.org/Features/RAM_Snapshots)
> > > > > we pass a path to file to libvirt, where the memory of the VM
> > > > > should
> > > > > be
> > > > > saved
> > > > > as
> > > > > part of the snapshot creation.
> > > > > the output file is identical to the one that is created to
store
> > > > > the
> > > > > memory
> > > > > on
> > > > > hibernate command.
> > > > >
> > > > > When VM with snapshot(s) that has memory is being exported, we
want
> > > > > the
> > > > > snapshot's
> > > > > memory file to be exported to the export domain as well. when
> > > > > trying
> > > > > to
> > > > > export such
> > > > > memory file, we saw that the file is being truncated to the
closest
> > > > > size
> > > > > that
> > > > > is
> > > > > a multiple of block size (512). we found that the file is being
> > > > > truncated
> > > > > by
> > > > > qemu-img that is being used to copy the file to the export
domain.
> > > > >
> > > > > We previously thought that it is a problem in qemu - not
handling
> > > > > files
> > > > > with
> > > > > size
> > > > > that is not a multiple of block size, and a bug to qemu was
opened
> > > > > (bz
> > > > > 970559).
> > > > >
> > > > > We now understand that the issue described above might be a
problem
> > > > > in
> > > > > qemu
> > > > > that
> > > > > needs to be solved, but it is not the problem in our case:
> > > > > treating the memory file as qemu image is wrong - the created
file
> > > > > is
> > > > > not
> > > > > a
> > > > > qemu
> > > > > image. the file has a special format: it contains xml part at
the
> > > > > beginning
> > > > > and
> > > > > the memory dump as a binary data right after that.
> > > >
> > > > This is not correct.
> > > > qemu-img is a utility to manage images.
> > >
> > > And here, we are trying to use it to copy something that is not a qemu
> > > image.
> >
> > This is a file created by qemu/libvirt and represents part of the VM.
> > If that is not a qemu image then I'm not sure what is.
>
> The file is created by libvirt, concatenating VM memory dump to its
> metadata. That something else to the qemu disk images which qemu-img was
> designed for (and named after).
A raw file is a raw file, the data inside it is irrelevant.
This is part of the VM.
qemu-img was also not originally designed for block devices, nor was qemu...
5:15 a.m.
Am 24.06.2013 um 11:50 hat Arik Hadas geschrieben:
Hi Kevin,
That's the thread I told you about
Can you please sound your opinion on this?
Thanks,
Arik
----- Original Message -----
>
>
> ----- Original Message -----
> > On Sun, Jun 23, 2013 at 06:24:50AM -0400, Ayal Baron wrote:
> > >
> > >
> > > ----- Original Message -----
> > > > On Sun, Jun 23, 2013 at 04:44:19AM -0400, Ayal Baron wrote:
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > [...]
> > > > > > > - Is there a filing for Qemu image handling reported
by virt
> > > > > > > team?
> > > > > >
> > > > > > Background about the problem:
> > > > > >
> > > > > > As part of the ram snapshots feature
> > > > > > (http://wiki.ovirt.org/Features/RAM_Snapshots)
> > > > > > we pass a path to file to libvirt, where the memory of the
VM
> > > > > > should
> > > > > > be
> > > > > > saved
> > > > > > as
> > > > > > part of the snapshot creation.
> > > > > > the output file is identical to the one that is created to
store
> > > > > > the
> > > > > > memory
> > > > > > on
> > > > > > hibernate command.
> > > > > >
> > > > > > When VM with snapshot(s) that has memory is being exported,
we want
> > > > > > the
> > > > > > snapshot's
> > > > > > memory file to be exported to the export domain as well.
when
> > > > > > trying
> > > > > > to
> > > > > > export such
> > > > > > memory file, we saw that the file is being truncated to the
closest
> > > > > > size
> > > > > > that
> > > > > > is
> > > > > > a multiple of block size (512). we found that the file is
being
> > > > > > truncated
> > > > > > by
> > > > > > qemu-img that is being used to copy the file to the export
domain.
> > > > > >
> > > > > > We previously thought that it is a problem in qemu - not
handling
> > > > > > files
> > > > > > with
> > > > > > size
> > > > > > that is not a multiple of block size, and a bug to qemu was
opened
> > > > > > (bz
> > > > > > 970559).
> > > > > >
> > > > > > We now understand that the issue described above might be a
problem
> > > > > > in
> > > > > > qemu
> > > > > > that
> > > > > > needs to be solved, but it is not the problem in our case:
> > > > > > treating the memory file as qemu image is wrong - the
created file
> > > > > > is
> > > > > > not
> > > > > > a
> > > > > > qemu
> > > > > > image. the file has a special format: it contains xml part
at the
> > > > > > beginning
> > > > > > and
> > > > > > the memory dump as a binary data right after that.
> > > > >
> > > > > This is not correct.
> > > > > qemu-img is a utility to manage images.
> > > >
> > > > And here, we are trying to use it to copy something that is not a
qemu
> > > > image.
> > >
> > > This is a file created by qemu/libvirt and represents part of the VM.
> > > If that is not a qemu image then I'm not sure what is.
> >
> > The file is created by libvirt, concatenating VM memory dump to its
> > metadata. That something else to the qemu disk images which qemu-img was
> > designed for (and named after).
>
> A raw file is a raw file, the data inside it is irrelevant.
> This is part of the VM.
Not everything that is part of a VM is an image - or to be more specific
for you: a disk image. I think the content we're talking about is really
VM state here, not the content of some disk.
qemu-img is clearly meant as a tool for managing disk images (it even
calls itself "QEMU disk image utility" in the --help output). Using it
for anything else is abuse.
I haven't closed the bug against qemu yet because I think there may in
theory be some device that doesn't require that the image size is a
multiple of 512, so I'm considering to patch this in order to make it
work. This is of course not an urgent bug fix, but a feature extension
for a very theoretical case with low priority.
But even if it worked eventually, it would be wrong for you to use it
for copying arbitrary files. You should really use qemu-img only for
disk images and resort to things like 'cp --sparse=always' for copying
other files.
> qemu-img was also not originally designed for block devices, nor
was qemu...
Not really relevant for this discussion, but block devices were
considered from the beginning - and most importantly, they are about
disks.
Kevin
2:34 a.m.
On Mon, Jun 17, 2013 at 10:05:01AM -0400, Antoni Segura Puimedon wrote:
VDSM sync meeting Monday June 17th 2013
=======================================
- Dan requests reviews for pending patches from Mei Liu and himself (
http://gerrit.ovirt.org/#/c/15356/8 ) for mom.
- Toni to fix the problem with Mark's patch that Dan reviewed so that it can
be merged together with the smaller following patches.
- Federico has three high priority patches for features and two lower priority
ones that need reviews in order to make it for the release deadline. They are
related to disk extension and image upload/download (glance):
+ http://gerrit.ovirt.org/#/c/15442 - constants: unify the BLANK_UUID def...
+ http://gerrit.ovirt.org/#/c/14589 - volume: add the BLOCK_SIZE constant +1
+ http://gerrit.ovirt.org/#/c/14590 - volume: add the extendVolumeSize method
+ http://gerrit.ovirt.org/#/c/15614 - vm: add the live diskSizeExtend method +1
+ http://gerrit.ovirt.org/#/c/14955 - image: add support to upload/download images
- Adam and others to review Gluster patches:
+ http://gerrit.ovirt.org/#/c/13785/
+ http://gerrit.ovirt.org/#/c/11094/
- Is there a filing for Qemu image handling reported by virt team?
- Reminder to follow wiki feature page process closely to maximize changes to
have features added to a release.
- Multiple gateways are being worked on to fix dhcp races and comments by
reviewers.
- NetReloaded after multiple gateways. Try to get up to iproute2 configurator.
- Cross-distro support:
+ Netreloaded with iproute2 plus persistence would help.
+ init scripts separation (proposed by Yaniv to make ready for 3.3).
- Cloud-init integration by Greg Padgett. There is a vdsm patch that should be
taken care of in terms of reviewing http://gerrit.ovirt.org/#/c/14347/
Douglas mentioned that he has built python-pthreading with a fix for
F19. That reminded me of a problem that I see when running
/usr/share/vdsm/vdsm from the terminal.
Exception RuntimeError: RuntimeError('cannot notify on un-acquired lock',) in
<module 'threading' from '/usr/lib64/python2.7/threading.pyc'>
ignored
is thrown to stderr. I have a feeling that that's a bug in python-pthreading.
Could anybody (Yaniv? Douglas?) take a look?
4016
days inactive
4023
days old
vdsm-devel@lists.fedorahosted.org
15 comments
7 participants
participants (7)
-
abaron＠redhat.com -
ahadas＠redhat.com -
asegurap＠redhat.com -
Dan Kenigsberg -
ewarszaw＠redhat.com -
iheim＠redhat.com -
Kevin Wolf