Re: [Xen-users] linux stubdom

[Markus Hochholdinger <Markus@xxxxxxxxxxxxxxxxx>]

Hello,

Am 31.01.2013 um 12:22 Uhr schrieb Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
> On Wed, 2013-01-30 at 15:35 +0000, Markus Hochholdinger wrote:
> > > Not quite, when you migrate there is a pause period while the final
> > > copy over occurs and at this point you can safely remove the device
> > > from the source host and make it available on the target host. The
> > > toolstack will
> > Isn't the domU on the destination created with all its virtual devices
> > before the migration starts?
> No

oh, this opens new possibilities for me :-)


> > What if the blkback is not ready on the destination host?
> We have to arrange that it is.

OK, I see.


> >  Am I missing something?
> Migration is a staged process.
>      1. First an empty shell domain (with no devices) is created on the
>         target host.
>      2. Then we copy the memory over, in several iterations, while the
>         domain is running on the source host (iterations happen to
>         handle the guest dirtying memory as we copy, this is the "live"
>         aspect of the migration).
>      3. After some iterations of live migration we pause the source
>         guest
>      4. Now we copy the remaining dirty RAM
>      5. Tear down devices on the source host
>      6. Setup devices on the target host for the incoming domain
>      7. Resume the guest on the target domain
>      8. Guest reconnects to new backend
> The key point is that the devices are only ever active on either the
> source or the target host and never both. The domain is paused during
> this final transfer (from #3 until #7) and therefore guest I/O is
> quiesced.

At what point are scripts like
 disk = [ ".., script=myblockscript.sh" ]
executed? Would this be between #3 and #7?


> In your scenario I would expect that in the interval of #5,#6 you would
> migrate the associated driver domain.

OK.

> > > ensure that the block device is only ever active on one end of the
> > > other and never on both -- otherwise you would get potential
> > > corruption.
> > Yeah, this is the problem! If I migrate the active raid1 logic within the
> > domU (aka linux software raid1) I don't have to care. I'll try to
> > accomplish the same with a "helper" domU very near to the normal domU
> > and which is live migrated while the normal domU is migrated.
> This might be possible but as I say the more normal approach would be to
> have a "RAID" domain on both hosts and dynamically map and unmap the
> backing guest disks at steps #5 and #6 above.

With the above info, that block devices are removed and added in the right 
order while doing live migration, I'm thinking more and more about a driver 
domain.

But in the first place I'll test the stopping and assembling of md devices in 
the dom0s while migrating. If this works I could put this job into a driver 
domain. Wow, this gives me a new view of the setup.


> > > While you could migrate the driver domain during the main domU's pause
> > > period it is much more normal to simply have a driver domain on each
> > > host and dynamically configure the storage as you migrate.
> > If I dynamically create the software raid1 I have to add a lot of checks
> > which I don't need now.
> > I've already thought about a software raid1 in the dom0 and the resulting
> > md device as xvda for a domU. But I have to assemble the md device on
> > the destination host before I can deactivate the md device on the source
> > host.
> No you don't, you deactivate on the source (step #5) before activating
> on the target (step #6).

This wasn't clear to me before. Many thanks for this info.


> > The
> > race condition is, if I deactivate the md device on the source host while
> > data is only written to one of the two devices. On the destination host
> > my raid1 seems clean but my two devices differ. The other race condition
> > is, if my raid1 is inconsistent while assembling on the destination
> > host.
> I'd have thought that shutting down the raid in step #5 and reactivating
> in step #6 would guarantee that neither of these were possible.

I'll try this first of all. If this works I'll recheck the performance against 
drbd and probably try a driver domain with this.


> > > > Can I combine a driver domU to a normal domU like I can combine a
> > > > stubdom with a normal domU?
> > > If you want, it would be more typical to have a single driver domain
> > > providing block services to all domains (or one per underlying physical
> > > block device).
> > I want :-) A single driver domain would need more logic (for me) while
> > doing live migrations.
> OK, but be aware that you are treading into unexplored territory, most
> people do things the other way. This means you are likely going to have
> to do a fair bit of heavy lifting yourself.

If this solves my problem I'm willing to go into unexplored territory :-) But 
I'm also sane enough to test the common ways first.

Many thanks so far.


-- 
greetings

eMHa

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users