Hi,
> Yes, this is exactly our point to do migration without allowing two
> primaries.
>
> We have tested the other way to migrate but none seems to work. Saving
> the vm doesn't stop the vm to be listed in xm list. If I destroy the
> save vm, then the restore fail. So our conclusion is that a save vm
> can't be restore on another host.
You're running into issues because of the way the xen stores the
configurations and what happens when you do an xm list
For example:
Name ID Mem VCPUs State
Time(s)
My_DomU 2048 1
34.1
Domain-0 0 12073 4 r-----
2622.7
My_DomU is not running (notice the lack of state info) but is in the xm list
- this means that if I move the configuration file and the paused state file
to the new machine, putting them into the correct locations and put the drbd
resource into secondary mode on the originating host and then drbd into
primary on the destination host, I will them be able to issue xm create
my_DomU on the destination host and all will be fine.
>
> Also the save feature takes a lot of time to complete, since our VM
> have 32 gig of ram. So it create a 22 gig save file...
>
> I don't know why migration and even live migration need primaries.. why
> the system can't just put in secondaries for a less than a second to
> put the other host in primary to start the vm?
Migration doesn't need to have primary/primary drbd resources. If the domU
in question is paused or shutdown, you can move it between hosts without the
need. During the move the drbd resources can be in secondary/secondary mode,
as you are not actually moving the disk data, only the configuration (the
first time around or on changes to the config) and the paused state file.
If I want to do an migration between hosts of a DomU that is shutdown, I
copy the config file from the originating server to the destination server,
shutdown the domU, put the drbd resource on the originating host to
secondary, go to the destination host and put the drbd resource into primary
and then start the domU on the destination host.
For this to work without having different local domU configs, I make sure
that the drbd resource names are exactly the same on both drbd hosts and
that the /dev/drbd(minor) also match.
During the live migration you need to have the drbd resources in
primary/primary only whilst the migration is taking place. This I would
assume is so that when you issue the command to migrate the domain, the
resources are checked on the other side and if they are not ready (which
would be the case when the drbd resource is in secondary mode), then the
migration would not take place. Without the resource being primary there is
no way for the originating host to determine that all will be well when it
switches over to the destination host. I understand your concerns regarding
dual primaries, I too have them, but I think that they can be overcome with
understanding and if needed some small scripting of the migration process.
Of course, this presumes that you have a drbd resource per DomU and that the
drbd resource are not shared between different domU's (migration of a domU
is considered to be the same domU).
Rgds
Simon
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home