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.
I am just curious how HSM interact with SPM after HSM get merge request no matter if they are in the same host. On 2012-2-7 4:34, Federico Simoncelli wrote:
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.
----- Original Message -----
From: "Shu Ming" shuming@linux.vnet.ibm.com To: "Federico Simoncelli" fsimonce@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 7, 2012 4:10:38 AM Subject: Re: [vdsm] Live Merge and Storage Live Migration
I am just curious how HSM interact with SPM after HSM get merge request no matter if they are in the same host.
At the moment the engine is responsible to poll the merge status on the HSM (and restart it if failed). When it's successfully completed the deleteVolume command must be issued to the SPM.
In the future we might consider the mailbox as mean of communication between the HSM and the SPM, even though it's now enabled only for block storage domains (and if the irs.vol_extend_policy is ON).
Still the entry point would be the deleteVolume call on the SPM.
On 2012-2-7 20:23, Federico Simoncelli wrote:
----- Original Message -----
From: "Shu Ming"shuming@linux.vnet.ibm.com To: "Federico Simoncelli"fsimonce@redhat.com Cc: "VDSM Project Development"vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 7, 2012 4:10:38 AM Subject: Re: [vdsm] Live Merge and Storage Live Migration
I am just curious how HSM interact with SPM after HSM get merge request no matter if they are in the same host.
At the moment the engine is responsible to poll the merge status on the HSM (and restart it if failed). When it's successfully completed the deleteVolume command must be issued to the SPM.
Sorry for confusing. Please let me explain my question again. In the Engine-VDSM Flow of "LiveMerge" wiki page, the engine will call the merge interface from engine to HSM to request the merge. I was wondering what HSM will do after it get the merge request. Does it call further interfaces in SPM by whatever way to make SPM to commit the real merge operation or just complete the operation by it self? If it does, how SPM will tell HSM the status of the merge operation?////synchronizedly or asnchronizedly?
In the future we might consider the mailbox as mean of communication between the HSM and the SPM, even though it's now enabled only for block storage domains (and if the irs.vol_extend_policy is ON).
Still the entry point would be the deleteVolume call on the SPM.
Does it mean that deleteVolume call will be from HSM to SPM directly instead of from engine?
----- Original Message -----
From: "Shu Ming" shuming@linux.vnet.ibm.com To: "Federico Simoncelli" fsimonce@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 7, 2012 3:23:37 PM Subject: Re: [vdsm] Live Merge and Storage Live Migration
On 2012-2-7 20:23, Federico Simoncelli wrote:
----- Original Message -----
From: "Shu Ming" shuming@linux.vnet.ibm.com To: "Federico Simoncelli" fsimonce@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Tuesday, February 7, 2012 4:10:38 AM Subject: Re: [vdsm] Live Merge and Storage Live Migration
Sorry for confusing. Please let me explain my question again. In the Engine-VDSM Flow of "LiveMerge" wiki page, the engine will call the merge interface from engine to HSM to request the merge. I was wondering what HSM will do after it get the merge request. Does it call further interfaces in SPM by whatever way to make SPM to commit the real merge operation or just complete the operation by it self? If it does, how SPM will tell HSM the status of the merge operation? synchronizedly or asnchronizedly?
The merge operation is done on the HSM by the qemu process, no HSM-SPM interaction is required here.
In the future we might consider the mailbox as mean of communication between the HSM and the SPM, even though it's now enabled only for block storage domains (and if the irs.vol_extend_policy is ON).
Still the entry point would be the deleteVolume call on the SPM. Does it mean that deleteVolume call will be from HSM to SPM directly instead of from engine?
Yes but don't expect that anytime soon (as far as I know).
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.
On 2012-2-7 4:34, Federico Simoncelli wrote:
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.
----- Original Message -----
From: "Shu Ming" shuming@linux.vnet.ibm.com To: "Federico Simoncelli" fsimonce@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).
On 02/06/2012 10:34 PM, Federico Simoncelli wrote: ...
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.
http://www.ovirt.org/wiki/Features/Design/StorageLiveMigration
I'd mention this is currently done only in same host, and in same DC. live migrating between hosts/DCs requires more work on all components.
----- Original Message -----
From: "Itamar Heim" iheim@redhat.com To: "Federico Simoncelli" fsimonce@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: ...
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.
vdsm-devel@lists.fedorahosted.org