This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-users] Live migration not moving the disk image. Is is supposed to?

To: <xen-users@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-users] Live migration not moving the disk image. Is is supposed to?
From: "Jamie J. Begin" <begin@xxxxxxxxxxxxxxx>
Date: Thu, 15 May 2008 19:23:04 -0400
Delivery-date: Thu, 15 May 2008 16:23:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aci24p+m6V2g7b/4QCWLLw7h0pNhow==

From my reading, it looks like performing “xm migrate –live domU target_server” ought to also copy the disk image.  Am I right?


When I attempt this procedure, everything looks to work except for the image file getting moved.  The command takes about 30 seconds to complete and then “xm list” shows the domU to be gone from the old host and running on the new host.  The SSH connection to the domU also continues to function without a hiccup. However, the disk image isn’t located anywhere on the new server. Also, the xen log on the new server lists the following error:


[2008-05-15 19:10:21 xend 3790] ERROR (XendCheckpoint:275) Device 51712 (tap) could not be connected.

/virt/myserver.img does not exist

Traceback (most recent call last):

  File "/usr/lib64/python2.4/site-packages/xen/xend/XendCheckpoint.py", line 273, in restore

    dominfo.waitForDevices() # Wait for backends to set up

  File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 1760, in waitForDevices


  File "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 1158, in waitForDevices_

    return self.getDeviceController(deviceClass).waitForDevices()

  File "/usr/lib64/python2.4/site-packages/xen/xend/server/DevController.py", line 145, in waitForDevices

    return map(self.waitForDevice, self.deviceIDs())

  File "/usr/lib64/python2.4/site-packages/xen/xend/server/DevController.py", line 179, in waitForDevice

    raise VmError("Device %s (%s) could not be connected.\n%s" %

VmError: Device 51712 (tap) could not be connected.

/virt/myserver.img does not exist


I then attempt to execute on the domU that accesses the disk (“df”, for example) and the instance hangs.


Both servers are running the 64-bit version of CentOS and using the xen packages from the yum repos.  On the source server, “/virt” is mounted on an ext3 filesystem in an LVM volume.  “/virt” on the target server is also ext3, but without LVM.  Would this have any affect? The domU config file is pretty basic:


name = "myserver"

uuid = "42db455d-17be-5288-cf89-7820ddcd0c76"

maxmem = 512

memory = 512

vcpus = 1

bootloader = "/usr/bin/pygrub"




vfb = [ "type=vnc,vncunused=1" ]

disk = [ "tap:aio:/virt/myserver.img,xvda,w" ]

vif = [ "mac=00:16:3e:1e:94:fb,bridge=xenbr0" ]


Xen-users mailing list
<Prev in Thread] Current Thread [Next in Thread>