Re: [vdsm] vdsm sync meeting June 17th 2013
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... ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm sync meeting June 17th 2013
- 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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Engine-devel] Snapshots with RAM feature
Hi All, The feature's wiki page has been massively updated (http://www.ovirt.org/Features/RAM_Snapshots) Major changes: 1. Withdraw the option of using the saved memory from snapshot when creating a VM from snapshot as the initial memory state of the VM, as it turned out that the VM configuration is stored inside the memory file. 2. Simplified the API between the engine and VDSM: using comma-separated string to represent the memory volume (which can be empty) instead of map with 'mode' and pool-domain-image-volume quartet values. Again, All feedback is welcome! Regards, Arik - Original Message - Hi All, The proposed feature will make it possible to run a VM which was reverted to live snapshot or created from live snapshot with the same memory state as it was at the moment the live snapshot was taken. http://www.ovirt.org/Features/RAM_Snapshots All feedback is welcome! Regards, Arik ___ Engine-devel mailing list engine-de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Snapshots with RAM feature
- Original Message - On 9 Apr 2013, at 10:01, Arik Hadas aha...@redhat.com wrote: Hi All, The proposed feature will make it possible to run a VM which was reverted to live snapshot or created from live snapshot with the same memory state as it was at the moment the live snapshot was taken. http://www.ovirt.org/Features/RAM_Snapshots All feedback is welcome! Nice! Perhaps on Run VM - how about instead of giving an option on start we'd have the possibility to strip the saved ram in snapshot beforehand? And keep the run logic as always start with ram when it exists. Yes, it makes sense to keep the run vm process short and simple by using the logic you propose and not to display any dialog in the process. An alternative approach for the removal of the ram from the snapshot can be to display a check box in the clone vm from snapshot dialog so that the user will be able to select whether to take the memory from the snapshot or not. and in the preview snapshot process to display a dialog with such check box also. that way we will be able to create both with memory state and without memory state VMs from snapshot that contains memory state. Also it is important to discard the ram on all forms of Run VM. Better discard it on error than mistakenly rerun with ram twice Absolutely, we should ensure that we remove the ram from the VM configuration if there's a chance that either the disks or the memory was changed since the VM was created from/reverted to the snapshot. Regards, Arik ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Snapshots with RAM feature
Hi All, The proposed feature will make it possible to run a VM which was reverted to live snapshot or created from live snapshot with the same memory state as it was at the moment the live snapshot was taken. http://www.ovirt.org/Features/RAM_Snapshots All feedback is welcome! Regards, Arik ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
