Bug 449696 - [Chapter 18] Virtualization_Live_Migration.xml:
[Chapter 18] Virtualization_Live_Migration.xml:
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: Virtualization_Guide (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Christopher Curran
Andrew Ross
: Documentation
Depends On:
Blocks: 449674
  Show dependency treegraph
Reported: 2008-06-02 21:38 EDT by Michael Hideo
Modified: 2013-10-20 18:05 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-01-26 23:53:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Hideo 2008-06-02 21:38:03 EDT


This section only talks about para-virtualized guests migration; what about
fully virtualized guests which is supported for x86 but not for ia64. There
should be a paragraph on fully virtualized guests and the limititations related
to the different archs.


inconsistent use of parens/non-parens when referrring to configuration
parameters, pick one...


same page, (xend-relocation-address ") and others have a strange lonely
double-quote.  This is probably an accident of formatting conversion.  It
appears on other pages too.
Comment 1 Christopher Curran 2008-06-04 22:01:52 EDT
I only know how to do it for the para-virtualized guests. This will need tech
review to identify how to do it for fully virtualized guests.
Comment 2 Bill Burns 2008-10-22 09:14:26 EDT
Cole can you help out Chris with this one?
Comment 3 Cole Robinson 2009-02-25 20:41:25 EST
I've only done migrations a handful of times, and every time I stumble over it. This isn't really my area of expertise.

clalance, think you can take a look at this section of the docs and make sure it covers FV all well?
Comment 4 Chris Lalancette 2009-02-26 05:18:42 EST
So, essentially, there is no difference from a users POV between a fully virtualized migration and a paravirtualized migration.  You still need to make sure that you mount shared storage (ala NFS, or GFS, or whatever), and then you issue all of the same commands.  So you can just change the wording in the section to say "this works for fully virtualized and paravirtualized guests".

That being said, there are a few problems with the sections on virtualization.  The first has to do with the location of the exported NFS directory.  If you use "/xentest", as the example suggests, you will be conflicting with the SELinux policy.  I would suggest using either "/var/lib/xen/images" (which I see you have warnings about; good), or "/xen", both of which are allowed by SELinux policy.

Next, there are numerous references to using "xm" style commands in that whole section.  Everything in there can be done with virsh equivalents, so all of that text should be updated to use the virsh equivalents.

If you have further questions, let me know; I've set this up a number of times, and it's fairly straightforward (if baroque), so I can help you out.

Chris Lalancette
Comment 5 Christopher Curran 2009-07-29 04:07:36 EDT

The xm commands are almost gone from that section. I'm not sure about all the virsh list (xm li) outputs though. Some of it didn't match the description before, it makes less sense now. If you could provide an example so I can get rid of the 'xm create' command it will be all libvirted. 

Moving this bug to ON_QA. Hopefully I can get it tested before 5.4

Comment 6 Chris Lalancette 2009-07-29 10:31:45 EDT
     Sorry, but can you be a bit more specific?  I clicked on the link above, but it still makes references to "xm migrate", etc.  I'm just assuming that is out of date.  Where is the newest version of the document that you want me to review, and what sections should I be reviewing?

Chris Lalancette
Comment 7 Michael Hideo 2009-08-02 20:08:06 EDT
(In reply to comment #6)
> Chris,
>      Sorry, but can you be a bit more specific?  I clicked on the link above,
> but it still makes references to "xm migrate", etc.  I'm just assuming that is
> out of date.  Where is the newest version of the document that you want me to
> review, and what sections should I be reviewing?

Located here:


- Mike
Comment 8 Chris Lalancette 2009-08-03 04:26:14 EDT
I think ccurran and I worked this out on IRC for the time being.  Chris, if there's anything more you need from me, please catch me on IRC or set this back to NEEDINFO.

Chris Lalancette
Comment 9 Christopher Curran 2009-11-15 19:38:25 EST
Should be all good. I am waiting on QE to test the procedure now.

Comment 10 Christopher Curran 2009-12-02 00:37:49 EST
Any progress from QA on this issue? This bug affects Red Hat Enterprise Linux 5 (all versions) and 6.

Comment 11 Andrew Ross 2009-12-02 17:25:31 EST
Chris C,

The migrate command is still using xm:

[et-virt08 ~]# xm migrate --live <domain-id> et-virt07
[et-virt08 ~]# xm migrate --live testvm1 et-virt07
[et-virt07 images]# xm migrate --live testvm1 et-virt08

Is comment #4 correct in that there should be no xm commands? 

From the man page it looks like a straight swap will work :)

migrate --live domain-id desturi migrateuri



Comment 12 Andrew Ross 2009-12-03 22:57:56 EST
Live migration as documented works for xm migrate :)

I tried the virsh migrate command, and it kept coming up with "could not connect to" errors.

There is one minor change needed:

" Initiate the live migration to et-virt08. in the example below et-virt07 is the hostname you are migrating to and <domain-id> must be replaced with a guest domain available to the host system.

[et-virt08 ~]# xm migrate --live <domain-id> et-virt07"

This should be the other way round. Run xm migrate on et-virt07 with et-virt08 as the args. Otherwise you get Domain not found: xenUnifiedDomainLookupByName error.

Moving back to assigned so we can get the text fixed up.
Comment 14 Christopher Curran 2009-12-09 23:45:11 EST
Fixed in build 77.

Note You need to log in before you can comment on or make changes to this bug.