[libvirt-users] Live Block Migration with additional attached storage
Dear all, I am planning to use live block migration with one VM running on local disk and also attached additional disk from iSCSI or other shared storage. When block migration, not only local VM disk is copied to the destination but also the attached additional disk from shared storage. It is not desired in this situation. I just want the local VM disk is copied. Is there anyway to do this scenario? Does the concept of storage pool help this? I browse the source code but don't find hints right now. Thanks. Regards, Arnose
Dear all, I am planning to use live block migration with one VM running on local disk and also attached additional disk from iSCSI or other shared storage. When block migration, not only local VM disk is copied to the destination but also the attached additional disk from shared storage. It is not desired in this situation. I just want the local VM disk is copied. Is there anyway to do this scenario? Does the concept of storage pool help this? I browse the source code but don't find hints right now. Thanks. Regards, Arnose
On 07/10/2012 04:24 AM, Chun-Hung Chen wrote:
Dear all,
I am planning to use live block migration with one VM running on local disk and also attached additional disk from iSCSI or other shared storage. When block migration, not only local VM disk is copied to the destination but also the attached additional disk from shared storage. It is not desired in this situation. I just want the local VM disk is copied. Is there anyway to do this scenario?
Unfortunately, block migration during migration is an all-or-none prospect. And qemu 1.1 does not provide enough tools to do anything differently, short of creating a snapshot file where the snapshot delta is on shared storage, and then you manually copy the backing file into place on the destination, then migrate without copying storage; but there is no way to coalesce things back into one file once you take the snapshot. Qemu 1.2 will be adding some new features that allow for block storage migration as well as live commits (coalescing a delta snapshot file back into its backing file) which can then be exposed through libvirt to provide more functionality into what you want to do.
Does the concept of storage pool help this? I browse the source code but don't find hints right now.
A storage pool lets you inform libvirt where your shared storage lives, but does not help with the aspect of whether live storage migration is possible in the underlying qemu. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Hi Eric, Glad to hear your reply. I would wait and check. Thanks. Regards, Arnose On Wed, Jul 11, 2012 at 7:37 AM, Eric Blake <eblake@redhat.com> wrote:
Unfortunately, block migration during migration is an all-or-none prospect. And qemu 1.1 does not provide enough tools to do anything differently, short of creating a snapshot file where the snapshot delta is on shared storage, and then you manually copy the backing file into place on the destination, then migrate without copying storage; but there is no way to coalesce things back into one file once you take the snapshot.
Qemu 1.2 will be adding some new features that allow for block storage migration as well as live commits (coalescing a delta snapshot file back into its backing file) which can then be exposed through libvirt to provide more functionality into what you want to do.
Does the concept of storage pool help this? I browse the source code but don't find hints right now.
A storage pool lets you inform libvirt where your shared storage lives, but does not help with the aspect of whether live storage migration is possible in the underlying qemu.
-- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Hi Eric, As QEMU 1.2 is released, I don't find the feature you describe in the change log. http://wiki.qemu.org/ChangeLog/1.2 Does it mean that we will not have this feature in the coming release? Thanks. Regards, Chun-Hung On Wed, Jul 11, 2012 at 7:37 AM, Eric Blake <eblake@redhat.com> wrote:
On 07/10/2012 04:24 AM, Chun-Hung Chen wrote:
Dear all,
I am planning to use live block migration with one VM running on local disk and also attached additional disk from iSCSI or other shared storage. When block migration, not only local VM disk is copied to the destination but also the attached additional disk from shared storage. It is not desired in this situation. I just want the local VM disk is copied. Is there anyway to do this scenario?
Unfortunately, block migration during migration is an all-or-none prospect. And qemu 1.1 does not provide enough tools to do anything differently, short of creating a snapshot file where the snapshot delta is on shared storage, and then you manually copy the backing file into place on the destination, then migrate without copying storage; but there is no way to coalesce things back into one file once you take the snapshot.
Qemu 1.2 will be adding some new features that allow for block storage migration as well as live commits (coalescing a delta snapshot file back into its backing file) which can then be exposed through libvirt to provide more functionality into what you want to do.
Does the concept of storage pool help this? I browse the source code but don't find hints right now.
A storage pool lets you inform libvirt where your shared storage lives, but does not help with the aspect of whether live storage migration is possible in the underlying qemu.
-- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 09/07/2012 03:00 AM, Chun-Hung Chen wrote:
Hi Eric,
As QEMU 1.2 is released, I don't find the feature you describe in the change log. http://wiki.qemu.org/ChangeLog/1.2 Does it mean that we will not have this feature in the coming release?
Unfortunately, you are correct that 'drive-mirror' and 'block-commit' did not make qemu 1.2, so you now have to wait at least another three months for qemu 1.3 for it to be official. However, the patches are receiving active review upstream, and may hit qemu.git sooner than that (and as soon as they DO hit qemu.git, I won't mind applying the libvirt side of things, so we may have libvirt support as soon as the 0.10.2 release). drive-mirror hasn't seen a repost since v1, but Paolo expects to post v2 soon: https://lists.gnu.org/archive/html/qemu-devel/2012-07/msg03082.html block-commit is at RFC v2, and Jeff expects to post a non-RFC v3 soon: https://lists.gnu.org/archive/html/qemu-devel/2012-08/msg05079.html -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (2)
-
Chun-Hung Chen -
Eric Blake