* Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host @ 2014-02-01 1:32 Miguel Clara 2014-02-03 10:17 ` Ian Campbell 0 siblings, 1 reply; 33+ messages in thread From: Miguel Clara @ 2014-02-01 1:32 UTC (permalink / raw) To: xen-devel 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-01 1:32 Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host Miguel Clara @ 2014-02-03 10:17 ` Ian Campbell 2014-02-03 15:09 ` Mike C. 0 siblings, 1 reply; 33+ messages in thread From: Ian Campbell @ 2014-02-03 10:17 UTC (permalink / raw) To: Miguel Clara; +Cc: xen-devel 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-03 10:17 ` Ian Campbell @ 2014-02-03 15:09 ` Mike C. 2014-02-04 2:45 ` Miguel Clara 0 siblings, 1 reply; 33+ messages in thread From: Mike C. @ 2014-02-03 15:09 UTC (permalink / raw) To: Ian Campbell; +Cc: xen-devel [-- 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-03 15:09 ` Mike C. @ 2014-02-04 2:45 ` Miguel Clara 2014-02-04 11:33 ` Ian Campbell 0 siblings, 1 reply; 33+ messages in thread From: Miguel Clara @ 2014-02-04 2:45 UTC (permalink / raw) To: Ian Campbell; +Cc: xen-devel 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-04 2:45 ` Miguel Clara @ 2014-02-04 11:33 ` Ian Campbell 2014-02-04 15:32 ` Mike C. 0 siblings, 1 reply; 33+ messages in thread From: Ian Campbell @ 2014-02-04 11:33 UTC (permalink / raw) To: Miguel Clara; +Cc: xen-devel 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-04 11:33 ` Ian Campbell @ 2014-02-04 15:32 ` Mike C. 2014-02-04 15:35 ` Ian Campbell 0 siblings, 1 reply; 33+ messages in thread From: Mike C. @ 2014-02-04 15:32 UTC (permalink / raw) To: Ian Campbell; +Cc: xen-devel 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-04 15:32 ` Mike C. @ 2014-02-04 15:35 ` Ian Campbell 2014-02-04 19:19 ` Shriram Rajagopalan 0 siblings, 1 reply; 33+ messages in thread From: Ian Campbell @ 2014-02-04 15:35 UTC (permalink / raw) To: Mike C.; +Cc: Shriram Rajagopalan, xen-devel 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. > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-04 15:35 ` Ian Campbell @ 2014-02-04 19:19 ` Shriram Rajagopalan 2014-02-04 20:26 ` Miguel Clara 0 siblings, 1 reply; 33+ messages in thread From: Shriram Rajagopalan @ 2014-02-04 19:19 UTC (permalink / raw) To: Mike C.; +Cc: xen-devel, Ian Campbell [-- 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-04 19:19 ` Shriram Rajagopalan @ 2014-02-04 20:26 ` Miguel Clara 2014-02-04 22:00 ` Miguel Clara 0 siblings, 1 reply; 33+ messages in thread From: Miguel Clara @ 2014-02-04 20:26 UTC (permalink / raw) To: rshriram; +Cc: xen-devel, Ian Campbell 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-04 20:26 ` Miguel Clara @ 2014-02-04 22:00 ` Miguel Clara 2014-02-04 22:02 ` Shriram Rajagopalan 0 siblings, 1 reply; 33+ messages in thread From: Miguel Clara @ 2014-02-04 22:00 UTC (permalink / raw) To: rshriram; +Cc: xen-devel, Ian Campbell 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-04 22:00 ` Miguel Clara @ 2014-02-04 22:02 ` Shriram Rajagopalan 2014-02-04 22:26 ` Miguel Clara 2014-02-05 3:20 ` Mike C. 0 siblings, 2 replies; 33+ messages in thread From: Shriram Rajagopalan @ 2014-02-04 22:02 UTC (permalink / raw) To: Miguel Clara; +Cc: xen-devel, Ian Campbell [-- 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-04 22:02 ` Shriram Rajagopalan @ 2014-02-04 22:26 ` Miguel Clara 2014-02-05 3:20 ` Mike C. 1 sibling, 0 replies; 33+ messages in thread From: Miguel Clara @ 2014-02-04 22:26 UTC (permalink / raw) To: rshriram; +Cc: xen-devel, Ian Campbell 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 > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-04 22:02 ` Shriram Rajagopalan 2014-02-04 22:26 ` Miguel Clara @ 2014-02-05 3:20 ` Mike C. 2014-02-06 3:37 ` Miguel Clara 1 sibling, 1 reply; 33+ messages in thread From: Mike C. @ 2014-02-05 3:20 UTC (permalink / raw) To: rshriram; +Cc: xen-devel, Ian Campbell [-- 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-05 3:20 ` Mike C. @ 2014-02-06 3:37 ` Miguel Clara 2014-02-06 10:03 ` Ian Campbell 0 siblings, 1 reply; 33+ messages in thread From: Miguel Clara @ 2014-02-06 3:37 UTC (permalink / raw) To: Shriram Rajagopalan; +Cc: xen-devel, Ian Campbell 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-06 3:37 ` Miguel Clara @ 2014-02-06 10:03 ` Ian Campbell 2014-02-06 16:03 ` Miguel Clara 0 siblings, 1 reply; 33+ messages in thread From: Ian Campbell @ 2014-02-06 10:03 UTC (permalink / raw) To: Miguel Clara; +Cc: Shriram Rajagopalan, xen-devel 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-06 10:03 ` Ian Campbell @ 2014-02-06 16:03 ` Miguel Clara 2014-02-10 14:23 ` Ian Campbell 0 siblings, 1 reply; 33+ messages in thread From: Miguel Clara @ 2014-02-06 16:03 UTC (permalink / raw) To: Ian Campbell; +Cc: Shriram Rajagopalan, xen-devel 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. > > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-06 16:03 ` Miguel Clara @ 2014-02-10 14:23 ` Ian Campbell 2014-02-12 2:48 ` Miguel Clara 0 siblings, 1 reply; 33+ messages in thread From: Ian Campbell @ 2014-02-10 14:23 UTC (permalink / raw) To: Miguel Clara; +Cc: Shriram Rajagopalan, xen-devel 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host 2014-02-10 14:23 ` Ian Campbell @ 2014-02-12 2:48 ` Miguel Clara 2014-02-12 9:56 ` handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) Ian Campbell 0 siblings, 1 reply; 33+ messages in thread From: Miguel Clara @ 2014-02-12 2:48 UTC (permalink / raw) To: Ian Campbell; +Cc: Shriram Rajagopalan, xen-devel 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. > > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-02-12 2:48 ` Miguel Clara @ 2014-02-12 9:56 ` Ian Campbell 2014-02-12 10:46 ` Roger Pau Monné 0 siblings, 1 reply; 33+ messages in thread From: Ian Campbell @ 2014-02-12 9:56 UTC (permalink / raw) To: Miguel Clara; +Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Roger Pau Monne 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-02-12 9:56 ` handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) Ian Campbell @ 2014-02-12 10:46 ` Roger Pau Monné 2014-02-13 1:29 ` Miguel Clara 2014-03-12 14:06 ` Ian Campbell 0 siblings, 2 replies; 33+ messages in thread From: Roger Pau Monné @ 2014-02-12 10:46 UTC (permalink / raw) To: Ian Campbell, Miguel Clara; +Cc: Shriram Rajagopalan, xen-devel, Ian Jackson 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 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-02-12 10:46 ` Roger Pau Monné @ 2014-02-13 1:29 ` Miguel Clara 2014-02-13 8:17 ` Roger Pau Monné 2014-03-12 14:06 ` Ian Campbell 1 sibling, 1 reply; 33+ messages in thread From: Miguel Clara @ 2014-02-13 1:29 UTC (permalink / raw) To: Roger Pau Monné Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Ian Campbell 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-02-13 1:29 ` Miguel Clara @ 2014-02-13 8:17 ` Roger Pau Monné 2014-02-13 10:10 ` Roger Pau Monné 0 siblings, 1 reply; 33+ messages in thread From: Roger Pau Monné @ 2014-02-13 8:17 UTC (permalink / raw) To: Miguel Clara; +Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Ian Campbell 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-02-13 8:17 ` Roger Pau Monné @ 2014-02-13 10:10 ` Roger Pau Monné 2014-02-14 2:09 ` Miguel Clara 0 siblings, 1 reply; 33+ messages in thread From: Roger Pau Monné @ 2014-02-13 10:10 UTC (permalink / raw) To: Miguel Clara; +Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Ian Campbell 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)" ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-02-13 10:10 ` Roger Pau Monné @ 2014-02-14 2:09 ` Miguel Clara 2014-02-14 9:13 ` Roger Pau Monné 0 siblings, 1 reply; 33+ messages in thread From: Miguel Clara @ 2014-02-14 2:09 UTC (permalink / raw) To: Roger Pau Monné Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Ian Campbell [-- 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-02-14 2:09 ` Miguel Clara @ 2014-02-14 9:13 ` Roger Pau Monné 2014-02-14 12:31 ` Mike C. 2014-02-14 20:08 ` Miguel Clara 0 siblings, 2 replies; 33+ messages in thread From: Roger Pau Monné @ 2014-02-14 9:13 UTC (permalink / raw) To: Miguel Clara; +Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Ian Campbell 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-02-14 9:13 ` Roger Pau Monné @ 2014-02-14 12:31 ` Mike C. 2014-02-14 20:08 ` Miguel Clara 1 sibling, 0 replies; 33+ messages in thread From: Mike C. @ 2014-02-14 12:31 UTC (permalink / raw) To: Roger Pau Monné Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Ian Campbell [-- 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-02-14 9:13 ` Roger Pau Monné 2014-02-14 12:31 ` Mike C. @ 2014-02-14 20:08 ` Miguel Clara 2014-02-17 8:32 ` Roger Pau Monné 1 sibling, 1 reply; 33+ messages in thread From: Miguel Clara @ 2014-02-14 20:08 UTC (permalink / raw) To: Roger Pau Monné Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Ian Campbell 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. > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-02-14 20:08 ` Miguel Clara @ 2014-02-17 8:32 ` Roger Pau Monné 2014-02-17 19:17 ` Miguel Clara 0 siblings, 1 reply; 33+ messages in thread From: Roger Pau Monné @ 2014-02-17 8:32 UTC (permalink / raw) To: Miguel Clara; +Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Ian Campbell 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-02-17 8:32 ` Roger Pau Monné @ 2014-02-17 19:17 ` Miguel Clara 2014-02-18 19:00 ` Miguel Clara 0 siblings, 1 reply; 33+ messages in thread From: Miguel Clara @ 2014-02-17 19:17 UTC (permalink / raw) To: Roger Pau Monné Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Ian Campbell 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. > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-02-17 19:17 ` Miguel Clara @ 2014-02-18 19:00 ` Miguel Clara 0 siblings, 0 replies; 33+ messages in thread From: Miguel Clara @ 2014-02-18 19:00 UTC (permalink / raw) To: Roger Pau Monné Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Ian Campbell 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! ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-02-12 10:46 ` Roger Pau Monné 2014-02-13 1:29 ` Miguel Clara @ 2014-03-12 14:06 ` Ian Campbell 2014-04-23 10:48 ` Ian Campbell 1 sibling, 1 reply; 33+ messages in thread From: Ian Campbell @ 2014-03-12 14:06 UTC (permalink / raw) To: Roger Pau Monné Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Miguel Clara 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-03-12 14:06 ` Ian Campbell @ 2014-04-23 10:48 ` Ian Campbell 2014-04-24 12:26 ` Miguel Clara 0 siblings, 1 reply; 33+ messages in thread From: Ian Campbell @ 2014-04-23 10:48 UTC (permalink / raw) To: Roger Pau Monné Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Miguel Clara 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) 2014-04-23 10:48 ` Ian Campbell @ 2014-04-24 12:26 ` Miguel Clara 0 siblings, 0 replies; 33+ messages in thread From: Miguel Clara @ 2014-04-24 12:26 UTC (permalink / raw) To: Ian Campbell Cc: Shriram Rajagopalan, xen-devel, Ian Jackson, Roger Pau Monné [-- 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2014-04-24 12:26 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-01 1:32 Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host Miguel Clara 2014-02-03 10:17 ` Ian Campbell 2014-02-03 15:09 ` Mike C. 2014-02-04 2:45 ` Miguel Clara 2014-02-04 11:33 ` Ian Campbell 2014-02-04 15:32 ` Mike C. 2014-02-04 15:35 ` Ian Campbell 2014-02-04 19:19 ` Shriram Rajagopalan 2014-02-04 20:26 ` Miguel Clara 2014-02-04 22:00 ` Miguel Clara 2014-02-04 22:02 ` Shriram Rajagopalan 2014-02-04 22:26 ` Miguel Clara 2014-02-05 3:20 ` Mike C. 2014-02-06 3:37 ` Miguel Clara 2014-02-06 10:03 ` Ian Campbell 2014-02-06 16:03 ` Miguel Clara 2014-02-10 14:23 ` Ian Campbell 2014-02-12 2:48 ` Miguel Clara 2014-02-12 9:56 ` handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host) Ian Campbell 2014-02-12 10:46 ` Roger Pau Monné 2014-02-13 1:29 ` Miguel Clara 2014-02-13 8:17 ` Roger Pau Monné 2014-02-13 10:10 ` Roger Pau Monné 2014-02-14 2:09 ` Miguel Clara 2014-02-14 9:13 ` Roger Pau Monné 2014-02-14 12:31 ` Mike C. 2014-02-14 20:08 ` Miguel Clara 2014-02-17 8:32 ` Roger Pau Monné 2014-02-17 19:17 ` Miguel Clara 2014-02-18 19:00 ` Miguel Clara 2014-03-12 14:06 ` Ian Campbell 2014-04-23 10:48 ` Ian Campbell 2014-04-24 12:26 ` Miguel Clara
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.