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

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




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

Oh, yes, depending on how XCP picks up the disks when you reboot the
system, this could be very fragile.  Theoretically, if you're using LVM
(NOT Thin Provisioning), it should *scan* the disk devices and find the
LVM one located wherever that disk happened to get attached.  However,
this would mis-match what the XE Toolstack thinks the disk should be, so
how does the system recover from that??

> 
> 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: 
> /dev/disk/by-id/scsi-3600508e0000000006069ef5986d41402-part3
>     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.

You actually can uncheck the box to create the SR on the local disk, but
I'm pretty sure I did not do this.  I did install XCP on a few nodes to
SDHC cards, and I did not want any local repository being created, so I
was able to untick the box and go through the install without the local
repo.  

-Nick



--------
This e-mail may contain confidential and privileged material for the sole use 
of the intended recipient.  If this email is not intended for you, or you are 
not responsible for the delivery of this message to the intended recipient, 
please note that this message may contain SEAKR Engineering (SEAKR) 
Privileged/Proprietary Information.  In such a case, you are strictly 
prohibited from downloading, photocopying, distributing or otherwise using this 
message, its contents or attachments in any way.  If you have received this 
message in error, please notify us immediately by replying to this e-mail and 
delete the message from your mailbox.  Information contained in this message 
that does not relate to the business of SEAKR is neither endorsed by nor 
attributable to SEAKR.

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


 


Rackspace

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