Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Miguel Clara]

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?

Thanks

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Ian Campbell]

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.

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Mike C.]

[-- Attachment #1.1: Type: text/plain, Size: 1750 bytes --]

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@citrix.com> 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.

[-- Attachment #1.2: Type: text/html, Size: 2301 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Miguel Clara]

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?

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?

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@gmail.com> 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@citrix.com>
> 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.

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Ian Campbell]

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@gmail.com> 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@citrix.com>
> > 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.

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Mike C.]

On February 4, 2014 11:33:42 AM GMT, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>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.
>

And would xl remus work if the disks are drdb 'backend' which in turn point to LVM?

Thanks

>> 
>> 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@gmail.com>
>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@citrix.com>
>> > 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.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Ian Campbell]

On Tue, 2014-02-04 at 15:32 +0000, Mike C. wrote:
> 
> On February 4, 2014 11:33:42 AM GMT, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >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.
> >
> 
> And would xl remus work if the disks are drdb 'backend' which in turn point to LVM?

I don't know, CCing Shriram the maintainer.

> 
> Thanks
> 
> >> 
> >> 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@gmail.com>
> >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@citrix.com>
> >> > 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.
> 

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Shriram Rajagopalan]

[-- Attachment #1.1: Type: text/plain, Size: 1008 bytes --]

On Tue, Feb 4, 2014 at 7:35 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

>
> > >> 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!
> > >>
>

If you just need to migrate an entire VM (memory & disk)  from one host to
another,
without using shared storage, then there are several alternatives.
One way is to use DRBD based disk backends (yes they can run on top of a
LVM)
and use protocol C (synchronous disk replication) to keep the disks at both
hosts synchronized.

Since the disk is always synchronized, you can just use the xl migrate
command to migrate
the memory state from one host to another, with very little downtime.

I would suggest reading up on the DRBD documentation regarding xen live
migration. IIRC,
their current example is based on xend, but it applies equally well to xl,
as xl also supports drbd based
disk backends.

shriram

[-- Attachment #1.2: Type: text/html, Size: 1549 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Miguel Clara]

Thanks both for the feedback, I will test xl migrate/remus with DRDB
and post back!

As for offline migration I tried xl save + simple scp seems to do the
trick, which works for none shared storage migration as long has the
domain is stopped (which is what save does already).


On Tue, Feb 4, 2014 at 7:19 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote:
> On Tue, Feb 4, 2014 at 7:35 AM, Ian Campbell <Ian.Campbell@citrix.com>
> wrote:
>>
>>
>> > >> 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!
>> > >>
>
>
> If you just need to migrate an entire VM (memory & disk)  from one host to
> another,
> without using shared storage, then there are several alternatives.
> One way is to use DRBD based disk backends (yes they can run on top of a
> LVM)
> and use protocol C (synchronous disk replication) to keep the disks at both
> hosts synchronized.
>
> Since the disk is always synchronized, you can just use the xl migrate
> command to migrate
> the memory state from one host to another, with very little downtime.
>
> I would suggest reading up on the DRBD documentation regarding xen live
> migration. IIRC,
> their current example is based on xend, but it applies equally well to xl,
> as xl also supports drbd based
> disk backends.
>
> shriram

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Miguel Clara]

I noticed /etc/xen/scripts doesn't include the 'block-drbd' script,
does this come with xen or the drbd package?

Xen 4.3.1 was compiled from source, but drdb is installed from apt-get
on debian (v 8.3)

Thanks

On Tue, Feb 4, 2014 at 8:26 PM, Miguel Clara <miguelmclara@gmail.com> wrote:
> Thanks both for the feedback, I will test xl migrate/remus with DRDB
> and post back!
>
> As for offline migration I tried xl save + simple scp seems to do the
> trick, which works for none shared storage migration as long has the
> domain is stopped (which is what save does already).
>
>
> On Tue, Feb 4, 2014 at 7:19 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote:
>> On Tue, Feb 4, 2014 at 7:35 AM, Ian Campbell <Ian.Campbell@citrix.com>
>> wrote:
>>>
>>>
>>> > >> 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!
>>> > >>
>>
>>
>> If you just need to migrate an entire VM (memory & disk)  from one host to
>> another,
>> without using shared storage, then there are several alternatives.
>> One way is to use DRBD based disk backends (yes they can run on top of a
>> LVM)
>> and use protocol C (synchronous disk replication) to keep the disks at both
>> hosts synchronized.
>>
>> Since the disk is always synchronized, you can just use the xl migrate
>> command to migrate
>> the memory state from one host to another, with very little downtime.
>>
>> I would suggest reading up on the DRBD documentation regarding xen live
>> migration. IIRC,
>> their current example is based on xend, but it applies equally well to xl,
>> as xl also supports drbd based
>> disk backends.
>>
>> shriram

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Shriram Rajagopalan]

[-- Attachment #1.1: Type: text/plain, Size: 331 bytes --]

On Tue, Feb 4, 2014 at 2:00 PM, Miguel Clara <miguelmclara@gmail.com> wrote:

> I noticed /etc/xen/scripts doesn't include the 'block-drbd' script,
> does this come with xen or the drbd package?
>
> Xen 4.3.1 was compiled from source, but drdb is installed from apt-get
> on debian (v 8.3)
>
>
It comes with the drbd package AFAIK

[-- Attachment #1.2: Type: text/html, Size: 686 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Miguel Clara]

dpkg-query -L drbd8-utils |grep block
/etc/xen/scripts/block-drbd



Seems true, but its not there... Re-installed, same thing! Weird, I'll
have to report it in drbd-user@lists.linbit.com.

On Tue, Feb 4, 2014 at 10:02 PM, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote:
> On Tue, Feb 4, 2014 at 2:00 PM, Miguel Clara <miguelmclara@gmail.com> wrote:
>>
>> I noticed /etc/xen/scripts doesn't include the 'block-drbd' script,
>> does this come with xen or the drbd package?
>>
>> Xen 4.3.1 was compiled from source, but drdb is installed from apt-get
>> on debian (v 8.3)
>>
>
> It comes with the drbd package AFAIK
>

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Mike C.]

[-- Attachment #1.1: Type: text/plain, Size: 774 bytes --]

Fixed this but it seems using drbd: in rhe disk config doesnt work with pygrub....

does this makes sense?

I found na old bug reporta but this is Debain squeze Xen 4.3

I seems to work fine booting into the installer bit if ibuse pygrub It doesnt find the drbd device.



On February 4, 2014 10:02:52 PM GMT, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote:
>On Tue, Feb 4, 2014 at 2:00 PM, Miguel Clara <miguelmclara@gmail.com>
>wrote:
>
>> I noticed /etc/xen/scripts doesn't include the 'block-drbd' script,
>> does this come with xen or the drbd package?
>>
>> Xen 4.3.1 was compiled from source, but drdb is installed from
>apt-get
>> on debian (v 8.3)
>>
>>
>It comes with the drbd package AFAIK

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #1.2: Type: text/html, Size: 1399 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Miguel Clara]

Sorry forgot to add the error:

# xl create test.cfg
Parsing config from test.cfg
libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader
failed - consult logfile /var/log/xen/bootloader.34.log
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
bootloader [10762] exited with error status 1
libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot
(re-)build domain: -3

# cat /var/log/xen/bootloader.34.log
Traceback (most recent call last):
  File "/usr/local/lib/xen/bin/pygrub", line 844, in <module>
    part_offs = get_partition_offsets(file)
  File "/usr/local/lib/xen/bin/pygrub", line 105, in get_partition_offsets
    image_type = identify_disk_image(file)
  File "/usr/local/lib/xen/bin/pygrub", line 47, in identify_disk_image
    fd = os.open(file, os.O_RDONLY)
OSError: [Errno 2] No such file or directory: 'drbd-remus-test'

On Wed, Feb 5, 2014 at 3:20 AM, Mike C. <miguelmclara@gmail.com> wrote:
> Fixed this but it seems using drbd: in rhe disk config doesnt work with
> pygrub....
>
> does this makes sense?
>
> I found na old bug reporta but this is Debain squeze Xen 4.3
>
> I seems to work fine booting into the installer bit if ibuse pygrub It
> doesnt find the drbd device.
>
>
>
>
> On February 4, 2014 10:02:52 PM GMT, Shriram Rajagopalan
> <rshriram@cs.ubc.ca> wrote:
>>
>> On Tue, Feb 4, 2014 at 2:00 PM, Miguel Clara <miguelmclara@gmail.com>
>> wrote:
>>>
>>> I noticed /etc/xen/scripts doesn't include the 'block-drbd' script,
>>> does this come with xen or the drbd package?
>>>
>>> Xen 4.3.1 was compiled from source, but drdb is installed from apt-get
>>> on debian (v 8.3)
>>>
>>
>> It comes with the drbd package AFAIK
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Ian Campbell]

On Thu, 2014-02-06 at 03:37 +0000, Miguel Clara wrote:
> Sorry forgot to add the error:
> 
> # xl create test.cfg
> Parsing config from test.cfg
> libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader
> failed - consult logfile /var/log/xen/bootloader.34.log
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
> bootloader [10762] exited with error status 1
> libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot
> (re-)build domain: -3
> 
> # cat /var/log/xen/bootloader.34.log
> Traceback (most recent call last):
>   File "/usr/local/lib/xen/bin/pygrub", line 844, in <module>
>     part_offs = get_partition_offsets(file)
>   File "/usr/local/lib/xen/bin/pygrub", line 105, in get_partition_offsets
>     image_type = identify_disk_image(file)
>   File "/usr/local/lib/xen/bin/pygrub", line 47, in identify_disk_image
>     fd = os.open(file, os.O_RDONLY)
> OSError: [Errno 2] No such file or directory: 'drbd-remus-test'

You haven't shared your cfg file but this sounds to me like something is
missing the necessary absolute path.

> 
> On Wed, Feb 5, 2014 at 3:20 AM, Mike C. <miguelmclara@gmail.com> wrote:
> > Fixed this but it seems using drbd: in rhe disk config doesnt work with
> > pygrub....
> >
> > does this makes sense?
> >
> > I found na old bug reporta but this is Debain squeze Xen 4.3
> >
> > I seems to work fine booting into the installer bit if ibuse pygrub It
> > doesnt find the drbd device.
> >
> >
> >
> >
> > On February 4, 2014 10:02:52 PM GMT, Shriram Rajagopalan
> > <rshriram@cs.ubc.ca> wrote:
> >>
> >> On Tue, Feb 4, 2014 at 2:00 PM, Miguel Clara <miguelmclara@gmail.com>
> >> wrote:
> >>>
> >>> I noticed /etc/xen/scripts doesn't include the 'block-drbd' script,
> >>> does this come with xen or the drbd package?
> >>>
> >>> Xen 4.3.1 was compiled from source, but drdb is installed from apt-get
> >>> on debian (v 8.3)
> >>>
> >>
> >> It comes with the drbd package AFAIK
> >>
> >
> > --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Miguel Clara]

http://www.drbd.org/users-guide/s-xen-configure-domu.html suggests we
need disk = [ 'drbd:ressouce-name,xvda,w' ] not a full path...

this is my config:

# Comment this out if uncommenting the next section (installing)
bootloader="pygrub"

#kernel = "/var/lib/xen/images/ubuntu-netboot/vmlinuz"
#ramdisk = "/var/lib/xen/images/ubuntu-netboot/initrd.gz"

extra = 'console=hvc0 xencons=tty'

### Cpu & RAM ##
vcpus = 2
memory = 1024

# Disk device(s). ###
root = '/dev/xvda1 rw'
disk = [
        'drbd:drbd-remus-test,xvda,w'
]

### Hostname ###
name = 'remus-test'


### Networking ###
vif = [ 'bridge=xenbr0' ]


#
# Behaviour
#
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'


If I use kernel/ramdisk files instead of pygrub it works, with he same
disk syntax!

Thanks

On Thu, Feb 6, 2014 at 10:03 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2014-02-06 at 03:37 +0000, Miguel Clara wrote:
>> Sorry forgot to add the error:
>>
>> # xl create test.cfg
>> Parsing config from test.cfg
>> libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader
>> failed - consult logfile /var/log/xen/bootloader.34.log
>> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
>> bootloader [10762] exited with error status 1
>> libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot
>> (re-)build domain: -3
>>
>> # cat /var/log/xen/bootloader.34.log
>> Traceback (most recent call last):
>>   File "/usr/local/lib/xen/bin/pygrub", line 844, in <module>
>>     part_offs = get_partition_offsets(file)
>>   File "/usr/local/lib/xen/bin/pygrub", line 105, in get_partition_offsets
>>     image_type = identify_disk_image(file)
>>   File "/usr/local/lib/xen/bin/pygrub", line 47, in identify_disk_image
>>     fd = os.open(file, os.O_RDONLY)
>> OSError: [Errno 2] No such file or directory: 'drbd-remus-test'
>
> You haven't shared your cfg file but this sounds to me like something is
> missing the necessary absolute path.
>
>>
>> On Wed, Feb 5, 2014 at 3:20 AM, Mike C. <miguelmclara@gmail.com> wrote:
>> > Fixed this but it seems using drbd: in rhe disk config doesnt work with
>> > pygrub....
>> >
>> > does this makes sense?
>> >
>> > I found na old bug reporta but this is Debain squeze Xen 4.3
>> >
>> > I seems to work fine booting into the installer bit if ibuse pygrub It
>> > doesnt find the drbd device.
>> >
>> >
>> >
>> >
>> > On February 4, 2014 10:02:52 PM GMT, Shriram Rajagopalan
>> > <rshriram@cs.ubc.ca> wrote:
>> >>
>> >> On Tue, Feb 4, 2014 at 2:00 PM, Miguel Clara <miguelmclara@gmail.com>
>> >> wrote:
>> >>>
>> >>> I noticed /etc/xen/scripts doesn't include the 'block-drbd' script,
>> >>> does this come with xen or the drbd package?
>> >>>
>> >>> Xen 4.3.1 was compiled from source, but drdb is installed from apt-get
>> >>> on debian (v 8.3)
>> >>>
>> >>
>> >> It comes with the drbd package AFAIK
>> >>
>> >
>> > --
>> > Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Ian Campbell]

On Thu, 2014-02-06 at 16:03 +0000, Miguel Clara wrote:
> 
> If I use kernel/ramdisk files instead of pygrub it works, with he same
> disk syntax! 

Ah, I suspect that something isn't realising that drbd:ressouce-name
isn't a local disk name and so tries to get pygrub to run on it
directly, instead of creating a loopback xvd to use.

Some of this has been improved since 4.3, but an "xl -vvv create ..."
might shed some light on exactly what is going wrong.

Ian.

Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host

[Miguel Clara]

Parsing config from test.cfg
libxl: debug: libxl_create.c:1230:do_domain_create: ao 0x9a9f30:
create: how=(nil) callback=(nil) poller=0x9a9f90
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=xvda spec.backend=unknown
libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=xvda,
uses script=... assuming phy backend
libxl: debug: libxl_device.c:296:libxl__device_disk_set_backend: Disk
vdev=xvda, using backend phy
libxl: debug: libxl_create.c:675:initiate_domain_create: running bootloader
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=(null) spec.backend=phy
libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=(null),
uses script=... assuming phy backend
libxl: debug: libxl.c:2604:libxl__device_disk_local_initiate_attach:
locally attaching PHY disk drbd-remus-test
libxl: debug: libxl_bootloader.c:409:bootloader_disk_attached_cb:
Config bootloader value: pygrub
libxl: debug: libxl_bootloader.c:425:bootloader_disk_attached_cb:
Checking for bootloader in libexec path: /usr/local/lib/xen/bin/pygrub
libxl: debug: libxl_create.c:1243:do_domain_create: ao 0x9a9f30:
inprogress: poller=0x9a9f90, flags=i
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=0x9aa3c8 wpath=/local/domain/35 token=3/0: register slotnum=3
libxl: debug: libxl_event.c:1737:libxl__ao_progress_report: ao
0x9a9f30: progress report: ignored
libxl: debug: libxl_bootloader.c:535:bootloader_gotptys: executing
bootloader: /usr/local/lib/xen/bin/pygrub
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader
arg: /usr/local/lib/xen/bin/pygrub
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader
arg: --args=root=/dev/xvda1 rw console=hvc0 xencons=tty
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader
arg: --output=/var/run/xen/bootloader.35.out
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader
arg: --output-format=simple0
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader
arg: --output-directory=/var/run/xen/bootloader.35.d
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader
arg: drbd-remus-test
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x9aa3c8
wpath=/local/domain/35 token=3/0: event epath=/local/domain/35
libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader
failed - consult logfile /var/log/xen/bootloader.35.log
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:
bootloader [12781] exited with error status 1
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=0x9aa3c8 wpath=/local/domain/35 token=3/0: deregister slotnum=3
libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot
(re-)build domain: -3
libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x9a9f30:
complete, rc=-3
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x9a9f30: destroy
xc: debug: hypercall buffer: total allocations:20 total releases:20
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:16 misses:2 toobig:2


This part:
libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader
arg: drbd-remus-test

Does seem weird...

On Mon, Feb 10, 2014 at 2:23 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2014-02-06 at 16:03 +0000, Miguel Clara wrote:
>>
>> If I use kernel/ramdisk files instead of pygrub it works, with he same
>> disk syntax!
>
> Ah, I suspect that something isn't realising that drbd:ressouce-name
> isn't a local disk name and so tries to get pygrub to run on it
> directly, instead of creating a loopback xvd to use.
>
> Some of this has been improved since 4.3, but an "xl -vvv create ..."
> might shed some light on exactly what is going wrong.
>
> Ian.
>
>

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Ian Campbell]

Please could you not top post.

On Wed, 2014-02-12 at 02:48 +0000, Miguel Clara wrote:
> Parsing config from test.cfg
> libxl: debug: libxl_create.c:1230:do_domain_create: ao 0x9a9f30: create: how=(nil) callback=(nil) poller=0x9a9f90
> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=unknown
> libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=xvda, uses script=... assuming phy backend
> libxl: debug: libxl_device.c:296:libxl__device_disk_set_backend: Disk vdev=xvda, using backend phy
> libxl: debug: libxl_create.c:675:initiate_domain_create: running bootloader
> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk vdev=(null) spec.backend=phy
> libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=(null), uses script=... assuming phy backend
> libxl: debug: libxl.c:2604:libxl__device_disk_local_initiate_attach: locally attaching PHY disk drbd-remus-test
> libxl: debug: libxl_bootloader.c:409:bootloader_disk_attached_cb: Config bootloader value: pygrub
> libxl: debug: libxl_bootloader.c:425:bootloader_disk_attached_cb: Checking for bootloader in libexec path: /usr/local/lib/xen/bin/pygrub
> libxl: debug: libxl_create.c:1243:do_domain_create: ao 0x9a9f30: inprogress: poller=0x9a9f90, flags=i
> libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x9aa3c8 wpath=/local/domain/35 token=3/0: register slotnum=3
> libxl: debug: libxl_event.c:1737:libxl__ao_progress_report: ao 0x9a9f30: progress report: ignored
> libxl: debug: libxl_bootloader.c:535:bootloader_gotptys: executing bootloader: /usr/local/lib/xen/bin/pygrub
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: /usr/local/lib/xen/bin/pygrub
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --args=root=/dev/xvda1 rw console=hvc0 xencons=tty
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --output=/var/run/xen/bootloader.35.out
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --output-format=simple0
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --output-directory=/var/run/xen/bootloader.35.d
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: drbd-remus-test
> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x9aa3c8 wpath=/local/domain/35 token=3/0: event epath=/local/domain/35
> libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader failed - consult logfile /var/log/xen/bootloader.35.log
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: bootloader [12781] exited with error status 1
> libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch w=0x9aa3c8 wpath=/local/domain/35 token=3/0: deregister slotnum=3
> libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot (re-)build domain: -3
> libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x9a9f30: complete, rc=-3
> libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x9a9f30: destroy
> xc: debug: hypercall buffer: total allocations:20 total releases:20
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:16 misses:2 toobig:2
> 
> 
> This part:
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: drbd-remus-test
> 
> Does seem weird...

Indeed, especially when there is a preceding
libxl: debug: libxl.c:2604:libxl__device_disk_local_initiate_attach: locally attaching PHY disk drbd-remus-test
which should have resulted in an xvda device to use.

Hrm, that function handles phy devices as a straight passthrough of the
underlying device, which is the source of the error.

I wonder if we should add some special handling of disk devices which
have a non-null script. I guess that would look something like the QDISK
bit of libxl__device_disk_local_initiate_attach but gated on
disk->script rather than ->format. i.e.:
        case LIBXL_DISK_BACKEND_PHY:
                if (disk->script) {
                libxl__prepare_ao_device(ao, &dls->aodev);
                dls->aodev.callback = local_device_attach_cb;
                device_disk_add(egc, LIBXL_TOOLSTACK_DOMID, disk,
                                &dls->aodev, libxl__alloc_vdev,
                                (void *) blkdev_start);
                return;
            } else {
                dev = disk->pdev_path;
            }

Would also need some code in libxl__device_disk_local_initiate_detach.
Ian.

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Roger Pau Monné]

On 12/02/14 10:56, Ian Campbell wrote:
> Please could you not top post.
> 
> On Wed, 2014-02-12 at 02:48 +0000, Miguel Clara wrote:
>> Parsing config from test.cfg
>> libxl: debug: libxl_create.c:1230:do_domain_create: ao 0x9a9f30: create: how=(nil) callback=(nil) poller=0x9a9f90
>> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=unknown
>> libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=xvda, uses script=... assuming phy backend
>> libxl: debug: libxl_device.c:296:libxl__device_disk_set_backend: Disk vdev=xvda, using backend phy
>> libxl: debug: libxl_create.c:675:initiate_domain_create: running bootloader
>> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk vdev=(null) spec.backend=phy
>> libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=(null), uses script=... assuming phy backend
>> libxl: debug: libxl.c:2604:libxl__device_disk_local_initiate_attach: locally attaching PHY disk drbd-remus-test
>> libxl: debug: libxl_bootloader.c:409:bootloader_disk_attached_cb: Config bootloader value: pygrub
>> libxl: debug: libxl_bootloader.c:425:bootloader_disk_attached_cb: Checking for bootloader in libexec path: /usr/local/lib/xen/bin/pygrub
>> libxl: debug: libxl_create.c:1243:do_domain_create: ao 0x9a9f30: inprogress: poller=0x9a9f90, flags=i
>> libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x9aa3c8 wpath=/local/domain/35 token=3/0: register slotnum=3
>> libxl: debug: libxl_event.c:1737:libxl__ao_progress_report: ao 0x9a9f30: progress report: ignored
>> libxl: debug: libxl_bootloader.c:535:bootloader_gotptys: executing bootloader: /usr/local/lib/xen/bin/pygrub
>> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: /usr/local/lib/xen/bin/pygrub
>> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --args=root=/dev/xvda1 rw console=hvc0 xencons=tty
>> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --output=/var/run/xen/bootloader.35.out
>> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --output-format=simple0
>> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: --output-directory=/var/run/xen/bootloader.35.d
>> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: drbd-remus-test
>> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x9aa3c8 wpath=/local/domain/35 token=3/0: event epath=/local/domain/35
>> libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader failed - consult logfile /var/log/xen/bootloader.35.log
>> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: bootloader [12781] exited with error status 1
>> libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch w=0x9aa3c8 wpath=/local/domain/35 token=3/0: deregister slotnum=3
>> libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot (re-)build domain: -3
>> libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x9a9f30: complete, rc=-3
>> libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x9a9f30: destroy
>> xc: debug: hypercall buffer: total allocations:20 total releases:20
>> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
>> xc: debug: hypercall buffer: cache current size:2
>> xc: debug: hypercall buffer: cache hits:16 misses:2 toobig:2
>>
>>
>> This part:
>> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: drbd-remus-test
>>
>> Does seem weird...
> 
> Indeed, especially when there is a preceding
> libxl: debug: libxl.c:2604:libxl__device_disk_local_initiate_attach: locally attaching PHY disk drbd-remus-test
> which should have resulted in an xvda device to use.
> 
> Hrm, that function handles phy devices as a straight passthrough of the
> underlying device, which is the source of the error.
> 
> I wonder if we should add some special handling of disk devices which
> have a non-null script. I guess that would look something like the QDISK
> bit of libxl__device_disk_local_initiate_attach but gated on
> disk->script rather than ->format. i.e.:
>         case LIBXL_DISK_BACKEND_PHY:
>                 if (disk->script) {
>                 libxl__prepare_ao_device(ao, &dls->aodev);
>                 dls->aodev.callback = local_device_attach_cb;
>                 device_disk_add(egc, LIBXL_TOOLSTACK_DOMID, disk,
>                                 &dls->aodev, libxl__alloc_vdev,
>                                 (void *) blkdev_start);
>                 return;
>             } else {
>                 dev = disk->pdev_path;
>             }
> 
> Would also need some code in libxl__device_disk_local_initiate_detach.
> Ian.

I though this was already working on libxl... Could you please test the 
attached patch? Which is basically the chunk Ian posted above plus the 
libxl__device_disk_local_initiate_detach part.

---
commit 3bcf91cbbd9a18db9ae7d594ffde7979774ed512
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Wed Feb 12 11:15:17 2014 +0100

    libxl: local attach support for PHY backends using scripts
    
    Allow disks using the PHY backend to locally attach if using a script.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Suggested-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 730f6e1..5cb46a1 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2630,6 +2630,16 @@ void libxl__device_disk_local_initiate_attach(libxl__egc *egc,
 
     switch (disk->backend) {
         case LIBXL_DISK_BACKEND_PHY:
+            if (disk->script != NULL) {
+                LOG(DEBUG, "trying to locally attach PHY device %s with script %s",
+                           disk->pdev_path, disk->script);
+                libxl__prepare_ao_device(ao, &dls->aodev);
+                dls->aodev.callback = local_device_attach_cb;
+                device_disk_add(egc, LIBXL_TOOLSTACK_DOMID, disk,
+                                &dls->aodev, libxl__alloc_vdev,
+                                (void *) blkdev_start);
+                return;
+            }
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
                        disk->pdev_path);
             dev = disk->pdev_path;
@@ -2709,7 +2719,7 @@ static void local_device_attach_cb(libxl__egc *egc, libxl__ao_device *aodev)
     }
 
     dev = GCSPRINTF("/dev/%s", disk->vdev);
-    LOG(DEBUG, "locally attaching qdisk %s", dev);
+    LOG(DEBUG, "locally attached disk %s", dev);
 
     rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &device);
     if (rc < 0)
@@ -2749,6 +2759,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc *egc,
     if (!dls->diskpath) goto out;
 
     switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
         case LIBXL_DISK_BACKEND_QDISK:
             if (disk->vdev != NULL) {
                 GCNEW(device);
@@ -2766,7 +2777,6 @@ void libxl__device_disk_local_initiate_detach(libxl__egc *egc,
             /* disk->vdev == NULL; fall through */
         default:
             /*
-             * Nothing to do for PHYSTYPE_PHY.
              * For other device types assume that the blktap2 process is
              * needed by the soon to be started domain and do nothing.
              */





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

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Miguel Clara]

I tried the patch provided by roger, I get a different error now:

Parsing config from test.cfg
libxl: error: libxl_device.c:1127:libxl__wait_for_backend: Backend
/local/domain/0/backend/vbd/0/51712 not ready
libxl: error: libxl_bootloader.c:405:bootloader_disk_attached_cb:
failed to attach local disk for bootloader execution
libxl: error: libxl_bootloader.c:276:bootloader_local_detached_cb:
unable to detach locally attached disk
libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot
(re-)build domain: -1


with -vvv

# xl -vvv create test.cfg
Parsing config from test.cfg
libxl: debug: libxl_create.c:1230:do_domain_create: ao 0x12548c0:
create: how=(nil) callback=(nil) poller=0x1254980
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=xvda spec.backend=unknown
libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=xvda,
uses script=... assuming phy backend
libxl: debug: libxl_device.c:296:libxl__device_disk_set_backend: Disk
vdev=xvda, using backend phy
libxl: debug: libxl_create.c:675:initiate_domain_create: running bootloader
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=(null) spec.backend=phy
libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=(null),
uses script=... assuming phy backend
libxl: debug: libxl.c:2605:libxl__device_disk_local_initiate_attach:
trying to locally attach PHY device drbd-remus-test with script
block-drbd
libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
vdev=xvdf spec.backend=phy
libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=xvdf,
uses script=... assuming phy backend
libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
w=0x124a300 wpath=/local/domain/0/backend/vbd/0/51792/state token=3/0:
register slotnum=3
libxl: debug: libxl_create.c:1243:do_domain_create: ao 0x12548c0:
inprogress: poller=0x1254980, flags=i
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x124a300
wpath=/local/domain/0/backend/vbd/0/51792/state token=3/0: event
epath=/local/domain/0/backend/vbd/0/51792/state
libxl: debug: libxl_event.c:647:devstate_watch_callback: backend
/local/domain/0/backend/vbd/0/51792/state wanted state 2 still waiting
state 1
libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x124a300
wpath=/local/domain/0/backend/vbd/0/51792/state token=3/0: event
epath=/local/domain/0/backend/vbd/0/51792/state
libxl: debug: libxl_event.c:643:devstate_watch_callback: backend
/local/domain/0/backend/vbd/0/51792/state wanted state 2 ok
libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
w=0x124a300 wpath=/local/domain/0/backend/vbd/0/51792/state token=3/0:
deregister slotnum=3
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=0x124a300: deregister unregistered
libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug
script: /etc/xen/scripts/block-drbd add
libxl: debug: libxl.c:2692:local_device_attach_cb: locally attached
disk /dev/xvdf
libxl: error: libxl_device.c:1127:libxl__wait_for_backend: Backend
/local/domain/0/backend/vbd/0/51792 not ready
libxl: error: libxl_bootloader.c:405:bootloader_disk_attached_cb:
failed to attach local disk for bootloader execution
libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
w=0x124a498: deregister unregistered
libxl: error: libxl_bootloader.c:276:bootloader_local_detached_cb:
unable to detach locally attached disk
libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot
(re-)build domain: -1
libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x12548c0:
complete, rc=-3
libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x12548c0: destroy
xc: debug: hypercall buffer: total allocations:31 total releases:31
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:27 misses:2 toobig:2

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Roger Pau Monné]

On 13/02/14 02:29, Miguel Clara wrote:
> I tried the patch provided by roger, I get a different error now:
> 
> Parsing config from test.cfg
> libxl: error: libxl_device.c:1127:libxl__wait_for_backend: Backend
> /local/domain/0/backend/vbd/0/51712 not ready
> libxl: error: libxl_bootloader.c:405:bootloader_disk_attached_cb:
> failed to attach local disk for bootloader execution
> libxl: error: libxl_bootloader.c:276:bootloader_local_detached_cb:
> unable to detach locally attached disk
> libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot
> (re-)build domain: -1
> 
> 
> with -vvv
> 
> # xl -vvv create test.cfg
> Parsing config from test.cfg
> libxl: debug: libxl_create.c:1230:do_domain_create: ao 0x12548c0:
> create: how=(nil) callback=(nil) poller=0x1254980
> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
> vdev=xvda spec.backend=unknown
> libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=xvda,
> uses script=... assuming phy backend
> libxl: debug: libxl_device.c:296:libxl__device_disk_set_backend: Disk
> vdev=xvda, using backend phy
> libxl: debug: libxl_create.c:675:initiate_domain_create: running bootloader
> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
> vdev=(null) spec.backend=phy
> libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=(null),
> uses script=... assuming phy backend
> libxl: debug: libxl.c:2605:libxl__device_disk_local_initiate_attach:
> trying to locally attach PHY device drbd-remus-test with script
> block-drbd
> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
> vdev=xvdf spec.backend=phy
> libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=xvdf,
> uses script=... assuming phy backend
> libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
> w=0x124a300 wpath=/local/domain/0/backend/vbd/0/51792/state token=3/0:
> register slotnum=3
> libxl: debug: libxl_create.c:1243:do_domain_create: ao 0x12548c0:
> inprogress: poller=0x1254980, flags=i
> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x124a300
> wpath=/local/domain/0/backend/vbd/0/51792/state token=3/0: event
> epath=/local/domain/0/backend/vbd/0/51792/state
> libxl: debug: libxl_event.c:647:devstate_watch_callback: backend
> /local/domain/0/backend/vbd/0/51792/state wanted state 2 still waiting
> state 1
> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x124a300
> wpath=/local/domain/0/backend/vbd/0/51792/state token=3/0: event
> epath=/local/domain/0/backend/vbd/0/51792/state
> libxl: debug: libxl_event.c:643:devstate_watch_callback: backend
> /local/domain/0/backend/vbd/0/51792/state wanted state 2 ok
> libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
> w=0x124a300 wpath=/local/domain/0/backend/vbd/0/51792/state token=3/0:
> deregister slotnum=3
> libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
> w=0x124a300: deregister unregistered
> libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug
> script: /etc/xen/scripts/block-drbd add
> libxl: debug: libxl.c:2692:local_device_attach_cb: locally attached
> disk /dev/xvdf
> libxl: error: libxl_device.c:1127:libxl__wait_for_backend: Backend
> /local/domain/0/backend/vbd/0/51792 not ready

So the local attach seems to DTRT, but the device never gets to state 4
(connected). Does the block-drbd script work with guests that are not
using pygrub? (extract the kernel from the DomU and use it directly on
the config file).

Roger.

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Roger Pau Monné]

On 13/02/14 09:17, Roger Pau Monné wrote:
> On 13/02/14 02:29, Miguel Clara wrote:
>> I tried the patch provided by roger, I get a different error now:
>>
>> Parsing config from test.cfg
>> libxl: error: libxl_device.c:1127:libxl__wait_for_backend: Backend
>> /local/domain/0/backend/vbd/0/51712 not ready
>> libxl: error: libxl_bootloader.c:405:bootloader_disk_attached_cb:
>> failed to attach local disk for bootloader execution
>> libxl: error: libxl_bootloader.c:276:bootloader_local_detached_cb:
>> unable to detach locally attached disk
>> libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot
>> (re-)build domain: -1
>>
>>
>> with -vvv
>>
>> # xl -vvv create test.cfg
>> Parsing config from test.cfg
>> libxl: debug: libxl_create.c:1230:do_domain_create: ao 0x12548c0:
>> create: how=(nil) callback=(nil) poller=0x1254980
>> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
>> vdev=xvda spec.backend=unknown
>> libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=xvda,
>> uses script=... assuming phy backend
>> libxl: debug: libxl_device.c:296:libxl__device_disk_set_backend: Disk
>> vdev=xvda, using backend phy
>> libxl: debug: libxl_create.c:675:initiate_domain_create: running bootloader
>> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
>> vdev=(null) spec.backend=phy
>> libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=(null),
>> uses script=... assuming phy backend
>> libxl: debug: libxl.c:2605:libxl__device_disk_local_initiate_attach:
>> trying to locally attach PHY device drbd-remus-test with script
>> block-drbd
>> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk
>> vdev=xvdf spec.backend=phy
>> libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=xvdf,
>> uses script=... assuming phy backend
>> libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch
>> w=0x124a300 wpath=/local/domain/0/backend/vbd/0/51792/state token=3/0:
>> register slotnum=3
>> libxl: debug: libxl_create.c:1243:do_domain_create: ao 0x12548c0:
>> inprogress: poller=0x1254980, flags=i
>> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x124a300
>> wpath=/local/domain/0/backend/vbd/0/51792/state token=3/0: event
>> epath=/local/domain/0/backend/vbd/0/51792/state
>> libxl: debug: libxl_event.c:647:devstate_watch_callback: backend
>> /local/domain/0/backend/vbd/0/51792/state wanted state 2 still waiting
>> state 1
>> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x124a300
>> wpath=/local/domain/0/backend/vbd/0/51792/state token=3/0: event
>> epath=/local/domain/0/backend/vbd/0/51792/state
>> libxl: debug: libxl_event.c:643:devstate_watch_callback: backend
>> /local/domain/0/backend/vbd/0/51792/state wanted state 2 ok
>> libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch
>> w=0x124a300 wpath=/local/domain/0/backend/vbd/0/51792/state token=3/0:
>> deregister slotnum=3
>> libxl: debug: libxl_event.c:608:libxl__ev_xswatch_deregister: watch
>> w=0x124a300: deregister unregistered
>> libxl: debug: libxl_device.c:959:device_hotplug: calling hotplug
>> script: /etc/xen/scripts/block-drbd add
>> libxl: debug: libxl.c:2692:local_device_attach_cb: locally attached
>> disk /dev/xvdf
>> libxl: error: libxl_device.c:1127:libxl__wait_for_backend: Backend
>> /local/domain/0/backend/vbd/0/51792 not ready
> 
> So the local attach seems to DTRT, but the device never gets to state 4
> (connected). Does the block-drbd script work with guests that are not
> using pygrub? (extract the kernel from the DomU and use it directly on
> the config file).

I've been looking into this, and found out that the block-drbd script 
is outdated, it expects that the type node in xenstore will be "drbd" 
(which probably was what xend was setting), but libxl sets it to "phy", 
so the following patch to block-drbd is needed. If it solves your 
problems I will upstream it to drbd for inclusion on new releases.

(The patch is against git://git.drbd.org/drbd-9.0.git)

---
commit 4a4806421d81b30762ed6a0b111e491b77e78a08
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Thu Feb 13 11:01:48 2014 +0100

    block-drbd: type is "phy" for drbd backends
    
    The type written to xenstore by libxl when attaching a drbd backend is
    "phy", not "drbd", so handle this case also.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

diff --git a/scripts/block-drbd b/scripts/block-drbd
index 5563ccb..975802b 100755
--- a/scripts/block-drbd
+++ b/scripts/block-drbd
@@ -250,7 +250,7 @@ case "$command" in
     fi
 
     case $t in 
-      drbd)
+      drbd|phy)
         drbd_resource=$p
         drbd_role="$(drbdadm role $drbd_resource)"
         drbd_lrole="${drbd_role%%/*}"
@@ -278,7 +278,7 @@ case "$command" in
 
   remove)
     case $t in 
-      drbd)
+      drbd|phy)
         p=$(xenstore_read "$XENBUS_PATH/params")
         drbd_resource=$p
         drbd_role="$(drbdadm role $drbd_resource)"

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Miguel Clara]

[-- Attachment #1: Type: text/plain, Size: 180 bytes --]

After compiling with the patch and rebuilding/installing the module, I
reboot, I get a panic now when drbd starts.

That was all I could get from the JAVA supermicro  kvm console!

[-- Attachment #2: panic_drbd.jpg --]
[-- Type: image/jpeg, Size: 94839 bytes --]

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Roger Pau Monné]

On 14/02/14 03:09, Miguel Clara wrote:
> After compiling with the patch and rebuilding/installing the module, I
> reboot, I get a panic now when drbd starts.

There was no need to rebuild the module, the patch only modified the
block-drbd script. I've tested it with drbd-8.4.3 and Linux 3.13,
everything seemed to be fine (no kernel panic of course).

Since the patch didn't modify anything in the kernel module itself I
find it unlikely to cause a kernel panic, probably there's some kind of
problem with your kernel/module.

> That was all I could get from the JAVA supermicro  kvm console!

Without a proper serial console log it's impossible to tell what's going
on (at least to me).

Roger.

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Mike C.]

[-- Attachment #1.1: Type: text/plain, Size: 1385 bytes --]


I had version 8.3 only, from apt-get, not sure if only the tools changed so I decided to build the module too.

the panic only happens on service start, so it might be something with the config, probably there are changes from 8.3 to 9.... but loading the module it self doesn't cause any issue.

I'll post my config  as soon has I'm in the laptop.

Sadly I cant seem to get Supermicro to work with SOL, only iKVM, but I think I can record the console output using iKVM, I'll try this later today.

Thanks


On February 14, 2014 9:13:40 AM GMT, "Roger Pau Monné" <roger.pau@citrix.com> wrote:
>On 14/02/14 03:09, Miguel Clara wrote:
>> After compiling with the patch and rebuilding/installing the module,
>I
>> reboot, I get a panic now when drbd starts.
>
>There was no need to rebuild the module, the patch only modified the
>block-drbd script. I've tested it with drbd-8.4.3 and Linux 3.13,
>everything seemed to be fine (no kernel panic of course).
>
>Since the patch didn't modify anything in the kernel module itself I
>find it unlikely to cause a kernel panic, probably there's some kind of
>problem with your kernel/module.
>
>> That was all I could get from the JAVA supermicro  kvm console!
>
>Without a proper serial console log it's impossible to tell what's
>going
>on (at least to me).
>
>Roger.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #1.2: Type: text/html, Size: 2046 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Miguel Clara]

On Fri, Feb 14, 2014 at 9:13 AM, Roger Pau Monné <roger.pau@citrix.com> wrote:
> On 14/02/14 03:09, Miguel Clara wrote:
>> After compiling with the patch and rebuilding/installing the module, I
>> reboot, I get a panic now when drbd starts.
>
> There was no need to rebuild the module, the patch only modified the
> block-drbd script. I've tested it with drbd-8.4.3 and Linux 3.13,
> everything seemed to be fine (no kernel panic of course).

Just noticed this part now but before you said:
(The patch is against git://git.drbd.org/drbd-9.0.git)

So should I apply the patch to drbd-8.4.3... ?

>
> Since the patch didn't modify anything in the kernel module itself I
> find it unlikely to cause a kernel panic, probably there's some kind of
> problem with your kernel/module.
>
>> That was all I could get from the JAVA supermicro  kvm console!
>
> Without a proper serial console log it's impossible to tell what's going
> on (at least to me).
>
> Roger.
>

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Roger Pau Monné]

On 14/02/14 21:08, Miguel Clara wrote:
> On Fri, Feb 14, 2014 at 9:13 AM, Roger Pau Monné <roger.pau@citrix.com> wrote:
>> On 14/02/14 03:09, Miguel Clara wrote:
>>> After compiling with the patch and rebuilding/installing the module, I
>>> reboot, I get a panic now when drbd starts.
>>
>> There was no need to rebuild the module, the patch only modified the
>> block-drbd script. I've tested it with drbd-8.4.3 and Linux 3.13,
>> everything seemed to be fine (no kernel panic of course).
> 
> Just noticed this part now but before you said:
> (The patch is against git://git.drbd.org/drbd-9.0.git)
> 
> So should I apply the patch to drbd-8.4.3... ?

Yes, I think this patch will apply to almost any version of drbd since
it only modifies the block-drbd script. I would recommend that you apply
it against your already installed block-drbd script, this way you will
be sure there's no version mismatch.

Roger.

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Miguel Clara]

I see, from the previous message I assume it had to be against drbd-9,
aptget repos offer 8.3 only but 8.4 is availeble as a .deb manual
download so I'll go fro the same version has you, just to be sure its
the same thing

On Mon, Feb 17, 2014 at 8:32 AM, Roger Pau Monné <roger.pau@citrix.com> wrote:
> On 14/02/14 21:08, Miguel Clara wrote:
>> On Fri, Feb 14, 2014 at 9:13 AM, Roger Pau Monné <roger.pau@citrix.com> wrote:
>>> On 14/02/14 03:09, Miguel Clara wrote:
>>>> After compiling with the patch and rebuilding/installing the module, I
>>>> reboot, I get a panic now when drbd starts.
>>>
>>> There was no need to rebuild the module, the patch only modified the
>>> block-drbd script. I've tested it with drbd-8.4.3 and Linux 3.13,
>>> everything seemed to be fine (no kernel panic of course).
>>
>> Just noticed this part now but before you said:
>> (The patch is against git://git.drbd.org/drbd-9.0.git)
>>
>> So should I apply the patch to drbd-8.4.3... ?
>
> Yes, I think this patch will apply to almost any version of drbd since
> it only modifies the block-drbd script. I would recommend that you apply
> it against your already installed block-drbd script, this way you will
> be sure there's no version mismatch.
>
> Roger.
>

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Miguel Clara]

Actually after giving it a better tough, its probably best to keep
with the same version that comes in apt-get.

I applied the patch and just re-installed the tools!

I tried again and all seems to work fine, at least with the test Ubuntu DomU.

xl migrate also worked has expected!

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Ian Campbell]

On Wed, 2014-02-12 at 11:46 +0100, Roger Pau Monné wrote:

> I though this was already working on libxl... Could you please test the 
> attached patch? Which is basically the chunk Ian posted above plus the 
> libxl__device_disk_local_initiate_detach part.

Did this patch work?

> 
> ---
> commit 3bcf91cbbd9a18db9ae7d594ffde7979774ed512
> Author: Roger Pau Monne <roger.pau@citrix.com>
> Date:   Wed Feb 12 11:15:17 2014 +0100
> 
>     libxl: local attach support for PHY backends using scripts
>     
>     Allow disks using the PHY backend to locally attach if using a script.
>     
>     Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>     Suggested-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 730f6e1..5cb46a1 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -2630,6 +2630,16 @@ void libxl__device_disk_local_initiate_attach(libxl__egc *egc,
>  
>      switch (disk->backend) {
>          case LIBXL_DISK_BACKEND_PHY:
> +            if (disk->script != NULL) {
> +                LOG(DEBUG, "trying to locally attach PHY device %s with script %s",
> +                           disk->pdev_path, disk->script);
> +                libxl__prepare_ao_device(ao, &dls->aodev);
> +                dls->aodev.callback = local_device_attach_cb;
> +                device_disk_add(egc, LIBXL_TOOLSTACK_DOMID, disk,
> +                                &dls->aodev, libxl__alloc_vdev,
> +                                (void *) blkdev_start);
> +                return;
> +            }
>              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
>                         disk->pdev_path);
>              dev = disk->pdev_path;
> @@ -2709,7 +2719,7 @@ static void local_device_attach_cb(libxl__egc *egc, libxl__ao_device *aodev)
>      }
>  
>      dev = GCSPRINTF("/dev/%s", disk->vdev);
> -    LOG(DEBUG, "locally attaching qdisk %s", dev);
> +    LOG(DEBUG, "locally attached disk %s", dev);
>  
>      rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &device);
>      if (rc < 0)
> @@ -2749,6 +2759,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc *egc,
>      if (!dls->diskpath) goto out;
>  
>      switch (disk->backend) {
> +        case LIBXL_DISK_BACKEND_PHY:
>          case LIBXL_DISK_BACKEND_QDISK:
>              if (disk->vdev != NULL) {
>                  GCNEW(device);
> @@ -2766,7 +2777,6 @@ void libxl__device_disk_local_initiate_detach(libxl__egc *egc,
>              /* disk->vdev == NULL; fall through */
>          default:
>              /*
> -             * Nothing to do for PHYSTYPE_PHY.
>               * For other device types assume that the blktap2 process is
>               * needed by the soon to be started domain and do nothing.
>               */
> 
> 
> 
> 



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

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Ian Campbell]

On Wed, 2014-03-12 at 14:06 +0000, Ian Campbell wrote:
> On Wed, 2014-02-12 at 11:46 +0100, Roger Pau Monné wrote:
> 
> > I though this was already working on libxl... Could you please test the 
> > attached patch? Which is basically the chunk Ian posted above plus the 
> > libxl__device_disk_local_initiate_detach part.
> 
> Did this patch work?

Ping? Miguel, I think this is waiting for you to confirm that it fixes
your issue.

> > 
> > ---
> > commit 3bcf91cbbd9a18db9ae7d594ffde7979774ed512
> > Author: Roger Pau Monne <roger.pau@citrix.com>
> > Date:   Wed Feb 12 11:15:17 2014 +0100
> > 
> >     libxl: local attach support for PHY backends using scripts
> >     
> >     Allow disks using the PHY backend to locally attach if using a script.
> >     
> >     Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> >     Suggested-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index 730f6e1..5cb46a1 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -2630,6 +2630,16 @@ void libxl__device_disk_local_initiate_attach(libxl__egc *egc,
> >  
> >      switch (disk->backend) {
> >          case LIBXL_DISK_BACKEND_PHY:
> > +            if (disk->script != NULL) {
> > +                LOG(DEBUG, "trying to locally attach PHY device %s with script %s",
> > +                           disk->pdev_path, disk->script);
> > +                libxl__prepare_ao_device(ao, &dls->aodev);
> > +                dls->aodev.callback = local_device_attach_cb;
> > +                device_disk_add(egc, LIBXL_TOOLSTACK_DOMID, disk,
> > +                                &dls->aodev, libxl__alloc_vdev,
> > +                                (void *) blkdev_start);
> > +                return;
> > +            }
> >              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
> >                         disk->pdev_path);
> >              dev = disk->pdev_path;
> > @@ -2709,7 +2719,7 @@ static void local_device_attach_cb(libxl__egc *egc, libxl__ao_device *aodev)
> >      }
> >  
> >      dev = GCSPRINTF("/dev/%s", disk->vdev);
> > -    LOG(DEBUG, "locally attaching qdisk %s", dev);
> > +    LOG(DEBUG, "locally attached disk %s", dev);
> >  
> >      rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &device);
> >      if (rc < 0)
> > @@ -2749,6 +2759,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc *egc,
> >      if (!dls->diskpath) goto out;
> >  
> >      switch (disk->backend) {
> > +        case LIBXL_DISK_BACKEND_PHY:
> >          case LIBXL_DISK_BACKEND_QDISK:
> >              if (disk->vdev != NULL) {
> >                  GCNEW(device);
> > @@ -2766,7 +2777,6 @@ void libxl__device_disk_local_initiate_detach(libxl__egc *egc,
> >              /* disk->vdev == NULL; fall through */
> >          default:
> >              /*
> > -             * Nothing to do for PHYSTYPE_PHY.
> >               * For other device types assume that the blktap2 process is
> >               * needed by the soon to be started domain and do nothing.
> >               */
> > 
> > 
> > 
> > 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



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

Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Miguel Clara]

[-- Attachment #1.1: Type: text/plain, Size: 3794 bytes --]

Sorry totally forgot about this, was looking into other stuff with Xen...
need to re-check this and ping you back later... maybe tomorrow, today will
be complicated.

Thanks for the reminder.



On Wed, Apr 23, 2014 at 11:48 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Wed, 2014-03-12 at 14:06 +0000, Ian Campbell wrote:
> > On Wed, 2014-02-12 at 11:46 +0100, Roger Pau Monné wrote:
> >
> > > I though this was already working on libxl... Could you please test the
> > > attached patch? Which is basically the chunk Ian posted above plus the
> > > libxl__device_disk_local_initiate_detach part.
> >
> > Did this patch work?
>
> Ping? Miguel, I think this is waiting for you to confirm that it fixes
> your issue.
>
> > >
> > > ---
> > > commit 3bcf91cbbd9a18db9ae7d594ffde7979774ed512
> > > Author: Roger Pau Monne <roger.pau@citrix.com>
> > > Date:   Wed Feb 12 11:15:17 2014 +0100
> > >
> > >     libxl: local attach support for PHY backends using scripts
> > >
> > >     Allow disks using the PHY backend to locally attach if using a
> script.
> > >
> > >     Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > >     Suggested-by: Ian Campbell <ian.campbell@citrix.com>
> > >
> > > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > > index 730f6e1..5cb46a1 100644
> > > --- a/tools/libxl/libxl.c
> > > +++ b/tools/libxl/libxl.c
> > > @@ -2630,6 +2630,16 @@ void
> libxl__device_disk_local_initiate_attach(libxl__egc *egc,
> > >
> > >      switch (disk->backend) {
> > >          case LIBXL_DISK_BACKEND_PHY:
> > > +            if (disk->script != NULL) {
> > > +                LOG(DEBUG, "trying to locally attach PHY device %s
> with script %s",
> > > +                           disk->pdev_path, disk->script);
> > > +                libxl__prepare_ao_device(ao, &dls->aodev);
> > > +                dls->aodev.callback = local_device_attach_cb;
> > > +                device_disk_add(egc, LIBXL_TOOLSTACK_DOMID, disk,
> > > +                                &dls->aodev, libxl__alloc_vdev,
> > > +                                (void *) blkdev_start);
> > > +                return;
> > > +            }
> > >              LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY
> disk %s",
> > >                         disk->pdev_path);
> > >              dev = disk->pdev_path;
> > > @@ -2709,7 +2719,7 @@ static void local_device_attach_cb(libxl__egc
> *egc, libxl__ao_device *aodev)
> > >      }
> > >
> > >      dev = GCSPRINTF("/dev/%s", disk->vdev);
> > > -    LOG(DEBUG, "locally attaching qdisk %s", dev);
> > > +    LOG(DEBUG, "locally attached disk %s", dev);
> > >
> > >      rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk,
> &device);
> > >      if (rc < 0)
> > > @@ -2749,6 +2759,7 @@ void
> libxl__device_disk_local_initiate_detach(libxl__egc *egc,
> > >      if (!dls->diskpath) goto out;
> > >
> > >      switch (disk->backend) {
> > > +        case LIBXL_DISK_BACKEND_PHY:
> > >          case LIBXL_DISK_BACKEND_QDISK:
> > >              if (disk->vdev != NULL) {
> > >                  GCNEW(device);
> > > @@ -2766,7 +2777,6 @@ void
> libxl__device_disk_local_initiate_detach(libxl__egc *egc,
> > >              /* disk->vdev == NULL; fall through */
> > >          default:
> > >              /*
> > > -             * Nothing to do for PHYSTYPE_PHY.
> > >               * For other device types assume that the blktap2 process
> is
> > >               * needed by the soon to be started domain and do nothing.
> > >               */
> > >
> > >
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 5322 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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