[vdsm] VDSM sync meeting minutes June 10th, 2014
VDSM sync meeting June 10th 2014 We mainly discussed the status of features for 3.5. Storage: * live merge: pending on reviews and minor revisions Network: * 3.5 features are all merged * one open issue about activating networks at boot (to be resolved in two different ways 3.5/master) Infra: * json-rpc: pending on merge * ioprocess: pending on final review * configure-libvirt: pending on verification and final reviews -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Problems with vdsm deleted Storages Domains
Can you paste the exact traceback that you see in the vdsm log? Also, what vdsm version is it? Thanks, -- Federico - Original Message - From: David Andino david_and...@yahoo.com To: vdsm-devel@lists.fedorahosted.org Sent: Monday, May 26, 2014 12:37:35 AM Subject: [vdsm] Problems with vdsm deleted Storages Domains Hello everyone, I have serious troubles with something that recently happend and this is our story. We have 12 nodes and 1 engine server. Our infrastructure is based in ISCSI and NFS (for Exports and ISOs). Recently my partner made some bad practices with our NFS server and one thing we noted in the engine, was that all of our nodes were contending the SPM and they never got agreed which one would it take it and the logs pointed to a Metadata corruption in the NFS Domains and after hours of the contending situation we tried to stabilized it. Trying to stabilize our cluster, we shutdown our NFS server and nothing happened. The cluster was still contending the SPM. After many tests like putting the nodes in maintain mode, reboot, shutdown all the cluster, etc, The last thing we did was destroying from the configuration (using the web interface) the Export and ISO Domains leaving the Data Domain intact trying to put online our guests, and that was (I think) our big mistake. Because now we are getting a serious situation that our Data Domain is not getting online because the vdsm in every node are looking for the NFS domains we already deleted. We were using vdsClient to consult the information the vdsm is getting and it says that we have 1 Storage Pool Domain and 3 Storage Domains, our ISCSI and the 2 NFS domains that were deleted. We let only one node active and the rest are in maintenance and the message is that it still contending for SPM. The vdsm.log says that the node is not finding the NFS Storages. We tried to delete this domains using vdsCLient but it says that the node has to have the SPM but it can't take the SPM because it can't find the NFS Domains so is like a circle. Now the question would be. Is there any way to delete this domains from the vdsm configuration?. What do I have to do to break this circle and the node leave to contending the SPM and activate our Data Domain again?. I appreciate all your coments and help you can share with me. Regards David ___ 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] Rv: Re: Problems with vdsm deleted Storages Domains
- Original Message - From: David Andino david_and...@yahoo.com To: Federico Simoncelli fsimo...@redhat.com Sent: Monday, May 26, 2014 4:09:44 PM Subject: Re: Rv: Re: [vdsm] Problems with vdsm deleted Storages Domains Hello Federico I have attached the entire file so you can read it. Let me know whether you need anything else Thanks David The relevant traceback is: 7b861db2-05c7-44b1-aac7-b4ea018120cf::ERROR::2014-05-26 07:01:15,376::sp::329::Storage.StoragePool::(startSpm) Unexpected error Traceback (most recent call last): File /usr/share/vdsm/storage/sp.py, line 296, in startSpm self._updateDomainsRole() File /usr/share/vdsm/storage/securable.py, line 75, in wrapper return method(self, *args, **kwargs) File /usr/share/vdsm/storage/sp.py, line 205, in _updateDomainsRole domain = sdCache.produce(sdUUID) File /usr/share/vdsm/storage/sdc.py, line 98, in produce domain.getRealDomain() File /usr/share/vdsm/storage/sdc.py, line 52, in getRealDomain return self._cache._realProduce(self._sdUUID) File /usr/share/vdsm/storage/sdc.py, line 122, in _realProduce domain = self._findDomain(sdUUID) File /usr/share/vdsm/storage/sdc.py, line 141, in _findDomain dom = findMethod(sdUUID) File /usr/share/vdsm/storage/sdc.py, line 171, in _findUnfetchedDomain raise se.StorageDomainDoesNotExist(sdUUID) StorageDomainDoesNotExist: Storage domain does not exist: (u'ba26bc14-3aff-48eb-816c-e02e81e5fd63',) The problem was fixed (and backported to 3.4) in: http://gerrit.ovirt.org/25424 http://gerrit.ovirt.org/27194 That is going to be available in vdsm-4.14.8 With that build you'll be able to start the SPM and later on use forcedDetachStorageDomain to remove the old domain. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm sync meeting minutes April 1st, 2014
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org, de...@ovirt.org, lara...@redhat.com, nsof...@redhat.com, fsimo...@redhat.com Cc: lyarw...@redhat.com Sent: Wednesday, April 9, 2014 3:01:31 PM Subject: Re: [vdsm] vdsm sync meeting minutes April 1st, 2014 On Wed, Apr 02, 2014 at 09:29:09AM +0100, dan...@redhat.com wrote: - We had a very (too) heated debate about ignoring failures of setDomainRegularRole() in http://gerrit.ovirt.org/24495/ and http://gerrit.ovirt.org/25424. The pain point is that relying on domain role (master/regular) is faulty by design. We cannot avoid the cases where a pool has more than one domain with a master role written in its metadata. One side argued that oVirt should be fixed to handle this unescapable truth, or at least enumerate the places where Vdsm and Engine, both current and old, depend on master role uniqueness. The other side argued that this is not a priority task, and that we should try to garbage-collect known-bad master roles as a courtesy to people digging into domain metadata, and as a means to lessen the problem until we kill the pool concept in the upcoming version. I hope that I present the debate fairly enough. In order to move these two patches forward, how about: - Limit the usage of the catching-all except Exception and replace it with swalling only the expected IO error - Add a comment about setDomainRegularRole() being called only as a courtesy garbage-collection attempt. - Conduct a survey on whether migrateMaster is used by anyone. No supported Engine has it, but I there was a suggestion that it was still expected via the command line. You don't call masterMigrate directly. It's triggered when you deactivate the master domain. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Pending Self-Hosted-Engine Patches in ovirt-3.3.2
- Original Message - From: Ayal Baron aba...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: Dan Kenigsberg dan...@redhat.com, vdsm-de...@fedorahosted.org, hat...@redhat.com, ybron...@redhat.com Sent: Thursday, November 28, 2013 12:22:14 PM Subject: Re: Pending Self-Hosted-Engine Patches in ovirt-3.3.2 - Original Message - - Original Message - From: Dan Kenigsberg dan...@redhat.com To: vdsm-de...@fedorahosted.org Cc: hat...@redhat.com, ybron...@redhat.com, fsimo...@redhat.com Sent: Monday, November 25, 2013 10:16:16 PM Subject: Pending Self-Hosted-Engine Patches in ovirt-3.3.2 An important feature of ovirt-3.3 has not made it to the ovirt-3.3.0 deadline: http://www.ovirt.org/Features/Self_Hosted_Engine. It would allow to run Engine as a VM on top one of the hosts controlled by itself, saving resources and allowing high availablity out-of-the-box. The feature was not ready on time for the ovirt-3.3.0 release but now its Engine-side patches are merged, and its Vdsm-side patches are pending aproval for entry into Vdsm's stable branch. http://gerrit.ovirt.org/20189 We can skip this patch as it's unrelated (transient disks for the backup API). http://gerrit.ovirt.org/20190 http://gerrit.ovirt.org/20191 http://gerrit.ovirt.org/20192 http://gerrit.ovirt.org/20193 http://gerrit.ovirt.org/20194 http://gerrit.ovirt.org/20209 My problem with 20209 is that it *seems* to be the cause of a regression: https://bugzilla.redhat.com/show_bug.cgi?id=1033942 and the fix is still under discussion at: http://gerrit.ovirt.org/#/c/19555/ http://gerrit.ovirt.org/20300 http://gerrit.ovirt.org/21357 I suggest to take the pending patches into the ovirt-3.3 branch, and ship ovirt-3.3.2 with this feature enabled. We shall not release ovirt-3.3.2 before we are assured by quality engineering that we have no regression to main Vdsm code. If we do not receive this green light, and there's urgency to release ovirt-3.3.2, we'd fork and ship 3.3.2 only with the urgent fixes. Either we decide that bz1033942 is not a blocker (not severe enough or unrelated to 20209), or we'll have to postpone the merge of this series. I just spoke to Gadi and it seems that the scope of the bug is very limited. There's not evidence of any of the engine flows to be affected, even though getStorageDomainInfo fails 100% on all the visible master domains. So technically we're not blocked on this specific BZ anymore but I agree that the following still stands: That bz is not the issue. This feature did not make it into 3.3. 3.3.x are stabilization versions. We know that these patches were the cause of a lot of grief and as can be seen there are more instabilities there. I don't see how it is ok to backport these. They're in master, we are stabilizing them and they will be in ovirt 3.4 (feature freeze in 1 month!). A -2 from me on this. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] suggesting Yaniv Bronheim as ovirt-3.3 branch maintainer
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: vdsm-de...@fedorahosted.org, a...@ovirt.org Sent: Wednesday, October 9, 2013 1:55:03 PM Subject: suggesting Yaniv Bronheim as ovirt-3.3 branch maintainer Recently, the Vdsm branch ovirt-3.3 was rebased on a relatively-stabilized vdsm-4.13.0. As discussed elsewhere, oVirt-3.3.1 is expected to be a relatively large micro version. Plenty of bug fixes are expected to be suggested to this branch. Currently, Federico is responsible to merge patches for oVirt-3.3.1, with my assistance. I would like to nominate Yaniv to join us in this delicate task: on one hand we should fix as many problems, but on the other hand - avoid regressions and needless surprises. It is a micro version after all. Yaniv has a wide understanding of Vdsm internals, and I am certain he would know how to solve problems introduced by patches approved by him. Please grant him +2 and merge rights on the ovirt-3.3 branch of vdsm. +1 -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] vdsm live migration errors in latest master
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: Dead Horse deadhorseconsult...@gmail.com, users us...@ovirt.org, vdsm-de...@fedorahosted.org, aba...@redhat.com Sent: Thursday, September 26, 2013 1:38:15 AM Subject: Re: [Users] vdsm live migration errors in latest master On Tue, Sep 24, 2013 at 12:04:14PM -0400, Federico Simoncelli wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Dead Horse deadhorseconsult...@gmail.com Cc: us...@ovirt.org us...@ovirt.org, vdsm-de...@fedorahosted.org, fsimo...@redhat.com, aba...@redhat.com Sent: Tuesday, September 24, 2013 11:44:48 AM Subject: Re: [Users] vdsm live migration errors in latest master On Mon, Sep 23, 2013 at 04:05:34PM -0500, Dead Horse wrote: Seeing failed live migrations and these errors in the vdsm logs with latest VDSM/Engine master. Hosts are EL6.4 Thanks for posting this report. The log is from the source of migration, right? Could you trace the history of the hosts of this VM? Could it be that it was started on an older version of vdsm (say ovirt-3.3.0) and then (due to migration or vdsm upgrade) got into a host with a much newer vdsm? Would you share the vmCreate (or vmMigrationCreate) line for this Vm in your log? I smells like an unintended regression of http://gerrit.ovirt.org/17714 vm: extend shared property to support locking solving it may not be trivial, as we should not call _normalizeDriveSharedAttribute() automatically on migration destination, as it may well still be apart of a 3.3 clusterLevel. Also, migration from vdsm with extended shared property, to an ovirt 3.3 vdsm is going to explode (in a different way), since the destination does not expect the extended values. Federico, do we have a choice but to revert that patch, and use something like shared3 property instead? I filed a bug at: https://bugzilla.redhat.com/show_bug.cgi?id=1011608 A possible fix could be: http://gerrit.ovirt.org/#/c/19509 Beyond this, we must make sure that on Engine side, the extended shared values would be used only for clusterLevel 3.4 and above. Are the extended shared values already used by Engine? Yes. That's the idea. Actually to be fair, the second case you mentioned (migrating from extended shared property to old vdsm) it wouldn't have been possible I suppose (the issue here is that Dead Horse has one or more hosts running on master instead of 3.3). The extended shared property would have appeared only in 3.4 and to allow the migration you would have had to upgrade all the nodes. But anyway since we were also talking about a new 3.3.1 barnch I just went ahead and covered all cases. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] vdsm live migration errors in latest master
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: Dead Horse deadhorseconsult...@gmail.com, users us...@ovirt.org, vdsm-de...@fedorahosted.org, aba...@redhat.com Sent: Thursday, September 26, 2013 2:09:15 PM Subject: Re: [Users] vdsm live migration errors in latest master On Thu, Sep 26, 2013 at 05:35:46AM -0400, Federico Simoncelli wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: Dead Horse deadhorseconsult...@gmail.com, users us...@ovirt.org, vdsm-de...@fedorahosted.org, aba...@redhat.com Sent: Thursday, September 26, 2013 1:38:15 AM Subject: Re: [Users] vdsm live migration errors in latest master On Tue, Sep 24, 2013 at 12:04:14PM -0400, Federico Simoncelli wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Dead Horse deadhorseconsult...@gmail.com Cc: us...@ovirt.org us...@ovirt.org, vdsm-de...@fedorahosted.org, fsimo...@redhat.com, aba...@redhat.com Sent: Tuesday, September 24, 2013 11:44:48 AM Subject: Re: [Users] vdsm live migration errors in latest master On Mon, Sep 23, 2013 at 04:05:34PM -0500, Dead Horse wrote: Seeing failed live migrations and these errors in the vdsm logs with latest VDSM/Engine master. Hosts are EL6.4 Thanks for posting this report. The log is from the source of migration, right? Could you trace the history of the hosts of this VM? Could it be that it was started on an older version of vdsm (say ovirt-3.3.0) and then (due to migration or vdsm upgrade) got into a host with a much newer vdsm? Would you share the vmCreate (or vmMigrationCreate) line for this Vm in your log? I smells like an unintended regression of http://gerrit.ovirt.org/17714 vm: extend shared property to support locking solving it may not be trivial, as we should not call _normalizeDriveSharedAttribute() automatically on migration destination, as it may well still be apart of a 3.3 clusterLevel. Also, migration from vdsm with extended shared property, to an ovirt 3.3 vdsm is going to explode (in a different way), since the destination does not expect the extended values. Federico, do we have a choice but to revert that patch, and use something like shared3 property instead? I filed a bug at: https://bugzilla.redhat.com/show_bug.cgi?id=1011608 A possible fix could be: http://gerrit.ovirt.org/#/c/19509 Beyond this, we must make sure that on Engine side, the extended shared values would be used only for clusterLevel 3.4 and above. Are the extended shared values already used by Engine? Yes. That's the idea. Actually to be fair, the second case you mentioned (migrating from extended shared property to old vdsm) it wouldn't have been possible I suppose (the issue here is that Dead Horse has one or more hosts running on master instead of 3.3). The extended shared property would have appeared only in 3.4 and to allow the migration you would have had to upgrade all the nodes. But anyway since we were also talking about a new 3.3.1 barnch I just went ahead and covered all cases. I do not see how the 3.3.1 branch is relevant to the discussion, as its Vdsm is NOT going to support clusterLevel 3.4. That is what I was referring to. If 3.3.1 was 3.3.0 + backported patches then we just wouldn't backport the extended shared attributes patch and that's it. But from what I understood 3.3.1 will be rebased on master (where instead we have the extended shared attributes) and that is why we have to cover both migration direction cases (instead of just the simple getattr one). Pardon my slowliness, but would you confirm that this feature is to be used only on clusterLevel 3.4 and above? If so, I'm +2ing your patch. Yes, the extended attributes will be used in the hosted engine and cluster level 3.4. But what the engine does is not relevant to +2ing correct vdsm patches. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] vdsm live migration errors in latest master
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Dead Horse deadhorseconsult...@gmail.com Cc: us...@ovirt.org us...@ovirt.org, vdsm-de...@fedorahosted.org, fsimo...@redhat.com, aba...@redhat.com Sent: Tuesday, September 24, 2013 11:44:48 AM Subject: Re: [Users] vdsm live migration errors in latest master On Mon, Sep 23, 2013 at 04:05:34PM -0500, Dead Horse wrote: Seeing failed live migrations and these errors in the vdsm logs with latest VDSM/Engine master. Hosts are EL6.4 Thanks for posting this report. The log is from the source of migration, right? Could you trace the history of the hosts of this VM? Could it be that it was started on an older version of vdsm (say ovirt-3.3.0) and then (due to migration or vdsm upgrade) got into a host with a much newer vdsm? Would you share the vmCreate (or vmMigrationCreate) line for this Vm in your log? I smells like an unintended regression of http://gerrit.ovirt.org/17714 vm: extend shared property to support locking solving it may not be trivial, as we should not call _normalizeDriveSharedAttribute() automatically on migration destination, as it may well still be apart of a 3.3 clusterLevel. Also, migration from vdsm with extended shared property, to an ovirt 3.3 vdsm is going to explode (in a different way), since the destination does not expect the extended values. Federico, do we have a choice but to revert that patch, and use something like shared3 property instead? I filed a bug at: https://bugzilla.redhat.com/show_bug.cgi?id=1011608 A possible fix could be: http://gerrit.ovirt.org/#/c/19509 -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] glusterfs-client and el6
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, August 27, 2013 11:57:37 PM Subject: Re: [vdsm] glusterfs-client and el6 They are here: http://resources.ovirt.org/releases/3.3/rpm/EL/6/x86_64/glusterfs-cli-3.4.0-8.el6.x86_64.rpm posting top we are why? To clarify, we're hosting the glusterfs rpms only to allow an easy update from ovirt-3.2 to ovirt-3.3. Fresh ovirt-3.3 (and updated ovirt-3.2) will then use the new: ovirt-release-el6-8-1.noarch.rpm which includes the relevant glusterfs repository (for install and updates). -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Exploiting domain specific offload features
- Original Message - From: Deepak C Shetty deepa...@linux.vnet.ibm.com To: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, July 17, 2013 12:08:03 PM Subject: Re: [vdsm] Exploiting domain specific offload features On 07/17/2013 12:48 PM, M. Mohan Kumar wrote: Hello, We are adding features such as server offloaded cloning, snapshot of the files(ie VM disks) and zeroed vm disk allocation in GlusterFS. As of now only BD xlator supports offloaded cloning snapshot. Server offloaded zeroing of VM disks is supported both by posix and BD xlator. The initial approach is to use xattr interface to trigger this offload features such as # setfattr -n clone -v path-to-new-clone-file path-to-source-file will create clone of path-to-source-file in path-to-new-clone-file. Cloning is done in GlusterFS server side and its kind of server offloaded copy. Similarly snapshot can also be taken using setfattr approach. GlusterFS storage domain is already part of VDSM and we want to exploit offload features provided by GlusterFS through VDSM. Is there any way to exploit these features from VDSM as of now? Mohan, IIUC, zeroing of files in GlusterFS is supported for both posix and block backends of GlusterFS Today VDSM does zeroing (as part of preallocated vmdisk flow) itself using 'dd'. If GlusterFS supports zeroing this feature can be exploited in VDSM (by overriding create volume flow as needed) so that we can save compute resources on the VDSM host, when Gluster domain is being used. Regarding exploiting clone and snapshot, IIUC these are very native to VDSM today... it expects that snapshots are qcow2 based and they form the image chain etc... With snapshot and clone handled in Gluster transparently, these notions of VDSM will be broken, so it probably needs a lot of changes in lots of places in VDSM to exploit these. Federico/Ayal, Wanted to know your comments/opinion on this ? Is there a way to exploit these features in VDSM Gluster storage domain in an elegant way ? I think we can already start exploiting cloning whenever we need to copy a volume maintaining the same format (raw=raw, cow=cow). -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Exploiting domain specific offload features
- Original Message - From: Itamar Heim ih...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: Deepak C Shetty deepa...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org Sent: Wednesday, July 24, 2013 3:35:35 PM Subject: Re: [vdsm] Exploiting domain specific offload features On 07/24/2013 03:38 PM, Federico Simoncelli wrote: - Original Message - From: Deepak C Shetty deepa...@linux.vnet.ibm.com To: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, July 17, 2013 12:08:03 PM Subject: Re: [vdsm] Exploiting domain specific offload features On 07/17/2013 12:48 PM, M. Mohan Kumar wrote: Hello, We are adding features such as server offloaded cloning, snapshot of the files(ie VM disks) and zeroed vm disk allocation in GlusterFS. As of now only BD xlator supports offloaded cloning snapshot. Server offloaded zeroing of VM disks is supported both by posix and BD xlator. The initial approach is to use xattr interface to trigger this offload features such as # setfattr -n clone -v path-to-new-clone-file path-to-source-file will create clone of path-to-source-file in path-to-new-clone-file. Cloning is done in GlusterFS server side and its kind of server offloaded copy. Similarly snapshot can also be taken using setfattr approach. GlusterFS storage domain is already part of VDSM and we want to exploit offload features provided by GlusterFS through VDSM. Is there any way to exploit these features from VDSM as of now? Mohan, IIUC, zeroing of files in GlusterFS is supported for both posix and block backends of GlusterFS Today VDSM does zeroing (as part of preallocated vmdisk flow) itself using 'dd'. If GlusterFS supports zeroing this feature can be exploited in VDSM (by overriding create volume flow as needed) so that we can save compute resources on the VDSM host, when Gluster domain is being used. Regarding exploiting clone and snapshot, IIUC these are very native to VDSM today... it expects that snapshots are qcow2 based and they form the image chain etc... With snapshot and clone handled in Gluster transparently, these notions of VDSM will be broken, so it probably needs a lot of changes in lots of places in VDSM to exploit these. Federico/Ayal, Wanted to know your comments/opinion on this ? Is there a way to exploit these features in VDSM Gluster storage domain in an elegant way ? I think we can already start exploiting cloning whenever we need to copy a volume maintaining the same format (raw=raw, cow=cow). you still need to tailor the flow from engine's perspective, right? or just override the entity created by the engine with the native cloned one for simplicity? No, this change would be transparent to the engine. When vdsm is asked to clone/copy an image (eg. iirc create a non-thin-provisioned vm from template) it would use the gluster clone capability to offload the volume copy. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Exploiting domain specific offload features
- Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Deepak C Shetty deepa...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org, Ayal Baron aba...@redhat.com Sent: Wednesday, July 24, 2013 4:22:02 PM Subject: Re: [vdsm] Exploiting domain specific offload features - Original Message - From: Itamar Heim ih...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: Deepak C Shetty deepa...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org Sent: Wednesday, July 24, 2013 3:35:35 PM Subject: Re: [vdsm] Exploiting domain specific offload features On 07/24/2013 03:38 PM, Federico Simoncelli wrote: I think we can already start exploiting cloning whenever we need to copy a volume maintaining the same format (raw=raw, cow=cow). you still need to tailor the flow from engine's perspective, right? or just override the entity created by the engine with the native cloned one for simplicity? No, this change would be transparent to the engine. When vdsm is asked to clone/copy an image (eg. iirc create a non-thin-provisioned vm from template) Maybe in this case we use an hard-link (no time to check now). Anyway concept is that if we ever need to copy a volume within the same storage domain, that can be offloaded to gluster. it would use the gluster clone capability to offload the volume copy. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] issue while creating data domain over NFS
- Original Message -
From: Sandro Bonazzola sbona...@redhat.com
To: vdsm-devel@lists.fedorahosted.org
Cc: Federico Simoncelli fsimo...@redhat.com, Alex Lourie
alou...@redhat.com, Moran Goldboim
mgold...@redhat.com
Sent: Friday, June 7, 2013 9:58:46 AM
Subject: issue while creating data domain over NFS
Hi here is the relevant log in vdsm.log: vdsm is taken from master,
commit 419cafb
09:49:44,068::fileSD::238::Storage.Misc.excCmd::(getReadDelay) SUCCESS:
err = '0+1 records in\n0+1 records out\n479 bytes (479 B) copied,
5.6832e-05 s, 8.4 MB/s\n'; rc = 0
Thread-263::ERROR::2013-06-07
09:49:44,069::misc::240::Storage.Misc::(readspeed) Unable to parse dd
output: '479 bytes (479 B) copied, 5.6832e-05 s, 8.4 MB/s'
My bad this is an issue I introduced recently. I didn't know that dd could
output such a human-friendly string. I thought I got it all covered, but I
didn't take in consideration the exponential notation (and your super-fast
storage domain :)
5.6832e-05
Thread-263::ERROR::2013-06-07
09:49:44,069::domainMonitor::225::Storage.DomainMonitorThread::(_monitorDomain)
Error while collecting domain 5569b4ce-c43b-434e-b0d2-7066a6e9489a
monitoring information
Traceback (most recent call last):
File /usr/share/vdsm/storage/domainMonitor.py, line 203, in
_monitorDomain
self.nextStatus.readDelay = self.domain.getReadDelay()
File /usr/share/vdsm/storage/fileSD.py, line 238, in getReadDelay
stats = misc.readspeed(self.metafile, 4096)
File /usr/share/vdsm/storage/misc.py, line 241, in readspeed
raise se.MiscFileReadException(path)
MiscFileReadException: Internal file read failure:
('/rhev/data-center/mnt/192.168.1.104:_var_lib_images2/5569b4ce-c43b-434e-b0d2-7066a6e9489a/dom_md/metadata',)
I'll get it fixed soon.
--
Federico
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] issue while creating data domain over NFS
- Original Message -
From: Sandro Bonazzola sbona...@redhat.com
To: Federico Simoncelli fsimo...@redhat.com
Cc: vdsm-devel@lists.fedorahosted.org, Alex Lourie alou...@redhat.com,
Moran Goldboim mgold...@redhat.com
Sent: Friday, June 7, 2013 10:19:55 AM
Subject: Re: issue while creating data domain over NFS
Il 07/06/2013 10:05, Federico Simoncelli ha scritto:
- Original Message -
From: Sandro Bonazzola sbona...@redhat.com
To: vdsm-devel@lists.fedorahosted.org
Cc: Federico Simoncelli fsimo...@redhat.com, Alex Lourie
alou...@redhat.com, Moran Goldboim
mgold...@redhat.com
Sent: Friday, June 7, 2013 9:58:46 AM
Subject: issue while creating data domain over NFS
Hi here is the relevant log in vdsm.log: vdsm is taken from master,
commit 419cafb
09:49:44,068::fileSD::238::Storage.Misc.excCmd::(getReadDelay) SUCCESS:
err = '0+1 records in\n0+1 records out\n479 bytes (479 B) copied,
5.6832e-05 s, 8.4 MB/s\n'; rc = 0
Thread-263::ERROR::2013-06-07
09:49:44,069::misc::240::Storage.Misc::(readspeed) Unable to parse dd
output: '479 bytes (479 B) copied, 5.6832e-05 s, 8.4 MB/s'
My bad this is an issue I introduced recently. I didn't know that dd could
output such a human-friendly string. I thought I got it all covered, but I
didn't take in consideration the exponential notation (and your super-fast
storage domain :)
5.6832e-05
Thread-263::ERROR::2013-06-07
09:49:44,069::domainMonitor::225::Storage.DomainMonitorThread::(_monitorDomain)
Error while collecting domain 5569b4ce-c43b-434e-b0d2-7066a6e9489a
monitoring information
Traceback (most recent call last):
File /usr/share/vdsm/storage/domainMonitor.py, line 203, in
_monitorDomain
self.nextStatus.readDelay = self.domain.getReadDelay()
File /usr/share/vdsm/storage/fileSD.py, line 238, in getReadDelay
stats = misc.readspeed(self.metafile, 4096)
File /usr/share/vdsm/storage/misc.py, line 241, in readspeed
raise se.MiscFileReadException(path)
MiscFileReadException: Internal file read failure:
('/rhev/data-center/mnt/192.168.1.104:_var_lib_images2/5569b4ce-c43b-434e-b0d2-7066a6e9489a/dom_md/metadata',)
I'll get it fixed soon.
Thanks!
Can you verify that this is working?
http://gerrit.ovirt.org/15433
Make sure that your dd commands with Storage.Misc.excCmd::(getReadDelay)
prefix are still returning values in scientific notation.
Thanks,
--
Federico
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] VDSM Repository Reorganization
- Original Message - From: Saggi Mizrahi smizr...@redhat.com To: Adam Litke a...@us.ibm.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, Dan Kenigsberg dan...@redhat.com, Vinzenz Feenstra vfeen...@redhat.com, Ayal Baron aba...@redhat.com, Federico Simoncelli fsimo...@redhat.com Sent: Monday, February 18, 2013 8:50:30 PM Subject: Re: VDSM Repository Reorganization - Original Message - From: Adam Litke a...@us.ibm.com To: Federico Simoncelli fsimo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, Dan Kenigsberg dan...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Vinzenz Feenstra vfeen...@redhat.com, Ayal Baron aba...@redhat.com Sent: Tuesday, February 12, 2013 3:08:09 PM Subject: Re: VDSM Repository Reorganization On Mon, Feb 11, 2013 at 12:17:39PM -0500, Federico Simoncelli wrote: It is some time now that we are discussing an eventual repository reorganization for vdsm. In fact I'm sure that we all experienced at least once the discomfort of having several modules scattered around the tree. The main goal of the reorganization would be to place the modules in their proper location so that they can be used (imported) without any special change (or hack) even when the code is executed inside the development repository (e.g. tests). Recently there has been an initial proposal about moving some of these modules: http://gerrit.ovirt.org/#/c/11858/ That spawned an interesting discussion that must involve the entire community; in fact before starting any work we should try to converge on a decision for the final repository structure in order to minimize the discomfort for the contributors that will be forced to rebase their pending gerrit patches. Even if the full reorganization won't happen in a short time I think we should plan the entire structure now and then eventually move only few relevant modules to their final location. To start the discussion I'm attaching here a sketch of the vdsm repository structure that I envision: . |-- client | |-- [...] | `-- vdsClient.py |-- common | |-- [...] | |-- betterPopen | | `-- [...] | `-- vdsm | |-- [...] | `-- config.py |-- contrib | |-- [...] | |-- nfs-check.py | `-- sos |-- daemon | |-- [...] | |-- supervdsm.py | `-- vdsmd `-- tool |-- [...] `-- vdsm-tool The schema file vdsmapi-schema.json (as well as the python module to parse it) are needed by the server and clients. Initially I'd think it should be installed in 'common', but a client does not need things like betterPopen. Any recommendation on where the schema/API definition should live? Well they both should have the file but when installed both should have their own version of the file depending on the version installed of the client or the server. This is so that vdsm-cli doesn't depend on vdsm or vice-versa. You can't have them share the file since if one is installed with a version of the schema where the schema syntax changed the client\server will fail to parse the schema. I'm not sure what's the purpose of having different versions of the client/server on the same machine. The software repository is one and it should provide both (as they're built from the same source). This is the standard way of delivering client/server applications in all the distributions. We can change that but we must have a good reason. As for development, I think the least bad solution is to put it in contrib with symlinks that have relative paths. |--daemon | |-- [...] | `-- vdsmapi-schema.json - ../contrib/vdsmapi-schema.json |--client | |-- [...] | `-- vdsmapi-schema.json - ../contrib/vdsmapi-schema.json |--contrib | |-- [...] | `-- vdsmapi-schema.json : . Git knows how to handle symlinks and symlinks are relative to the location of the symlink. +1. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] VDSM Repository Reorganization
It is some time now that we are discussing an eventual repository reorganization for vdsm. In fact I'm sure that we all experienced at least once the discomfort of having several modules scattered around the tree. The main goal of the reorganization would be to place the modules in their proper location so that they can be used (imported) without any special change (or hack) even when the code is executed inside the development repository (e.g. tests). Recently there has been an initial proposal about moving some of these modules: http://gerrit.ovirt.org/#/c/11858/ That spawned an interesting discussion that must involve the entire community; in fact before starting any work we should try to converge on a decision for the final repository structure in order to minimize the discomfort for the contributors that will be forced to rebase their pending gerrit patches. Even if the full reorganization won't happen in a short time I think we should plan the entire structure now and then eventually move only few relevant modules to their final location. To start the discussion I'm attaching here a sketch of the vdsm repository structure that I envision: . |-- client | |-- [...] | `-- vdsClient.py |-- common | |-- [...] | |-- betterPopen | | `-- [...] | `-- vdsm | |-- [...] | `-- config.py |-- contrib | |-- [...] | |-- nfs-check.py | `-- sos |-- daemon | |-- [...] | |-- supervdsm.py | `-- vdsmd `-- tool |-- [...] `-- vdsm-tool This would allow any component (daemon, client, tool, etc...) to run in place with the only addition of PYTHONPATH=$(top_srcdir)/common. The tests would need also the additional component path but that is a given since it's what they should be testing. Once the components are in the proper place we can eventually start using distutils inside the Makefile.am files in order to simplify the installation process (and also as verification that our repository structure is complying with the python standards). Please get involved, share your feedback and proposals. Thanks, -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] A question about the SPM operation permission in VDSM
- Original Message -
From: Shu Ming shum...@linux.vnet.ibm.com
To: VDSM Project Development vdsm-devel@lists.fedorahosted.org
Sent: Tuesday, October 30, 2012 7:22:18 AM
Subject: [vdsm] A question about the SPM operation permission in VDSM
Hi,
In the VDSM code about some SPM operations like HSM.deleteImage(), It
is found that VDSM doesn't check if the operation will be launched
on a SPM host or not. It only checks if the storage pool is already
acquired by one SPM host, but not necessary the same host as the SPM
operation is delivered to. The code is like this:
HSM.deleteImage()
{
...
HSM._spmSchedule()
{
self.validateSPM(spUUID) --- Only check if the storage pool was
acquired by one host, but not necessary this host
}
...
}
So it really depends on the node management application AKA
ovirt-engine to dispatch the SPM operations to the right VDSM host.
Hi Shu,
validateSPM is:
def validateSPM(self, spUUID):
pool = self.getPool(spUUID)
if pool.spmRole != sp.SPM_ACQUIRED:
raise se.SpmStatusError(spUUID)
despite its ambiguous name SPM_ACQUIRED refers only to the spmRole
of the current host. That said, vdsm actually checks before running
deleteImage if the host is actually the SPM or not. Eventually you can
verify it running deleteImage on an HSM host, it should fail with:
# vdsClient 0 deleteImage ...
Not SPM: ('spUUID',)
--
Federico
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] v4.10.3 tagged
- Original Message - From: Dan Kenigsberg dan...@redhat.com To: vdsm-devel@lists.fedorahosted.org Cc: Federico Simoncelli fsimo...@redhat.com, Mike Burns mbu...@redhat.com Sent: Tuesday, December 11, 2012 8:24:49 PM Subject: v4.10.3 tagged I've just tagged v4.10.3 of vdsm. It has several interesting changes since the previous release (some are detailed below), and I would like to suggest it as a beta candidate for ovirt-3.2. A Fedora 18 build can be found here: http://koji.fedoraproject.org/koji/buildinfo?buildID=372402 -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Proposal to add Adam Litke as maintainer to vdsm
+1 - Original Message - From: Itamar Heim ih...@redhat.com To: Ayal Baron aba...@redhat.com, Dan Kenigsberg dan...@redhat.com, Saggi Mizrahi smizr...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Eduardo Warszawski ewars...@redhat.com, Igor Lvovsky ilvov...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Friday, November 16, 2012 5:50:27 PM Subject: Proposal to add Adam Litke as maintainer to vdsm Adam has been submitting numerous patches for VDSM for more than a year, most noticeably on improving VDSM API into, well, an API... I'd like to propose Adam as a maintainer for vdsm. Thanks, Itamar -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] API: Supporting internal/testing interfaces
- Original Message - From: Saggi Mizrahi smizr...@redhat.com To: dl...@redhat.com Cc: Federico Simoncelli fsimo...@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 4, 2012 1:27:27 PM Subject: Re: [vdsm] API: Supporting internal/testing interfaces - Original Message - From: Dor Laor dl...@redhat.com To: Saggi Mizrahi smizr...@redhat.com Cc: Federico Simoncelli fsimo...@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Wednesday, October 3, 2012 10:16:26 PM Subject: Re: [vdsm] API: Supporting internal/testing interfaces On 10/03/2012 09:52 PM, Saggi Mizrahi wrote: My personal preference is using the VDSM debug hook to inject code to a running VDSM and dynamically add whatever you want. This means the code is part of the test and not VDSM. That's might be good for debugging/tracing but not for full functional tests. There are also better ways for dynamic tracing. We used to use it (before the code rotted away) to add to VDSM the startCoverage() and endCoverage() verbs for tests. Another option is having the code in an optional RPM (similar to how debug hook is loaded only if it's installed) I might also accept unpythonic things like conditional compilation Asking people nicely not to use a method that might corrupt their data-center doesn't always work with good people not to mention bad ones. Using -test devices/interfaces is a common practice. It's good to keep them live within the code base so they won't get rotten and any reasonable user is aware it's only a test api. Downstream can always compile it out before shipping. Conditional compilation kind of awkward in python, but as I said I'll agree to have that as an option. From what I understand litke's proposal is having the bindings in a different RPM but I am actually talking about the server side code not being available or at least hooked up. I thought that the server side was modular too and Adam's proposal was a server side additional module that registers new verbs to expose. In any case, I personally like this being hard and tiresome to do because it makes living with bad design less tolerable. There are some things that are harder to test and debug no matter how you implement them. To see a single extension you have to start a vm and wait for the guest to fill the lv. A better design wouldn't change the fact that if you don't expose a verb you can't use it. In any case, I don't want new code to need to have special debug verbs, if you don't test a full VDSM you shouldn't need to have one running. Why you think that one thing should exclude the other. Here we're talking about providing easier ways to test more (not less). -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] API: Supporting internal/testing interfaces
- Original Message -
From: Saggi Mizrahi smizr...@redhat.com
To: Adam Litke a...@us.ibm.com
Cc: Dan Kenigsberg dan...@redhat.com, fsimo...@redhat.com,
vdsm-devel@lists.fedorahosted.org
Sent: Wednesday, October 3, 2012 9:27:02 PM
Subject: Re: API: Supporting internal/testing interfaces
Never expose such things through the API.
I know that it is currently impossible to test the mailbox \ lvextend
flow without a full blown VDSM running because of bad design but
this doesn't imply we should expose testing interface through the
main public API.
Ok, given that in the future we'll have a proper design, what is the
short term alternative to efficiently test the mailbox?
You also completely dismissed Adam's proposal to ship these in a separate
libvdsm-debug.so library.
--
Federico
- Original Message -
From: Adam Litke a...@us.ibm.com
To: vdsm-devel@lists.fedorahosted.org
Cc: Dan Kenigsberg dan...@redhat.com, fsimo...@redhat.com,
Saggi Mizrahi smizr...@redhat.com
Sent: Wednesday, October 3, 2012 3:09:48 PM
Subject: API: Supporting internal/testing interfaces
Hi,
A recent patch: http://gerrit.ovirt.org/#/c/8286/1 has brought up
an
important
issue regarding the vdsm API and I would like to open up a
discussion
about how
we should expose testing/internal interfaces in the next-generation
vdsm API.
The above change exposes an internal HSM verb 'sendExtendMsg' via
the
xmlrpc
interface. There is no doubt that this is useful for testing and
debugging the
storage mailbox functionality. Until now, all new APIs were
required
to be
documented in the vdsm api schema so that they can be properly
exported to end
users. But we don't really want end users to consume this
particular
API.
How should we handle this? I see a few options:
1) Don't document the API and omit it from the schema. This is the
patch's
current approach. I do not favor this approach because eventually
the xmlrpc
server will be going away and then we will lose the ability to use
this new
debugging API. We need to decide how to support debugging
interfaces
going
forward.
2) Expose it in the schema as a debugging API. This can be done by
extending
the symbol's dictionary with {'debug': True}. Initially, the API
documentation
and code generators can simply skip over these symbols. Later on,
we
could
generate an independent libvdsm-debug.so library that includes
these
debugging
APIs.
Thoughts?
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] sanlock issues
- Original Message - From: Saggi Mizrahi smizr...@redhat.com To: vdsm-devel vdsm-de...@fedorahosted.org Cc: ybronhei ybron...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Barak Azulay bazu...@redhat.com Sent: Sunday, September 23, 2012 1:17:01 PM Subject: sanlock issues If you are trying to run sanlock on fedora and you get this error: Sep 23 11:26:56 dhcp-XX-XX.tlv.redhat.com sanlock[7083]: 2012-09-23 11:26:56+0200 37014 [7083]: wdmd connect failed for watchdog handling You need to do this: # unload softdog if it's running rmmod softdog # Check if there are residual watchdog files under /dev and remove them rm /dev/watchdog* # reload the softdog module modprobe softdog # make sure the file is named /dev/watchdog mv /dev/watchdog? /dev/watchdog # set the proper selinux context restorecon /dev/watchdog # restart wdmd systemctl restart wdmd.service # restart sanlock systemctl restart sanlock.service # Profit! fortune There are several things involved here. Were multiple watchdog modules loaded? Why? Is the hardware watchdog loaded after sanlock (which itself loads the softdog)? Is sanlock loading the softdog even if there in an hardware watchdog present? It might also be an udev issue with the device naming. You shouldn't need to relabel the device (another udev issue?). I doubt that this workaround would survive a reboot (did you check?) BTW. fedora 17 or 18? -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Problem building vdsm RPM
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: Itzik Brown itz...@mellanox.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, September 19, 2012 4:18:08 PM Subject: Re: [vdsm] Problem building vdsm RPM - Original Message - From: Itzik Brown itz...@mellanox.com To: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, September 19, 2012 5:12:28 PM Subject: [vdsm] Problem building vdsm RPM I'm trying to build vdsm from git . After make rpm I get these errors: snip How exactly do you try to build? This is what working for me: $ git clone ... $ cd vdsm $ autoreconf -ivf $ ./configure $ make dist $ rpmbuild -tb vdsm*.gz The suggested way of building vdsm is: (clone and cd vdsm) $ ./autogen.sh --system $ make rpm -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Problem building vdsm RPM
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, Itzik Brown itz...@mellanox.com Sent: Thursday, September 20, 2012 12:12:28 PM Subject: Re: [vdsm] Problem building vdsm RPM - Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, Itzik Brown itz...@mellanox.com Sent: Thursday, September 20, 2012 1:06:53 PM Subject: Re: [vdsm] Problem building vdsm RPM - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Itzik Brown itz...@mellanox.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, September 19, 2012 4:18:08 PM Subject: Re: [vdsm] Problem building vdsm RPM - Original Message - From: Itzik Brown itz...@mellanox.com To: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, September 19, 2012 5:12:28 PM Subject: [vdsm] Problem building vdsm RPM I'm trying to build vdsm from git . After make rpm I get these errors: snip How exactly do you try to build? This is what working for me: $ git clone ... $ cd vdsm $ autoreconf -ivf $ ./configure $ make dist $ rpmbuild -tb vdsm*.gz The suggested way of building vdsm is: (clone and cd vdsm) $ ./autogen.sh --system $ make rpm No reason for the --system, as rpmbuild will execute configure with right settings. Correct, but since you have to run it why keeping different (wrong) settings locally (vs. the ones that you'll be using in the rpm)? Also, in most projects autogen does not run configure... this is something unique in vdsm I like to avoid. Taken from libvirt, I don't see value in de-automating things. If there is a problem with rpmbuild -tb tarball, we need to fix it... is there any? The problem with your rpmbuild command is that it's not automatic enough, if you want to automate it you use wildcards (vdsm*.gz) which will build any vdsm tar.gz you find in the directory rather the one you just prepared (which is what make rpm is doing). It's not that what you're saying is wrong (after all it's what autogen.sh and the Makefile rely upon, and it works for you), it's that what you do manually is already done automatically (with less potential errors and confusion for the newcomers). -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Problem building vdsm RPM
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, Itzik Brown itz...@mellanox.com Sent: Thursday, September 20, 2012 12:41:58 PM Subject: Re: [vdsm] Problem building vdsm RPM - Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, Itzik Brown itz...@mellanox.com Sent: Thursday, September 20, 2012 1:38:23 PM Subject: Re: [vdsm] Problem building vdsm RPM The problem with your rpmbuild command is that it's not automatic enough, if you want to automate it you use wildcards (vdsm*.gz) which will build any vdsm tar.gz you find in the directory rather the one you just prepared (which is what make rpm is doing). It's not that what you're saying is wrong (after all it's what autogen.sh and the Makefile rely upon, and it works for you), it's that what you do manually is already done automatically (with less potential errors and confusion for the newcomers). Well, my view is that there is a standard method of creating rpms out of source tree. That is why I pushed for autotools, so experienced people can use it in all the way they prefer. Newcomers that have done this on one project can reuse their knowledge to do this in another project. There is no need to create custom unique methods to confuse people. Are you suggesting that ./autogen.sh make rpm is unique? -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Problem building vdsm RPM
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, Itzik Brown itz...@mellanox.com Sent: Thursday, September 20, 2012 1:29:00 PM Subject: Re: [vdsm] Problem building vdsm RPM - Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, Itzik Brown itz...@mellanox.com Sent: Thursday, September 20, 2012 2:15:58 PM Subject: Re: [vdsm] Problem building vdsm RPM - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, Itzik Brown itz...@mellanox.com Sent: Thursday, September 20, 2012 12:41:58 PM Subject: Re: [vdsm] Problem building vdsm RPM - Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, Itzik Brown itz...@mellanox.com Sent: Thursday, September 20, 2012 1:38:23 PM Subject: Re: [vdsm] Problem building vdsm RPM The problem with your rpmbuild command is that it's not automatic enough, if you want to automate it you use wildcards (vdsm*.gz) which will build any vdsm tar.gz you find in the directory rather the one you just prepared (which is what make rpm is doing). It's not that what you're saying is wrong (after all it's what autogen.sh and the Makefile rely upon, and it works for you), it's that what you do manually is already done automatically (with less potential errors and confusion for the newcomers). Well, my view is that there is a standard method of creating rpms out of source tree. That is why I pushed for autotools, so experienced people can use it in all the way they prefer. Newcomers that have done this on one project can reuse their knowledge to do this in another project. There is no need to create custom unique methods to confuse people. Are you suggesting that ./autogen.sh make rpm is unique? Well... as far as I know more common is: $ ./autogen $ ./configure $ make rpm While I don't see the make rpm is required, I do not really care, as far as there is no magic hidden within... so that when we will publish release tarballs for download (using make dist of course no magic), people can simply do rpmbuild -tb on these to produce valid rpms. In the past people needed to use aclocal, autoconf, libtool, automake, gettext in proper sequence in order to produce build environment. autogen(or any script) was born to automate this task, the task of producing build environment so that configure could be executed. These days a single 'autoreconf -ivf' is doing exactly what in the past was complex, hence no autogen is required any more... but I don't care project putting a single command just for keep the name... It's not like anyone is preventing you from doing what you think is the best. The build system already supports what you want to do. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Fedora build vdsm-4.9.6-0.git1b07249
Hi all, you can download the latest vdsm build (4.9.6-0.git1b07249) for fedora 17 and 18 at: https://koji.fedoraproject.org/koji/packageinfo?packageID=12944 -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Move some of code from spec file into vdsm-tool function issue
- Original Message - From: Lei Li li...@linux.vnet.ibm.com To: vdsm-devel@lists.fedorahosted.org Cc: Adam Litke a...@us.ibm.com, Dan Kenigsberg dan...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Ryan Harper ry...@linux.vnet.ibm.com Sent: Monday, May 28, 2012 11:18:03 AM Subject: Move some of code from spec file into vdsm-tool function issue Hi guys, Adam point out a problem about my patch moving some of the post and preun section in vdsm spec file into vdsm-tool, and I have the same concern. After some discussion, I'd like to ask for your suggestion on the patch as link below. http://gerrit.ovirt.org/#patch,sidebyside,4528,3,vdsm.spec.in Please let me know your idea, thanks! VDSM is/was adding a password to libvirt to prevent anyone or anything (eg: virt-manager, etc...) from managing the VMs that are controlled by VDSM. In general I don't like this idea for a couple of reasons: it's too much intrusive (making modifications that are not expected) and it's using a standard and known password, which is something debatable for many reasons (even if it's doing well it's job of preventing careless mistakes). I already tried to use polkit upstream (so that the vdsm user can manage libvirt) and it worked pretty well, but it's not preventing other users or other applications from connecting to libvirt and controlling the VMs. Does anyone know if we still need this precaution? Is there any new feature of libvirt that we can easily use to seal the access to our VMs? -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Move some of code from spec file into vdsm-tool function issue
- Original Message - From: Daniel P. Berrange berra...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: Lei Li li...@linux.vnet.ibm.com, Adam Litke a...@us.ibm.com, Dan Kenigsberg dan...@redhat.com, Ryan Harper ry...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org, Ayal Baron aba...@redhat.com Sent: Monday, May 28, 2012 4:52:38 PM Subject: Re: Move some of code from spec file into vdsm-tool function issue On Mon, May 28, 2012 at 10:39:08AM -0400, Federico Simoncelli wrote: - Original Message - From: Lei Li li...@linux.vnet.ibm.com To: vdsm-devel@lists.fedorahosted.org Cc: Adam Litke a...@us.ibm.com, Dan Kenigsberg dan...@redhat.com, Federico Simoncelli fsimo...@redhat.com, Ryan Harper ry...@linux.vnet.ibm.com Sent: Monday, May 28, 2012 11:18:03 AM Subject: Move some of code from spec file into vdsm-tool function issue Hi guys, Adam point out a problem about my patch moving some of the post and preun section in vdsm spec file into vdsm-tool, and I have the same concern. After some discussion, I'd like to ask for your suggestion on the patch as link below. http://gerrit.ovirt.org/#patch,sidebyside,4528,3,vdsm.spec.in Please let me know your idea, thanks! Ok, then coming to your specific question, my opinion is: - vdsm should work out of the box even if libvirt doesn't require a password (polkit should be enough) - vdsm-tool should (at some point) update the sasl password with the content of libvirt_password (if present) - an admin wanting to secure libvirt will create the libvirt_password file and will use vdsm-tool to make it effective - if downstream wants to automate this will drop in a %config libvirt_password file (or maybe generating it runtime as we do with the certificate?) and will call vdsm-tool accordingly Dan? Thoughts? -- Federico VDSM is/was adding a password to libvirt to prevent anyone or anything (eg: virt-manager, etc...) from managing the VMs that are controlled by VDSM. In general I don't like this idea for a couple of reasons: it's too much intrusive (making modifications that are not expected) and it's using a standard and known password, which is something debatable for many reasons (even if it's doing well it's job of preventing careless mistakes). I already tried to use polkit upstream (so that the vdsm user can manage libvirt) and it worked pretty well, but it's not preventing other users or other applications from connecting to libvirt and controlling the VMs. Does anyone know if we still need this precaution? Is there any new feature of libvirt that we can easily use to seal the access to our VMs? Not yet, but the intention is that the role based access control code I am working on will allow VDSM to drop in a policy file which says allow read-only access to any user, read-write access to VDSM only. Which is what you were trying to achieve with this password setting. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Installation dependency for VDSM-4.9.6-0.109 package on FC16
Hi Shu, you can get sanlock and libvirt from fedora 17: # yum --releasever=17 update libvirt # yum --releasever=17 install sanlock And lvm2 from my repository: http://fsimonce.fedorapeople.org/lvm2/fedora-16/x86_64/ -- Federico - Original Message - From: Shu Ming shum...@linux.vnet.ibm.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Sunday, April 22, 2012 5:21:38 PM Subject: [vdsm] Installation dependency for VDSM-4.9.6-0.109 package on FC16 Hi, I am trying to upgrade my VDSM to the latest version. But it seems that several things should be upgraded before the new version of VDSM can be installed on fc16. I am wondering if FC16 is the recommended system for this upgrade. Can anyone tell me if the newer version of Fedora(FC17, FC18) are more compatible with the latest VDSM packages? Dependency check failed here. ---l [root@ovirt-node2 ~]# yum install vdsm Loaded plugins: langpacks, presto, refresh-packagekit fedora/metalink | 9.5 kB 00:00 ovirt-engine | 1.3 kB 00:00 updates/metalink | 4.4 kB 00:00 updates | 4.5 kB 00:00 updates/primary_db | 5.9 MB 00:14 updates/group| 1.9 MB 00:04 vdsm-changes | 2.9 kB 00:00 vdsm-changes/primary_db | 5.4 kB 00:00 Setting up Install Process Resolving Dependencies -- Running transaction check --- Package vdsm.x86_64 0:4.9.3.2-0.fc16 will be updated --- Package vdsm.x86_64 0:4.9.6-0.109.git009bc0c.fc16 will be an update -- Processing Dependency: vdsm-python = 4.9.6-0.109.git009bc0c.fc16 for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Processing Dependency: libvirt-python = 0.9.10 for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Processing Dependency: lvm2 = 2.02.95 for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Processing Dependency: libvirt = 0.9.10 for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Processing Dependency: sanlock = 2.1 for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Processing Dependency: ntp for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Processing Dependency: sanlock-python for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Running transaction check --- Package ntp.x86_64 0:4.2.6p4-1.fc16 will be installed -- Processing Dependency: ntpdate = 4.2.6p4-1.fc16 for package: ntp-4.2.6p4-1.fc16.x86_64 --- Package sanlock-python.x86_64 0:1.9-8.fc16 will be installed -- Processing Dependency: sanlock-lib = 1.9-8.fc16 for package: sanlock-python-1.9-8.fc16.x86_64 -- Processing Dependency: libsanlock.so.1()(64bit) for package: sanlock-python-1.9-8.fc16.x86_64 --- Package vdsm.x86_64 0:4.9.6-0.109.git009bc0c.fc16 will be an update -- Processing Dependency: libvirt-python = 0.9.10 for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Processing Dependency: lvm2 = 2.02.95 for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Processing Dependency: libvirt = 0.9.10 for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Processing Dependency: sanlock = 2.1 for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 --- Package vdsm-python.noarch 0:4.9.6-0.109.git009bc0c.fc16 will be installed -- Running transaction check --- Package ntpdate.x86_64 0:4.2.6p4-1.fc16 will be installed --- Package sanlock-lib.x86_64 0:1.9-8.fc16 will be installed --- Package vdsm.x86_64 0:4.9.6-0.109.git009bc0c.fc16 will be an update -- Processing Dependency: libvirt-python = 0.9.10 for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Processing Dependency: lvm2 = 2.02.95 for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Processing Dependency: libvirt = 0.9.10 for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Processing Dependency: sanlock = 2.1 for package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 -- Finished Dependency Resolution Error: Package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 (vdsm-changes) Requires: sanlock = 2.1 Available: sanlock-1.8-1.fc16.x86_64 (fedora) sanlock = 1.8-1.fc16 Available: sanlock-1.9-8.fc16.x86_64 (updates) sanlock = 1.9-8.fc16 Error: Package: vdsm-4.9.6-0.109.git009bc0c.fc16.x86_64 (vdsm-changes) Requires: libvirt-python = 0.9.10 Installed: libvirt-python-0.9.6-4.fc16.x86_64 (@updates) libvirt-python = 0.9.6-4.fc16 Available: libvirt-python-0.9.6-2.fc16.x86_64 (fedora) libvirt-python = 0.9.6-2.fc16 Available: libvirt-python-0.9.6-5.fc16.x86_64 (updates) libvirt-python = 0.9.6-5.fc16
Re: [vdsm] Installation dependency for VDSM-4.9.6-0.109 package on FC16
For a quick solution you can try to disable the signature check: # yum --help | grep gpg --nogpgcheck disable gpg signature checking The correct way to address the problem is adding the new gpg key (if it's actually required). You could try to get some help from the fedora community (check the wiki, irc, mailing lists, etc...). -- Federico - Original Message - From: ShaoHe Feng shao...@linux.vnet.ibm.com To: Federico Simoncelli fsimo...@redhat.com Cc: Shu Ming shum...@linux.vnet.ibm.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Monday, April 23, 2012 4:35:09 PM Subject: Re: [vdsm] Installation dependency for VDSM-4.9.6-0.109 package on FC16 error, when I apply these updates on my laptop. here is the err: Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-x86_64 The GPG keys listed for the Fedora 17 - x86_64 repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository. the libvirt is still 0.9.6 virsh # version --daemon Compiled against library: libvir 0.9.6 Using library: libvir 0.9.6 Using API: QEMU 0.9.6 Running hypervisor: QEMU 0.15.1 Running against daemon: 0.9.6 the sanlock version is still 1.9 $ sanlock version sanlock 1.9 (built Feb 20 2012 19:52:57) On 04/23/2012 08:04 PM, Federico Simoncelli wrote: Hi Shu, you can get sanlock and libvirt from fedora 17: # yum --releasever=17 update libvirt # yum --releasever=17 install sanlock And lvm2 from my repository: http://fsimonce.fedorapeople.org/lvm2/fedora-16/x86_64/ ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Running VDSM (master branch) on Fedora 16
- Original Message - From: Lee Yarwood lyarw...@redhat.com To: vdsm-devel@lists.fedorahosted.org Sent: Tuesday, April 10, 2012 1:21:06 PM Subject: Re: [vdsm] Running VDSM (master branch) on Fedora 16 Looks like your missing device-mapper-libs from the lvm build in this repo : # cat /etc/yum.repos.d/vdsm.repo [vdsm] name=vdsm baseurl=http://fsimonce.fedorapeople.org/lvm2/fedora-16/x86_64/ enabled=1 gpgcheck=0 # yum update device-mapper -y [..] Error: Package: device-mapper-libs-1.02.65-6.fc16.x86_64 (@updates) Requires: device-mapper = 1.02.65-6.fc16 Removing: device-mapper-1.02.65-6.fc16.x86_64 (@updates) device-mapper = 1.02.65-6.fc16 Updated By: device-mapper-1.02.74-6.fc16.x86_64 (vdsm) device-mapper = 1.02.74-6.fc16 Error: Package: device-mapper-1.02.74-6.fc16.x86_64 (vdsm) Requires: device-mapper-libs = 1.02.74-6.fc16 Installed: device-mapper-libs-1.02.65-6.fc16.x86_64 (@updates) device-mapper-libs = 1.02.65-6.fc16 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Could you try again? It should be fixed now. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Running VDSM (master branch) on Fedora 16
Hi all, lately we introduced two new requirements in the VDSM master branch, therefore if you want to run the latest code on Fedora 16 you need to update some packages that aren't shipped officially (yet): lvm2-2.02.95-6.fc16 http://koji.fedoraproject.org/koji/taskinfo?taskID=3959741 libvirt-0.9.10-2.fc16 http://repos.fedorapeople.org/repos/jforbes/virt-preview/ More info on the Virtualization Preview Repository: http://fedoraproject.org/wiki/Virtualization_Preview_Repository Please let me know if you have any problem, Thanks, -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Installing VDSM on an empty Fedora 16 machine?
- Original Message - From: Saša Tomić tomi...@gmail.com To: Federico Simoncelli fsimo...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, Dan Kenigsberg dan...@redhat.com Sent: Thursday, March 8, 2012 12:04:45 PM Subject: Re: [vdsm] Installing VDSM on an empty Fedora 16 machine? [root@fedora16 log]# tail libvirtd.log messages == libvirtd.log == 2012-03-08 10:53:09.589+: 2915: debug : virRegisterDriver:783 : driver=0x739960 name=QEMU 2012-03-08 10:53:09.589+: 2915: debug : virRegisterDriver:807 : registering QEMU as driver 10 2012-03-08 10:53:09.589+: 2915: debug : virRegisterDriver:783 : driver=0x739f60 name=LXC 2012-03-08 10:53:09.589+: 2915: debug : virRegisterDriver:807 : registering LXC as driver 11 2012-03-08 10:53:09.589+: 2915: debug : virRegisterDriver:783 : driver=0x73aa40 name=UML 2012-03-08 10:53:09.589+: 2915: debug : virRegisterDriver:807 : registering UML as driver 12 2012-03-08 10:53:09.589+: 2915: debug : virHookCheck:115 : No hook script /etc/libvirt/hooks/daemon 2012-03-08 10:53:09.589+: 2915: debug : virHookCheck:115 : No hook script /etc/libvirt/hooks/qemu 2012-03-08 10:53:09.589+: 2915: debug : virHookCheck:115 : No hook script /etc/libvirt/hooks/lxc 2012-03-08 10:53:09.590+: 2915: error : virNetTLSContextCheckCertBasicConstraints:166 : The certificate /etc/pki/vdsm/certs/vdsmcert.pem basic constraints show a CA, but we need one for a server Thanks now the path is correct, however we must fix the certificate automatic generation using the correct nsCertType values. I'll get that in few hours, for now you could try to disable ssl configuring: [vars] ssl = false in /etc/vdsm/vdsm.conf -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Installing VDSM on an empty Fedora 16 machine?
- Original Message - From: Saša Tomić tomi...@gmail.com To: Dan Kenigsberg dan...@redhat.com Cc: Federico Simoncelli fsimo...@redhat.com, vdsm-devel@lists.fedorahosted.org Sent: Thursday, March 8, 2012 12:32:35 PM Subject: Re: [vdsm] Installing VDSM on an empty Fedora 16 machine? On 03/08/2012 12:16 PM, Dan Kenigsberg wrote: On Thu, Mar 08, 2012 at 12:04:45PM +0100, Saša Tomić wrote: To have this removed, make sure /etc/vdsm/vdsm.conf has ssl=false, and run /lib/systemd/systemd-vdsmd reconfigure Basically, I believe that you have found a bug with the default certificate that Vdsm creates for itself when it is installed. Thanks. Let's see if you can work with ssl=false. Dan. Fantastic! This was the key! I finally have libvirtd running :) I previously tried service libvirtd reconfigure, which of course didn't work. Now service vdsmd start also works OK, and the [root@fedora16 log]# vdsClient 0 getVdsCaps prints several screens of info Could you verify that this patch is fixing the problem? http://gerrit.ovirt.org/2657 You can cherry-pick the patch with: $ git fetch http://gerrit.ovirt.org/p/vdsm refs/changes/57/2657/1 $ git cherry-pick FETCH_HEAD Eventually you can read more about gerrit here: http://www.ovirt.org/wiki/Working_with_gerrit.ovirt.org -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Live Merge and Storage Live Migration
- Original Message - From: Shu Ming shum...@linux.vnet.ibm.com To: Federico Simoncelli fsimo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 7, 2012 4:00:39 PM Subject: Re: [vdsm] Live Merge and Storage Live Migration Another question about the Storage Live Migration wiki page, in the Engine-VDSM flow: createVolumeCrossSD(): domain1: [base(raw)]-[snap1(qcow2)]-+-(VM) domain2: +-[snap2(qcow2)] blockMigrate(): domain1: [base(raw)]-[snap1(qcow2)]-+ domain2: +-[snap2(qcow2)]-(VM) I think there must have a storage quiesce time between the snap2 creation and setting the VM on top of snap2. When the snap2 is being created, VM cannot access snap1. Only after VM is set on top of snap2, the quiesce period is end. That is not required. The snap2 is there as place-holder (it doesn't hold any internal state about snap1). We need to do so because the lvm volume must be created on the SPM. After that the qemu-kvm re-initialize the qcow header in snap2 (hopefully fixing BZ#785683 too). -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Live Merge and Storage Live Migration
- Original Message - From: Itamar Heim ih...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 7, 2012 11:51:11 PM Subject: Re: [vdsm] Live Merge and Storage Live Migration On 02/06/2012 10:34 PM, Federico Simoncelli wrote: ... http://www.ovirt.org/wiki/Features/Design/LiveMerge I'm missing details on the behavior in case of failure. I assume once a backward merge started, the underlying image is corrupted and must be used only via the higher layer. as this is a touchy issue, I'd expect the design to explain how this is going to be represented in vdsm and engine if such a failure happens. (engine would affect UI, if needed). obviously, reverting to that previous node in the chain is not relevant once a backward merge started. Ah yes, correct. Thanks. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Live Merge and Storage Live Migration
During my endless journey back from FOSDEM (24 hours stuck in airports, taxi and trains because of one of the largest blizzards in Italy ever), I've been briefly working on the design for both live merge and storage live migration: http://www.ovirt.org/wiki/Features/Design/LiveMerge http://www.ovirt.org/wiki/Features/Design/StorageLiveMigration They're far for being complete but I'm not able to do anything better now. Please review if you're interested, the general idea should be correct even though there are several unfinished parts. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] oVirt Live Snapshots
- Original Message - From: Shu Ming shum...@linux.vnet.ibm.com To: Federico Simoncelli fsimo...@redhat.com Cc: qemu-de...@nongnu.org, libvir-l...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org, Dave Allan dal...@redhat.com, Eric Blake ebl...@redhat.com Sent: Thursday, February 2, 2012 1:59:01 PM Subject: Re: [vdsm] oVirt Live Snapshots Can someone explain what is DB in this wiki page? It is the ovirt-engine database, where the VMs/images information and status is stored. That part of the wiki should be improved. See, Live snapshots operation extend regular snapshots as follow: • Create a locked snapshot in DB -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] oVirt Live Snapshots
Hi, oVirt, and more specifically VDSM, is currently implementing the live snapshot feature using the API/commands provided by libvirt and qemu. It would be great if you could review the design and the current open issues at: http://ovirt.org/wiki/Live_Snapshots Thank you, -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: VDSM on Fedora
- Original Message - From: Federico Simoncelli fsimo...@redhat.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Wednesday, October 19, 2011 3:41:27 PM Subject: VDSM on Fedora Hi all, I'm actively working on the vdsm packages for fedora, you can test them from here: http://fsimonce.fedorapeople.org/vdsm/ Please check the README for more details: http://fsimonce.fedorapeople.org/vdsm/README.txt It would be great if any of you could verify the process before the ovirt workshop. Main site: - http://fsimonce.fedorapeople.org/vdsm/ Git repository with the fixes for fedora (not yet accepted upstream): - http://fedorapeople.org/gitweb?p=fsimonce/public_git/vdsm.git;a=summary Guide to add a fedora host to RHEV-M: - http://fsimonce.fedorapeople.org/vdsm/README.txt Fedora yum repository: - http://fsimonce.fedorapeople.org/vdsm/fedora-vdsm.repo Fedora rpms: - http://fsimonce.fedorapeople.org/vdsm/fedora-16/SRPMS/ - http://fsimonce.fedorapeople.org/vdsm/fedora-16/x86_64/ -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
