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

Re: [Xen-users] [XCP] XCP 1.5 Beta Create Local SR

  From: "Nick Couchman" <Nick.Couchman@seakr">Couchman@xxxxxxxxx>
  Date: Wed, 22 Feb 2012 10:05:38 -0700

  On Tue, 2012-02-21 at 18:24 -0600, hga@xxxxxxxxxxxxxx wrote:
  > From: "Nick Couchman" 
  > Date: Tue, 21 Feb 2012 16:47:10 -0700
  >   I installed XCP 1.5 Beta, and it partitioned by HD
  >   correctly but did not actually create a local SR.  The
  >   creation of a local SR through the "xe" command is
  >   sufficiently complicated enough that I'm not confident
  >   about doing it - could someone post the list of steps (or
  >   a link to a document that outlines how) to create an SR
  >   using a local disk volume?

  > Here's what I puzzled out for XCP 1.1 by looking at the
  > default sr's params; I found the device id (for the
  > whole disk) and used it in the sr-create command:

  > cat /proc/partitions ->
  > major minor  #blocks  name
  >    8        0 1953514584 sda
  >    [...]
  > ls -l /dev/disk/by-id ->
  > total 0
  > [...]
  > lrwxrwxrwx 1 root root  9 Aug 11 16:21 scsi-35000c50033e2ff7f -> ../../sda
  > [...]
  > xe sr-create name-label="Local storage slow 01" type=lvm content-type=user 
shared=false device-config:device=/dev/disk/by-id/scsi-35000c50033e2ff7f

  > The only significant difference in the sr params
  > compared to the original automatically created on
  > installation "Local storage" sr was this, which was in
  > the default but not in the one I created:

  >   other-config (MRW): i18n-original-value-name_label: Local storage; 
i18n-key: local-storage

  Thanks, Harold,

You're welcome.

  Interestingly in the XCP 1.5 beta release I do not see
  /dev/disk/by-id, so I wasn't able to use that.  Instead, I
  came up with the following command:

  xe sr-create content-type=user device-config:device=/dev/sda3 
host-uuid=47f5967d-76c9-4e66-b6e6-543afcf1c19e name-label="Local storage" 
shared=false type=lvm

I have a concern that that's fragile; add or subtract a USB
stick or another disk or whatever and what is /dev/sda
*might* change.  The device is used to create a pbd; here's
the relevant output from my machine:

xe pbd-list">pbd-list ->

uuid ( RO)                  : a844364c-fc70-f4ce-4ca1-785224cf7dc4
             host-uuid ( RO): 75de5d76-0011-4296-85b1-100567147c46
               sr-uuid ( RO): e77ffc8a-ed78-c9b0-7ed4-702308cce130
         device-config (MRO): device: 
    currently-attached ( RO): true


uuid ( RO)                  : da707dd6-d1cf-a460-cc76-6ca55f413813
             host-uuid ( RO): 75de5d76-0011-4296-85b1-100567147c46
               sr-uuid ( RO): 2415abc5-7d90-10e5-49db-39cc21c4eba0
         device-config (MRO): device: /dev/disk/by-id/scsi-35000c50033e2ff7f
    currently-attached ( RO): true

In the first one, the 3rd partition is used and I gather XCP
1.5 has the same layout with Dom0 in partition 1, partition
2 is of identical length (used for a backup command?) and
the third, comprising the rest of the disk, was left for
the Local storage sr.  Perhaps someone who's installed 1.5
could provide us with a listing from the relevant pdb so
that we can see how it's done in this version?

In the second I just gave it the whole disk.  In reflection, I'm
not sure that was a good idea (vs. a partition using the
whole disk), it violates the normal usage; can't remember
why I did it.

  This should have been done at install time by the
  installer, so not sure if this is a bug or just a glitch
  during the install I was doing?

I would think the former; that's how 1.1 works (and as I
recall it didn't give you an option *not* to create a local
repository, although strictly speaking in a proper XCP cloud
your VMs' storage is going to be separate so that you can
easily migrate them and so forth).  You might want to try a
raw installation again to see if if you've found a bug or if
1.5 just allows an option not to create a local sr.

- Harold

Xen-users mailing list



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