[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host



On Tue, 2014-02-04 at 02:45 +0000, Miguel Clara wrote:
> The wiki mentions "NBD" but if I got it right this means the storage
> is in "host1" and all ndb does is connect to that host, so the disk is
> never copied to disk 2?
> 
> Am I correct to assume this?

Yes. N is for network.

> I have a host where what I need is to move it from host1 to host2, or
> reverse if needed, there's no problem stopping it first, but I guess
> this is not what the "migrate" command is used for!
> 
> And for guest where I do wan to keep a backup with remus, is shared
> storage still a must? the wiki http://wiki.xen.org/wiki/Remus states:
> 
> -> Shared storage is not required
> 
> But if "migrate" doesn't work how would remus?

I think Remus with xend supports out of band storage synchronisation.
This has not yet been implemented for xl remus support.

> 
> Sorry for all the questions just trying to understand this better, and
> there's really no documentation about:
> xl migrate and xl remus!
> 
> thanks
> 
> On Mon, Feb 3, 2014 at 3:09 PM, Mike C. <miguelmclara@xxxxxxxxx> wrote:
> > Makes sense...
> >
> > Is there documentation about xl migrate and xl remus?
> >
> > Say I want to migrate a host but first pause it?
> >
> > I could also snapshot the lvm but that doesn't save the memory and the
> > domain would have to be offline.
> >
> > So if I want to migrate but don't have shared storage, what's the best
> > approach drdb?
> >
> > Thanks
> >
> >
> >
> > On February 3, 2014 10:17:04 AM GMT, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> > wrote:
> >>
> >> On Sat, 2014-02-01 at 01:32 +0000, Miguel Clara wrote:
> >>>
> >>>  I'm testing live migration without shared storage (I use LVM at both
> >>> sides)
> >>>
> >>>
> >>>  Issuing "xl migrate" worked nice and the machine was migrated to the
> >>> second host
> >>>
> >>>  However I see this in the second host log:
> >>>
> >>>  [ 1502.563251] EXT4-fs error (device xvda1):
> >>>  htree_dirblock_to_tree:892: inode #136303: block 533250: comm
> >>>  run-parts: bad entry in directory: rec_len is smaller than minimal -
> >>>  offset=0(0), inode=0, rec_len=0, name_len=0
> >>>  Jan 31 17:17:01 remus-test kernel: [ 1502.563251] EXT4-fs error
> >>>  (device xvda1): htree_dirblock_to_tree:892: inode #136303: block
> >>>  533250: comm run-parts: bad entry in directory: rec_len is smaller
> >>>  than minimal - offset=0(0), inode=0, rec_len=0, name_len=0
> >>>
> >>>  I also get errors
> >>> like:
> >>>  -bash: /bin/ping: cannot execute binary file
> >>>
> >>>  Is this to be expect on using none shared storage?
> >>
> >>
> >> Yes. If the underlying disk is not the same device between both hosts
> >> then all bets are off and all sorts of bad things will be happen. Think
> >> about it -- what would you expect to happen to an OS if a disk suddenly
> >> started returning completely different data to what was written to it.
> >>
> >> What you have seen seems like a plausible outcome.
> >>
> >> Ian.
> >>
> >
> > --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.