Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Helmut Wollmersdorfer wrote: > Michael Paesold wrote: > > First, 0.7.12 has a bug invented. You should better move to 0.7.13. I have never used 0.7.12. At the time I started to build drbd rpms for xen the 0.7.12 URL already had the "has_bug" information. Thanks. Today I rebased the rpm on 0.7.13 and went through the release notes of 0.7.12. >> this is my first post to the list, so a short introduction. I am from >> Vienna/Austria. Currently I am trying to use drbd backed devices as vbds >> in >> Xen and have live migration work. > > Tell more ... > > I do not understand live migration in _detail_, as I am unexperienced with > Xen. > Does it mean, that you 'xm [create|destroy] [path-to-drbd-device]' the > guests? Live migration works by: 1) syncing memory of the VM from host A to B while the vm is still running on host A 2) finally destroy the VM on host A 3) start running of the VM on host B The synchronization of the "disk" resources (vbd=virtual block device) is left to the user, usually using NFS et.al. This is accomplished by using a script that accepts "bind" and "unbind" commands and the disk resource name. I have created such scripts that do "drbdadm primary ..." on bind and "drbdadm secondary ..." on unbind. Now why it doesn't work. In reality the sequence of events is unfortunately this one: 1) create the resources on host B (i.e. including bind for vbds!) 2) synchronize memory 3) destroy the VM on host A (i.e. unbind of vbds on host A) 4) start running of the VM on host B So when xen tries to setup the vm on the new host in step 1, drbdadm primary will fail, because the device is still used on host A. And we can't just lie to xen because it will test if it can access the block device rw. So the problem is really with xen's sequence of the setup. There is in fact no real need to setup the vbd's so early. Unfortunately changing this in xen is beyond my skills (or my available time). It's not just an issue of moving some lines around. I had the idea to just ignore the bind for the vbd and do "ssh hostB drbdadm primary $resource" at unbind on the first host. disable_bd_claim could have help here. It doesn't, because the device is still read-only. Xen will fail. > I do a similar thing with with linux-vserver. Just[1] mount a DRBD device > as root '/' of a vserver guest, and then 'vserver <guest> > [start|stop|status]' via heartbeat. Works nice (now in pre-production > test). vserver <guest> start|stop will be quite a bit faster than restart in xen. With xen it's not really a very good option to do migration by shutdown/boot of the guest OS. Nevertheless, perhaps I should have a look at vserver. ;-) Best Regards, Michael Paesold