[Qemu-devel] vm live storage migration approach.

[Qemu-devel] vm live storage migration approach.

[Yaodong Yang]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

Hi all,

I'm investigating the current schemes for the VM live storage migration in
QEMU system. I have the following questions:

1. What is the functionality of drive_mirror in QEMU? Is it designed as a
VM live storage migration approach?

2. What's the difference between drive_mirror and vMotion? I learned that
vMotion employs IO Mirroring mechanism to migration a running VM with all
the virtual disk images. Are there any other mechanisms inside QEMU serve
this purpose as well?

I'm looking for a mechanism in QEMU, which is similar to vMotion ( IO
Mirroring) in ESX environment.

Thanks!
Yaodong

[-- Attachment #2: Type: text/html, Size: 929 bytes --]

Re: [Qemu-devel] vm live storage migration approach.

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

On 01/30/2015 09:25 AM, Yaodong Yang wrote:
> Hi all,
> 
> I'm investigating the current schemes for the VM live storage migration in
> QEMU system. I have the following questions:
> 
> 1. What is the functionality of drive_mirror in QEMU? Is it designed as a
> VM live storage migration approach?

Yes. drive-mirror was added precisely to support live storage migration.

> 
> 2. What's the difference between drive_mirror and vMotion? I learned that
> vMotion employs IO Mirroring mechanism to migration a running VM with all
> the virtual disk images. Are there any other mechanisms inside QEMU serve
> this purpose as well?

vMotion is not part of qemu, so I'm not sure what it does.  Therefore, I
cannot make a fair comparison.

> 
> I'm looking for a mechanism in QEMU, which is similar to vMotion ( IO
> Mirroring) in ESX environment.

Look at drive-mirror, block-backup, quorum drives, and lots of recent
threads on this list about adding redundant processing (such as the term
"COLO") for how to piece together lower-level blocks into whatever drive
mirroring scheme you can think of.


-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] vm live storage migration approach.

[Yaodong Yang]

[-- Attachment #1: Type: text/plain, Size: 2438 bytes --]

An follow up questions.

Suppose I have a running VM with two virtual disks, I would like to migrate
the vm from host A to host B. Both host A and host B have their own
isolated storage devices. Is there anyway to migrate the vm's memory, two
virtual disk images and other states together from host A to host B? Can
drive_mirror command itself finish this job? I noticed that drive_mirror
only mirror for one virtual disk and require both the source and
destination share the same storage namespace. I do not know how to migrate
the whole VM (memory, storage, network ) together from host A to host B,
given that host A and host B have NO shared storage resource.

Could you show me an example, if possible?

I know "migrate -b" works well for this purpose. But the downside is
"migrate -b" does not mirror Write Requests to both host A and host B
during migration. In this case, "migrate -b" has a higher VM downtime
during the migration.

Yaodong

On Fri, Jan 30, 2015 at 1:21 PM, Eric Blake <eblake@redhat.com> wrote:

> On 01/30/2015 09:25 AM, Yaodong Yang wrote:
> > Hi all,
> >
> > I'm investigating the current schemes for the VM live storage migration
> in
> > QEMU system. I have the following questions:
> >
> > 1. What is the functionality of drive_mirror in QEMU? Is it designed as a
> > VM live storage migration approach?
>
> Yes. drive-mirror was added precisely to support live storage migration.
>
> >
> > 2. What's the difference between drive_mirror and vMotion? I learned that
> > vMotion employs IO Mirroring mechanism to migration a running VM with all
> > the virtual disk images. Are there any other mechanisms inside QEMU serve
> > this purpose as well?
>
> vMotion is not part of qemu, so I'm not sure what it does.  Therefore, I
> cannot make a fair comparison.
>
> >
> > I'm looking for a mechanism in QEMU, which is similar to vMotion ( IO
> > Mirroring) in ESX environment.
>
> Look at drive-mirror, block-backup, quorum drives, and lots of recent
> threads on this list about adding redundant processing (such as the term
> "COLO") for how to piece together lower-level blocks into whatever drive
> mirroring scheme you can think of.
>
>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>


-- 
Yaodong Yang
yaodong.yangy@gmail.com or yyang@cse.unl.edu
Computer Science and Engineering Department
University of Nebraska-Lincoln
Lincoln, NE, USA

[-- Attachment #2: Type: text/html, Size: 3694 bytes --]

Re: [Qemu-devel] vm live storage migration approach.

[Stefan Hajnoczi]

On Fri, Jan 30, 2015 at 8:13 PM, Yaodong Yang <yaodong.yangy@gmail.com> wrote:
> An follow up questions.
>
> Suppose I have a running VM with two virtual disks, I would like to migrate
> the vm from host A to host B. Both host A and host B have their own isolated
> storage devices. Is there anyway to migrate the vm's memory, two virtual
> disk images and other states together from host A to host B? Can
> drive_mirror command itself finish this job? I noticed that drive_mirror
> only mirror for one virtual disk and require both the source and destination
> share the same storage namespace. I do not know how to migrate the whole VM
> (memory, storage, network ) together from host A to host B, given that host
> A and host B have NO shared storage resource.
>
> Could you show me an example, if possible?
>
> I know "migrate -b" works well for this purpose. But the downside is
> "migrate -b" does not mirror Write Requests to both host A and host B during
> migration. In this case, "migrate -b" has a higher VM downtime during the
> migration.

Hi Yaodong,
The answers to these questions are in libvirt's source code.  It
orchestrates live migration between two hosts.

Multiple independent drive_mirror jobs can run.  That's how you handle
multiple disks.

The regular migrate command (without -b) can be used if drive_mirror
is in place and fully synced.

Libvirt sets up an NBD server on the destination host.  The source
host runs drive_mirror to copy over the contents of the disk images.
Once the drive_mirror command has completed syncing data the regular
'migrate' command can be used to send device state and RAM over to the
destination host.

See qemuMigrationDriveMirror() in libvirt.

migrate -b is a legacy feature that is being replaced by drive_mirror.

Stefan

Re: [Qemu-devel] vm live storage migration approach.

[Yaodong Yang]

[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]

Thank you Stefan! Now I understand the workflow.

-Yaodong

On Fri, Jan 30, 2015 at 2:37 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:

> On Fri, Jan 30, 2015 at 8:13 PM, Yaodong Yang <yaodong.yangy@gmail.com>
> wrote:
> > An follow up questions.
> >
> > Suppose I have a running VM with two virtual disks, I would like to
> migrate
> > the vm from host A to host B. Both host A and host B have their own
> isolated
> > storage devices. Is there anyway to migrate the vm's memory, two virtual
> > disk images and other states together from host A to host B? Can
> > drive_mirror command itself finish this job? I noticed that drive_mirror
> > only mirror for one virtual disk and require both the source and
> destination
> > share the same storage namespace. I do not know how to migrate the whole
> VM
> > (memory, storage, network ) together from host A to host B, given that
> host
> > A and host B have NO shared storage resource.
> >
> > Could you show me an example, if possible?
> >
> > I know "migrate -b" works well for this purpose. But the downside is
> > "migrate -b" does not mirror Write Requests to both host A and host B
> during
> > migration. In this case, "migrate -b" has a higher VM downtime during the
> > migration.
>
> Hi Yaodong,
> The answers to these questions are in libvirt's source code.  It
> orchestrates live migration between two hosts.
>
> Multiple independent drive_mirror jobs can run.  That's how you handle
> multiple disks.
>
> The regular migrate command (without -b) can be used if drive_mirror
> is in place and fully synced.
>
> Libvirt sets up an NBD server on the destination host.  The source
> host runs drive_mirror to copy over the contents of the disk images.
> Once the drive_mirror command has completed syncing data the regular
> 'migrate' command can be used to send device state and RAM over to the
> destination host.
>
> See qemuMigrationDriveMirror() in libvirt.
>
> migrate -b is a legacy feature that is being replaced by drive_mirror.
>
> Stefan
>



-- 
Yaodong Yang
yaodong.yangy@gmail.com or yyang@cse.unl.edu
Computer Science and Engineering Department
University of Nebraska-Lincoln
Lincoln, NE, USA

[-- Attachment #2: Type: text/html, Size: 3260 bytes --]