From xen-api-bounces@lists.xen.org Thu Jul 16 17:42:44 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 16 Jul 2015 17:42:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFnB6-0004It-3o; Thu, 16 Jul 2015 17:42:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFnB4-0004Id-Nc for xen-api@lists.xen.org; Thu, 16 Jul 2015 17:42:34 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id 5A/19-10437-A0DE7A55; Thu, 16 Jul 2015 17:42:34 +0000 X-Env-Sender: williamstevens@gmail.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1437068551!26553816!1 X-Originating-IP: [209.85.213.172] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15609 invoked from network); 16 Jul 2015 17:42:32 -0000 Received: from mail-ig0-f172.google.com (HELO mail-ig0-f172.google.com) (209.85.213.172) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 16 Jul 2015 17:42:32 -0000 Received: by iggp10 with SMTP id p10so18507000igg.0 for ; Thu, 16 Jul 2015 10:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=s71QJ1CRY55aalRSBfA8DS3d/MnWG/m1xZj/mBGAhAg=; b=Wbf3k41h1mnERIurzaaibVwYVxih47L/16lu1AhZAg2nvtPfA4SGaOYjhafp56FyHq WIYkjJ9fXplj0ud4j1rTN1iJMET7S9EIfa+j7eVc8UsCOY/tFbYnRE2o5FzyRgVKycpq 6wv40d1whq/6YbeIIScrf30w7BaSGCLYwudVsLRRPDwLEn3qzocYMAbiSOklFsi8es3H 1FTH60Mnh9kG07fYtThCnAZoiYvLQPe9Af9UWWgwEGW1etxLPYKj7haWRjeun/cUj6BK gmwvrxLDsGaGudHKmtqvCWfS8EJP+tW7O73+9fwqisvugi6w5c69kG//bnbgGnvDpezF rdKQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudops.com; s=google; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=s71QJ1CRY55aalRSBfA8DS3d/MnWG/m1xZj/mBGAhAg=; b=NGyDXdCbbz4JkEMu3rqH2va14lAygoL4BiLISLTtw4sY8L6GDbBUal1ZQ0b3pMlp4W 6IbbNkzLxJcHgS/eeO2ZPUkIVoRgEuYgLG6UV5gToc4EEhCLU0Ym6JuiDbnf096Lq9fI V50aYTnDCuAzqpsobIoj+kgRjHJ0v39x4UnG8= MIME-Version: 1.0 X-Received: by 10.107.15.25 with SMTP id x25mr14807134ioi.161.1437068551369; Thu, 16 Jul 2015 10:42:31 -0700 (PDT) Received: by 10.64.36.233 with HTTP; Thu, 16 Jul 2015 10:42:31 -0700 (PDT) Date: Thu, 16 Jul 2015 13:42:31 -0400 X-Google-Sender-Auth: 33WiysdVs86WHNbSjuMqwGQtSUM Message-ID: From: Will Stevens To: xen-api@lists.xen.org Subject: [Xen-API] PROPOSAL: Resignature Duplicate SRs X-BeenThere: xen-api@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: User and development list for XCP and XAPI List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5332710826162050372==" Sender: xen-api-bounces@lists.xen.org Errors-To: xen-api-bounces@lists.xen.org --===============5332710826162050372== Content-Type: multipart/alternative; boundary=001a113f193885ba25051b0198d8 --001a113f193885ba25051b0198d8 Content-Type: text/plain; charset=UTF-8 Hello Everyone, I am in the early stages of planning the development of the following functionality. If you have any comments or suggestions I would appreciate your feedback. I am looking to develop a supplemental pack for XenServer to allow an existing SR to be reintroduced to the XenServer and have the new SR resignatured (including all its VDIs) so both the original and new SR can exist on the system at the same time. *Context:* We currently use XenServer with Apache CloudStack (ACS) and SolidFire for storage. We have a configuration where we have an SR including a single VDI that maps to a LUN in the SolidFire. This configuration allows us to provide QoS on each VDI in our system. The SolidFire offers us a lot of interesting features and is well supported by ACS. *The Problem:* We are trying to solve for a problem when we take a snapshot of the LUN on the SolidFire and then try to reintroduce that new snapshot back into XenServer. The situation is as follows: - XenServer has an SR with 1 (or more) VDIs in it which is represented as a single LUN (L0) in the SolidFire (for QoS of that SR). - The SolidFire can do a snapshot of this LUN (L0) to create a second logically identical LUN (L1). - The attempt to introduce the new LUN (L1) into XenServer fails with the following error: Attaching SR Internal error: Db_exn.Uniqueness_constraint_violation("SR", "uuid", "1c2...hash...71a") Check your settings and try again. This is the expected behavior because the current implementation of XenServer does not know how to deal with an attempt to attach a second SR with the same UUID as an SR that already exists in the system. *Observations:* - The newly created LUN (L1) on the SolidFire has SR metadata stored inside it which includes the SR UUID. - The newly created LUN (L1) on the SolidFire has VDI metadata stored inside it which includes the VDI UUIDs. *Challenges:* - Since the new LUN (L1) has the SR UUID saved as metadata inside the LUN (L1), we need to be able to modify that metadata in order to resignature it. However, this means that we have to attach the SR in order to modify the existing metadata configured on the LUN (L1). - Since we can not attach the LUN as an SR because of the uniqueness constraint, we can not modify the SR to resignature it. *Possible Solution(s):* (I am still validating how I will develop this, so please correct me if I am off base on anything...) - Introduce a new XenServer config option that would be something like ' resignature_duplicate_srs' with the following options: -- 'False' (default) : This is the current behavior and would not let the operation happen -- 'True' : This option would catch if a duplicate SR is being added and would resignature the newly added SR - If the configuration is set to 'True' (resignature the SR) when introducing a duplicate SR, the XenServer would attempt to do the following: -- Generate a new SR UUID for the duplicate SR. -- Attach the SR (temporarily? unofficially according to XenServer?) using the new UUID and the ISCSI IQN (which would be the LUN (L1) on the SolidFire in this case). -- Update the SR metadata on the LUN (L1) to reflect the new SR UUID (not sure how much other stuff I would have to change, but this is probably more involved than this). -- Loop through all the VDIs on this SR and resignature each of the VDIs. This may be reasonably complex since this is setup through LVM and I will have to update the Volume Group (VG) and the Logical Volumes (LV). I have not spent much time looking at this piece yet. -- I should not have to worry about the VBDs at this point because none should be attached to the VDIs since these will all be new references. The VBDs should be automatically handled when the new VDIs are attached to VMs. - Assuming this all goes as planned, I will probably have to detach this new temporary SR now that it has been resignatured and kick off the normal XenServer flow to attach this new SR. This is important because we need the XenServer to update all of its local caching and such and load the SR correctly from scratch. *Next Steps:* - Figure out how the supplemental packs work with the DDK . - Setup a dev environment to start working on the DDK. - Figure out how to unofficially attach an SR using a newly generated UUID so I can get access to the LUN (L1) metadata and update it. This is my plan right now. If you have concerns with this approach, please speak up because I want to reduce the number of failed attempts at implementing this. I am still learning how everything works and how it all fits together, so your comments are very helpful for me as most of you understand the inner workings of this better than I do at this point. I have been spending a lot of time getting my head around how the Storage Manager works by looking through the code here: https://github.com/xapi-project/sm/tree/master/drivers Thanks for your time. Cheers, *Will STEVENS* Lead Developer *CloudOps* *| *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ --001a113f193885ba25051b0198d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Everyone,
I am in the early stages of planning t= he development of the following functionality.=C2=A0 If you have any commen= ts or suggestions I would appreciate your feedback.

I am looking to develop a supplemental pack for XenServer to allow an exi= sting SR to be reintroduced to the XenServer and have the new SR resignatur= ed (including all its VDIs) so both the original and new SR can exist on th= e system at the same time.

Context:
We currently use XenServer with Apache CloudStack (ACS) and SolidFire fo= r storage.=C2=A0 We have a configuration where we have an SR including a si= ngle VDI that maps to a LUN in the SolidFire.=C2=A0 This configuration allo= ws us to provide QoS on each VDI in our system.=C2=A0 The SolidFire offers = us a lot of interesting features and is well supported by ACS.
The Problem:
We are trying to solve for a pro= blem when we take a snapshot of the LUN on the SolidFire and then try to re= introduce that new snapshot back into XenServer.=C2=A0 The situation is as = follows:
- XenSe= rver has an SR with 1 (or more) VDIs in it which is represented as a single= LUN (L0) in the SolidFire (for QoS of that SR).
- The SolidFire can do a snapshot of this LUN (L0) t= o create a second logically identical LUN (L1).
- The attempt to introduce the new LUN (L1) into XenS= erver fails with the following error:

Attaching SR
Internal error:
Db_exn.Uniqueness_constraint_violation("SR", "= ;uuid", "1c2...hash...71a")
Check your = settings and try again.

This is the expe= cted behavior because=C2=A0the= current implementation of XenServer does not know how to deal with an atte= mpt to attach a second SR with the same UUID as an SR that already exists i= n the system.

O= bservations:
- The newly created LUN (L1) on t= he SolidFire has SR metadata stored inside it which includes the SR UUID.
- The newly created LUN (L1= ) on the SolidFire has VDI metadata stored inside it which includes the VDI= UUIDs.

Challenges:
- = Since the new LUN (L1) has the SR UUID saved as metadata inside the LUN (L1= ), we need to be able to modify that metadata in order to resignature it.= =C2=A0 However, this means that we have to attach the SR in order to modify= the existing metadata configured on the LUN (L1).
- Since we can not attach the LUN as an SR because= of the uniqueness constraint, we can not modify the SR to resignature it.<= /div>

= Possible Solution(s):
= (I am still validating how I will develop this, so please correct me if I a= m off base on anything...)
- Introduce a new XenServer config option that would be something like = 9;resignature_duplicate_srs'= with the following options:
-- 'False' (default) = : This is the current behavior and would not let the operation happen
=
-- 'True' : This option would catch if a duplicate SR i= s being added and would resignature the newly added SR
- If the configuration is set to 'True' (resignature the SR) when intr= oducing a duplicate SR, the XenServer would attempt to do the following:
-- Generate a new SR UUID fo= r the duplicate SR.
-- Att= ach the SR (temporarily? =C2=A0unofficially according to XenServer?) using = the new UUID and the ISCSI IQN (which would be the LUN (L1) on the SolidFir= e in this case).
-- Update= the SR metadata on the LUN (L1) to reflect the new SR UUID (not sure how m= uch other stuff I would have to change, but this is probably more involved = than this).
-- Loop throug= h all the VDIs on this SR and resignature each of the VDIs.=C2=A0 This may = be reasonably complex since this is setup through LVM and I will have to up= date the Volume Group (VG) and the Logical Volumes (LV).=C2=A0 I have not s= pent much time looking at this piece yet.
-- I should not have to worry about the VBDs at this point = because none should be attached to the VDIs since these will all be new ref= erences.=C2=A0 The VBDs should be automatically handled when the new VDIs a= re attached to VMs.
- Assu= ming this all goes as planned, I will probably have to detach this new temp= orary SR now that it has been resignatured and kick off the normal XenServe= r flow to attach this new SR.=C2=A0 This is important because we need the X= enServer to update all of its local caching and such and load the SR correc= tly from scratch.

Next Steps:
- Figure out how the=C2=A0supplemental packs work = with the DDK.
- Setup = a dev environment to start working on the DDK.
- Figure out how to unofficially attach an SR using a = newly generated UUID so I can get access to the LUN (L1) metadata and updat= e it.

This is my plan right now.=C2=A0 If you h= ave concerns with this approach, please speak up because I want to reduce t= he number of failed attempts at implementing this.=C2=A0 I am still learnin= g how everything works and how it all fits together, so your comments are v= ery helpful for me as most of you understand the inner workings of this bet= ter than I do at this point.

I have been spendi= ng a lot of time getting my head around how the Storage Manager works by lo= oking through the code here:=C2=A0https://github.com/xapi-project/sm/tree/master/dr= ivers

Thanks for your time.

Cheers,

Will STEVENS
Lead Developer

CloudOps=C2=A0|=C2=A0C= loud Solutions Experts
420 rue Guy= =C2=A0|=C2=A0Montreal=C2=A0|=C2=A0Quebec=C2=A0|=C2=A0H3J 1S6
w=C2=A0cloudops.com=C2=A0|=C2=A0tw=C2=A0@CloudOps_=C2=A0 =C2=A0

--001a113f193885ba25051b0198d8-- --===============5332710826162050372== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api --===============5332710826162050372==-- From xen-api-bounces@lists.xen.org Thu Jul 16 17:42:44 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 16 Jul 2015 17:42:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFnB6-0004It-3o; Thu, 16 Jul 2015 17:42:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFnB4-0004Id-Nc for xen-api@lists.xen.org; Thu, 16 Jul 2015 17:42:34 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id 5A/19-10437-A0DE7A55; Thu, 16 Jul 2015 17:42:34 +0000 X-Env-Sender: williamstevens@gmail.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1437068551!26553816!1 X-Originating-IP: [209.85.213.172] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15609 invoked from network); 16 Jul 2015 17:42:32 -0000 Received: from mail-ig0-f172.google.com (HELO mail-ig0-f172.google.com) (209.85.213.172) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 16 Jul 2015 17:42:32 -0000 Received: by iggp10 with SMTP id p10so18507000igg.0 for ; Thu, 16 Jul 2015 10:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=s71QJ1CRY55aalRSBfA8DS3d/MnWG/m1xZj/mBGAhAg=; b=Wbf3k41h1mnERIurzaaibVwYVxih47L/16lu1AhZAg2nvtPfA4SGaOYjhafp56FyHq WIYkjJ9fXplj0ud4j1rTN1iJMET7S9EIfa+j7eVc8UsCOY/tFbYnRE2o5FzyRgVKycpq 6wv40d1whq/6YbeIIScrf30w7BaSGCLYwudVsLRRPDwLEn3qzocYMAbiSOklFsi8es3H 1FTH60Mnh9kG07fYtThCnAZoiYvLQPe9Af9UWWgwEGW1etxLPYKj7haWRjeun/cUj6BK gmwvrxLDsGaGudHKmtqvCWfS8EJP+tW7O73+9fwqisvugi6w5c69kG//bnbgGnvDpezF rdKQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudops.com; s=google; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=s71QJ1CRY55aalRSBfA8DS3d/MnWG/m1xZj/mBGAhAg=; b=NGyDXdCbbz4JkEMu3rqH2va14lAygoL4BiLISLTtw4sY8L6GDbBUal1ZQ0b3pMlp4W 6IbbNkzLxJcHgS/eeO2ZPUkIVoRgEuYgLG6UV5gToc4EEhCLU0Ym6JuiDbnf096Lq9fI V50aYTnDCuAzqpsobIoj+kgRjHJ0v39x4UnG8= MIME-Version: 1.0 X-Received: by 10.107.15.25 with SMTP id x25mr14807134ioi.161.1437068551369; Thu, 16 Jul 2015 10:42:31 -0700 (PDT) Received: by 10.64.36.233 with HTTP; Thu, 16 Jul 2015 10:42:31 -0700 (PDT) Date: Thu, 16 Jul 2015 13:42:31 -0400 X-Google-Sender-Auth: 33WiysdVs86WHNbSjuMqwGQtSUM Message-ID: From: Will Stevens To: xen-api@lists.xen.org Subject: [Xen-API] PROPOSAL: Resignature Duplicate SRs X-BeenThere: xen-api@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: User and development list for XCP and XAPI List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5332710826162050372==" Sender: xen-api-bounces@lists.xen.org Errors-To: xen-api-bounces@lists.xen.org --===============5332710826162050372== Content-Type: multipart/alternative; boundary=001a113f193885ba25051b0198d8 --001a113f193885ba25051b0198d8 Content-Type: text/plain; charset=UTF-8 Hello Everyone, I am in the early stages of planning the development of the following functionality. If you have any comments or suggestions I would appreciate your feedback. I am looking to develop a supplemental pack for XenServer to allow an existing SR to be reintroduced to the XenServer and have the new SR resignatured (including all its VDIs) so both the original and new SR can exist on the system at the same time. *Context:* We currently use XenServer with Apache CloudStack (ACS) and SolidFire for storage. We have a configuration where we have an SR including a single VDI that maps to a LUN in the SolidFire. This configuration allows us to provide QoS on each VDI in our system. The SolidFire offers us a lot of interesting features and is well supported by ACS. *The Problem:* We are trying to solve for a problem when we take a snapshot of the LUN on the SolidFire and then try to reintroduce that new snapshot back into XenServer. The situation is as follows: - XenServer has an SR with 1 (or more) VDIs in it which is represented as a single LUN (L0) in the SolidFire (for QoS of that SR). - The SolidFire can do a snapshot of this LUN (L0) to create a second logically identical LUN (L1). - The attempt to introduce the new LUN (L1) into XenServer fails with the following error: Attaching SR Internal error: Db_exn.Uniqueness_constraint_violation("SR", "uuid", "1c2...hash...71a") Check your settings and try again. This is the expected behavior because the current implementation of XenServer does not know how to deal with an attempt to attach a second SR with the same UUID as an SR that already exists in the system. *Observations:* - The newly created LUN (L1) on the SolidFire has SR metadata stored inside it which includes the SR UUID. - The newly created LUN (L1) on the SolidFire has VDI metadata stored inside it which includes the VDI UUIDs. *Challenges:* - Since the new LUN (L1) has the SR UUID saved as metadata inside the LUN (L1), we need to be able to modify that metadata in order to resignature it. However, this means that we have to attach the SR in order to modify the existing metadata configured on the LUN (L1). - Since we can not attach the LUN as an SR because of the uniqueness constraint, we can not modify the SR to resignature it. *Possible Solution(s):* (I am still validating how I will develop this, so please correct me if I am off base on anything...) - Introduce a new XenServer config option that would be something like ' resignature_duplicate_srs' with the following options: -- 'False' (default) : This is the current behavior and would not let the operation happen -- 'True' : This option would catch if a duplicate SR is being added and would resignature the newly added SR - If the configuration is set to 'True' (resignature the SR) when introducing a duplicate SR, the XenServer would attempt to do the following: -- Generate a new SR UUID for the duplicate SR. -- Attach the SR (temporarily? unofficially according to XenServer?) using the new UUID and the ISCSI IQN (which would be the LUN (L1) on the SolidFire in this case). -- Update the SR metadata on the LUN (L1) to reflect the new SR UUID (not sure how much other stuff I would have to change, but this is probably more involved than this). -- Loop through all the VDIs on this SR and resignature each of the VDIs. This may be reasonably complex since this is setup through LVM and I will have to update the Volume Group (VG) and the Logical Volumes (LV). I have not spent much time looking at this piece yet. -- I should not have to worry about the VBDs at this point because none should be attached to the VDIs since these will all be new references. The VBDs should be automatically handled when the new VDIs are attached to VMs. - Assuming this all goes as planned, I will probably have to detach this new temporary SR now that it has been resignatured and kick off the normal XenServer flow to attach this new SR. This is important because we need the XenServer to update all of its local caching and such and load the SR correctly from scratch. *Next Steps:* - Figure out how the supplemental packs work with the DDK . - Setup a dev environment to start working on the DDK. - Figure out how to unofficially attach an SR using a newly generated UUID so I can get access to the LUN (L1) metadata and update it. This is my plan right now. If you have concerns with this approach, please speak up because I want to reduce the number of failed attempts at implementing this. I am still learning how everything works and how it all fits together, so your comments are very helpful for me as most of you understand the inner workings of this better than I do at this point. I have been spending a lot of time getting my head around how the Storage Manager works by looking through the code here: https://github.com/xapi-project/sm/tree/master/drivers Thanks for your time. Cheers, *Will STEVENS* Lead Developer *CloudOps* *| *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ --001a113f193885ba25051b0198d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Everyone,
I am in the early stages of planning t= he development of the following functionality.=C2=A0 If you have any commen= ts or suggestions I would appreciate your feedback.

I am looking to develop a supplemental pack for XenServer to allow an exi= sting SR to be reintroduced to the XenServer and have the new SR resignatur= ed (including all its VDIs) so both the original and new SR can exist on th= e system at the same time.

Context:
We currently use XenServer with Apache CloudStack (ACS) and SolidFire fo= r storage.=C2=A0 We have a configuration where we have an SR including a si= ngle VDI that maps to a LUN in the SolidFire.=C2=A0 This configuration allo= ws us to provide QoS on each VDI in our system.=C2=A0 The SolidFire offers = us a lot of interesting features and is well supported by ACS.
The Problem:
We are trying to solve for a pro= blem when we take a snapshot of the LUN on the SolidFire and then try to re= introduce that new snapshot back into XenServer.=C2=A0 The situation is as = follows:
- XenSe= rver has an SR with 1 (or more) VDIs in it which is represented as a single= LUN (L0) in the SolidFire (for QoS of that SR).
- The SolidFire can do a snapshot of this LUN (L0) t= o create a second logically identical LUN (L1).
- The attempt to introduce the new LUN (L1) into XenS= erver fails with the following error:

Attaching SR
Internal error:
Db_exn.Uniqueness_constraint_violation("SR", "= ;uuid", "1c2...hash...71a")
Check your = settings and try again.

This is the expe= cted behavior because=C2=A0the= current implementation of XenServer does not know how to deal with an atte= mpt to attach a second SR with the same UUID as an SR that already exists i= n the system.

O= bservations:
- The newly created LUN (L1) on t= he SolidFire has SR metadata stored inside it which includes the SR UUID.
- The newly created LUN (L1= ) on the SolidFire has VDI metadata stored inside it which includes the VDI= UUIDs.

Challenges:
- = Since the new LUN (L1) has the SR UUID saved as metadata inside the LUN (L1= ), we need to be able to modify that metadata in order to resignature it.= =C2=A0 However, this means that we have to attach the SR in order to modify= the existing metadata configured on the LUN (L1).
- Since we can not attach the LUN as an SR because= of the uniqueness constraint, we can not modify the SR to resignature it.<= /div>

= Possible Solution(s):
= (I am still validating how I will develop this, so please correct me if I a= m off base on anything...)
- Introduce a new XenServer config option that would be something like = 9;resignature_duplicate_srs'= with the following options:
-- 'False' (default) = : This is the current behavior and would not let the operation happen
=
-- 'True' : This option would catch if a duplicate SR i= s being added and would resignature the newly added SR
- If the configuration is set to 'True' (resignature the SR) when intr= oducing a duplicate SR, the XenServer would attempt to do the following:
-- Generate a new SR UUID fo= r the duplicate SR.
-- Att= ach the SR (temporarily? =C2=A0unofficially according to XenServer?) using = the new UUID and the ISCSI IQN (which would be the LUN (L1) on the SolidFir= e in this case).
-- Update= the SR metadata on the LUN (L1) to reflect the new SR UUID (not sure how m= uch other stuff I would have to change, but this is probably more involved = than this).
-- Loop throug= h all the VDIs on this SR and resignature each of the VDIs.=C2=A0 This may = be reasonably complex since this is setup through LVM and I will have to up= date the Volume Group (VG) and the Logical Volumes (LV).=C2=A0 I have not s= pent much time looking at this piece yet.
-- I should not have to worry about the VBDs at this point = because none should be attached to the VDIs since these will all be new ref= erences.=C2=A0 The VBDs should be automatically handled when the new VDIs a= re attached to VMs.
- Assu= ming this all goes as planned, I will probably have to detach this new temp= orary SR now that it has been resignatured and kick off the normal XenServe= r flow to attach this new SR.=C2=A0 This is important because we need the X= enServer to update all of its local caching and such and load the SR correc= tly from scratch.

Next Steps:
- Figure out how the=C2=A0supplemental packs work = with the DDK.
- Setup = a dev environment to start working on the DDK.
- Figure out how to unofficially attach an SR using a = newly generated UUID so I can get access to the LUN (L1) metadata and updat= e it.

This is my plan right now.=C2=A0 If you h= ave concerns with this approach, please speak up because I want to reduce t= he number of failed attempts at implementing this.=C2=A0 I am still learnin= g how everything works and how it all fits together, so your comments are v= ery helpful for me as most of you understand the inner workings of this bet= ter than I do at this point.

I have been spendi= ng a lot of time getting my head around how the Storage Manager works by lo= oking through the code here:=C2=A0https://github.com/xapi-project/sm/tree/master/dr= ivers

Thanks for your time.

Cheers,

Will STEVENS
Lead Developer

CloudOps=C2=A0|=C2=A0C= loud Solutions Experts
420 rue Guy= =C2=A0|=C2=A0Montreal=C2=A0|=C2=A0Quebec=C2=A0|=C2=A0H3J 1S6
w=C2=A0cloudops.com=C2=A0|=C2=A0tw=C2=A0@CloudOps_=C2=A0 =C2=A0

--001a113f193885ba25051b0198d8-- --===============5332710826162050372== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api --===============5332710826162050372==-- From xen-api-bounces@lists.xen.org Tue Jul 28 03:52:58 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 03:52:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJvwe-0001iv-TM; Tue, 28 Jul 2015 03:52:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJvwd-0001ic-Iw; Tue, 28 Jul 2015 03:52:47 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 66/C8-19125-E8CF6B55; Tue, 28 Jul 2015 03:52:46 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1438055566!21124365!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=2.1 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 503 invoked from network); 28 Jul 2015 03:52:46 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 28 Jul 2015 03:52:46 -0000 Received: by wibud3 with SMTP id ud3so163484062wib.1; Mon, 27 Jul 2015 20:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=z58TzHytt85SkKfOISQsb6ZI32MQY1ZtcB0XxtdrcCA=; b=hxxzveWJYdVzPcCo7buqr1IY9nqJZbq9SmkoexvNWLnaMC7Ad+h0wTwdlfJQ3y+ynB oJ2MpGMcCoDjOJE1YkL/62fU2A+N1vVCteQE/IW21tVaDbVxaYYHAlTFGlH9w1jpXDX1 mfppy8vfJ/G76u5uwmyl6R9OKR8TL8M44SkQumlDxkUKzJ26LCqV+KQGxw73M8CN95Nb Z31C4EFPlSIy3yuBdhSnltdmD4K54rOSDJFpOl0GfYK9X904C06/hOidG3hjBa6m3u3u Ykjzmwg6b0GvpTAE3zPF4/epZ7pCt5ssB0zTCtJEfL81LavAUMknxyGjGJ2JW+IW5iVZ sV2A== MIME-Version: 1.0 X-Received: by 10.180.10.200 with SMTP id k8mr2328015wib.5.1438055566013; Mon, 27 Jul 2015 20:52:46 -0700 (PDT) Received: by 10.194.81.99 with HTTP; Mon, 27 Jul 2015 20:52:45 -0700 (PDT) Date: Mon, 27 Jul 2015 23:52:45 -0400 X-Google-Sender-Auth: Mfns2vI3u7yLA7g3vVkEbD5FcRM Message-ID: From: Russ Pavlicek To: xen-devel , "xen-users@lists.xen.org" , xs-devel@lists.xenserver.org, xen-api@lists.xen.org, mirageos-devel@lists.xenproject.org, "publicity@lists.xenproject.org" Subject: [Xen-API] Xen Project Document Day is this Wednesday July 29 X-BeenThere: xen-api@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: User and development list for XCP and XAPI List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-api-bounces@lists.xen.org Errors-To: xen-api-bounces@lists.xen.org Our next Xen Project Document Day is this Wednesday, July 29! Our THEME OF THE MONTH: "The Reverse Yard Sale" For many of us in the northern hemisphere, this is the time of year when people sort through the things they own and put the things they no longer need into a yard sale. Well, instead of removing things we don't need, we want a reverse yard sale, where we add the things we *do* need. Some topics to address include: - Hyper: the new hypervisor-independent Docker engine which uses Xen Project (among other hypervisors); we need a basic document on how to use Xen Project with Hyper - XAPI: The latest docs from the XenServer crew need to be referenced from our wiki - Unikernels: Lots of Unikernels leverage Xen Project; we need them properly linked in to our wiki - Booting with UEFI: needs to be made current - Raisin: the new effort has a new wiki page which needs review - and anything else which needs to be added All the information you need to participate in Document Day is here: http://wiki.xenproject.org/wiki/Xen_Document_Days Also take a look at the current TODO list to see other items which need attention: http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO Please think about how you can help out. If you haven't requested to be made a Wiki editor, save time and do it now so you are ready to go on Document Day. Just fill out the form below: http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html We hope to see you Wednesday in #xendocs! _______________________________________________ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api From xen-api-bounces@lists.xen.org Tue Jul 28 03:52:58 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 03:52:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJvwe-0001iv-TM; Tue, 28 Jul 2015 03:52:48 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJvwd-0001ic-Iw; Tue, 28 Jul 2015 03:52:47 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 66/C8-19125-E8CF6B55; Tue, 28 Jul 2015 03:52:46 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1438055566!21124365!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=2.1 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 503 invoked from network); 28 Jul 2015 03:52:46 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 28 Jul 2015 03:52:46 -0000 Received: by wibud3 with SMTP id ud3so163484062wib.1; Mon, 27 Jul 2015 20:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=z58TzHytt85SkKfOISQsb6ZI32MQY1ZtcB0XxtdrcCA=; b=hxxzveWJYdVzPcCo7buqr1IY9nqJZbq9SmkoexvNWLnaMC7Ad+h0wTwdlfJQ3y+ynB oJ2MpGMcCoDjOJE1YkL/62fU2A+N1vVCteQE/IW21tVaDbVxaYYHAlTFGlH9w1jpXDX1 mfppy8vfJ/G76u5uwmyl6R9OKR8TL8M44SkQumlDxkUKzJ26LCqV+KQGxw73M8CN95Nb Z31C4EFPlSIy3yuBdhSnltdmD4K54rOSDJFpOl0GfYK9X904C06/hOidG3hjBa6m3u3u Ykjzmwg6b0GvpTAE3zPF4/epZ7pCt5ssB0zTCtJEfL81LavAUMknxyGjGJ2JW+IW5iVZ sV2A== MIME-Version: 1.0 X-Received: by 10.180.10.200 with SMTP id k8mr2328015wib.5.1438055566013; Mon, 27 Jul 2015 20:52:46 -0700 (PDT) Received: by 10.194.81.99 with HTTP; Mon, 27 Jul 2015 20:52:45 -0700 (PDT) Date: Mon, 27 Jul 2015 23:52:45 -0400 X-Google-Sender-Auth: Mfns2vI3u7yLA7g3vVkEbD5FcRM Message-ID: From: Russ Pavlicek To: xen-devel , "xen-users@lists.xen.org" , xs-devel@lists.xenserver.org, xen-api@lists.xen.org, mirageos-devel@lists.xenproject.org, "publicity@lists.xenproject.org" Subject: [Xen-API] Xen Project Document Day is this Wednesday July 29 X-BeenThere: xen-api@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: User and development list for XCP and XAPI List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-api-bounces@lists.xen.org Errors-To: xen-api-bounces@lists.xen.org Our next Xen Project Document Day is this Wednesday, July 29! Our THEME OF THE MONTH: "The Reverse Yard Sale" For many of us in the northern hemisphere, this is the time of year when people sort through the things they own and put the things they no longer need into a yard sale. Well, instead of removing things we don't need, we want a reverse yard sale, where we add the things we *do* need. Some topics to address include: - Hyper: the new hypervisor-independent Docker engine which uses Xen Project (among other hypervisors); we need a basic document on how to use Xen Project with Hyper - XAPI: The latest docs from the XenServer crew need to be referenced from our wiki - Unikernels: Lots of Unikernels leverage Xen Project; we need them properly linked in to our wiki - Booting with UEFI: needs to be made current - Raisin: the new effort has a new wiki page which needs review - and anything else which needs to be added All the information you need to participate in Document Day is here: http://wiki.xenproject.org/wiki/Xen_Document_Days Also take a look at the current TODO list to see other items which need attention: http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO Please think about how you can help out. If you haven't requested to be made a Wiki editor, save time and do it now so you are ready to go on Document Day. Just fill out the form below: http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html We hope to see you Wednesday in #xendocs! _______________________________________________ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api From xen-api-bounces@lists.xen.org Wed Jul 29 04:07:16 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 04:07:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKIe0-0000TM-8F; Wed, 29 Jul 2015 04:07:04 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKIdy-0000Sv-Gt; Wed, 29 Jul 2015 04:07:02 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id 9A/57-00475-56158B55; Wed, 29 Jul 2015 04:07:01 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1438142820!36082770!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=2.1 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26362 invoked from network); 29 Jul 2015 04:07:00 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 04:07:00 -0000 Received: by wicgb10 with SMTP id gb10so182129043wic.1; Tue, 28 Jul 2015 21:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0CwZO5LHNb2jHZ0urb7MMfRTul/JcdSHB31rWdHceUk=; b=AwQuH4pv3puR1W275c4DGfAyg8SaXcxwcOci3gbqZfh98Vr7l4f/o4+3rH2IeMSbsp DFJXvn92mdr9YJpwdlI+VdgxL1u2LYvnsAnTH/GRVy1lPvXwfXkrInPeAzSijH1xLPtu GTCFwWWNmNpd3vgLawSU6d6rgLkN2d1skSp2hqSt5XvLyCh1egpA+V8FYeCq6klTKuZ/ IlLcfBMxFYPQbHqh7+1Z9oc+hZKGkte0W4vqdbmCTR51J7nomNV76IOT1uOM0HbMLvdv Pvi8FsllaZ93mloHtsGiI4qUdeiNYT5wbil0q5hVv2FTHhUM00jZ9px9BoVo3677u59/ IsnA== MIME-Version: 1.0 X-Received: by 10.181.12.20 with SMTP id em20mr1731884wid.28.1438142819118; Tue, 28 Jul 2015 21:06:59 -0700 (PDT) Received: by 10.194.81.99 with HTTP; Tue, 28 Jul 2015 21:06:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Jul 2015 00:06:59 -0400 X-Google-Sender-Auth: qPaVX-Ni8ZfC0IaKYVfwr-84lq4 Message-ID: From: Russ Pavlicek To: Russ Pavlicek Cc: xen-api@lists.xen.org, xen-devel , xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org, "xen-users@lists.xen.org" Subject: Re: [Xen-API] Xen Project Document Day is this Wednesday July 29 X-BeenThere: xen-api@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: User and development list for XCP and XAPI List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-api-bounces@lists.xen.org Errors-To: xen-api-bounces@lists.xen.org Xen Project Document Day is here! Join us as we seek to make our Wiki more accurate and useful! On Mon, Jul 27, 2015 at 11:52 PM, Russ Pavlicek wrote: > Our next Xen Project Document Day is this Wednesday, July 29! > > Our THEME OF THE MONTH: "The Reverse Yard Sale" > > For many of us in the northern hemisphere, this is the time of year > when people sort through the things they own and put the things they > no longer need into a yard sale. Well, instead of removing things we > don't need, we want a reverse yard sale, where we add the things we > *do* need. Some topics to address include: > > - Hyper: the new hypervisor-independent Docker engine which uses Xen > Project (among other hypervisors); we need a basic document on how to > use Xen Project with Hyper > - XAPI: The latest docs from the XenServer crew need to be referenced > from our wiki > - Unikernels: Lots of Unikernels leverage Xen Project; we need them > properly linked in to our wiki > - Booting with UEFI: needs to be made current > - Raisin: the new effort has a new wiki page which needs review > - and anything else which needs to be added > > All the information you need to participate in Document Day is here: > > http://wiki.xenproject.org/wiki/Xen_Document_Days > > Also take a look at the current TODO list to see other items which > need attention: > > http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO > > Please think about how you can help out. If you haven't requested > to be made a Wiki editor, save time and do it now so you are ready to > go on Document Day. Just fill out the form below: > > http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html > > We hope to see you Wednesday in #xendocs! _______________________________________________ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api From xen-api-bounces@lists.xen.org Wed Jul 29 04:07:16 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 04:07:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKIe0-0000TM-8F; Wed, 29 Jul 2015 04:07:04 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKIdy-0000Sv-Gt; Wed, 29 Jul 2015 04:07:02 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id 9A/57-00475-56158B55; Wed, 29 Jul 2015 04:07:01 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1438142820!36082770!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=2.1 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26362 invoked from network); 29 Jul 2015 04:07:00 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 04:07:00 -0000 Received: by wicgb10 with SMTP id gb10so182129043wic.1; Tue, 28 Jul 2015 21:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0CwZO5LHNb2jHZ0urb7MMfRTul/JcdSHB31rWdHceUk=; b=AwQuH4pv3puR1W275c4DGfAyg8SaXcxwcOci3gbqZfh98Vr7l4f/o4+3rH2IeMSbsp DFJXvn92mdr9YJpwdlI+VdgxL1u2LYvnsAnTH/GRVy1lPvXwfXkrInPeAzSijH1xLPtu GTCFwWWNmNpd3vgLawSU6d6rgLkN2d1skSp2hqSt5XvLyCh1egpA+V8FYeCq6klTKuZ/ IlLcfBMxFYPQbHqh7+1Z9oc+hZKGkte0W4vqdbmCTR51J7nomNV76IOT1uOM0HbMLvdv Pvi8FsllaZ93mloHtsGiI4qUdeiNYT5wbil0q5hVv2FTHhUM00jZ9px9BoVo3677u59/ IsnA== MIME-Version: 1.0 X-Received: by 10.181.12.20 with SMTP id em20mr1731884wid.28.1438142819118; Tue, 28 Jul 2015 21:06:59 -0700 (PDT) Received: by 10.194.81.99 with HTTP; Tue, 28 Jul 2015 21:06:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Jul 2015 00:06:59 -0400 X-Google-Sender-Auth: qPaVX-Ni8ZfC0IaKYVfwr-84lq4 Message-ID: From: Russ Pavlicek To: Russ Pavlicek Cc: xen-api@lists.xen.org, xen-devel , xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org, "xen-users@lists.xen.org" Subject: Re: [Xen-API] Xen Project Document Day is this Wednesday July 29 X-BeenThere: xen-api@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: User and development list for XCP and XAPI List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-api-bounces@lists.xen.org Errors-To: xen-api-bounces@lists.xen.org Xen Project Document Day is here! Join us as we seek to make our Wiki more accurate and useful! On Mon, Jul 27, 2015 at 11:52 PM, Russ Pavlicek wrote: > Our next Xen Project Document Day is this Wednesday, July 29! > > Our THEME OF THE MONTH: "The Reverse Yard Sale" > > For many of us in the northern hemisphere, this is the time of year > when people sort through the things they own and put the things they > no longer need into a yard sale. Well, instead of removing things we > don't need, we want a reverse yard sale, where we add the things we > *do* need. Some topics to address include: > > - Hyper: the new hypervisor-independent Docker engine which uses Xen > Project (among other hypervisors); we need a basic document on how to > use Xen Project with Hyper > - XAPI: The latest docs from the XenServer crew need to be referenced > from our wiki > - Unikernels: Lots of Unikernels leverage Xen Project; we need them > properly linked in to our wiki > - Booting with UEFI: needs to be made current > - Raisin: the new effort has a new wiki page which needs review > - and anything else which needs to be added > > All the information you need to participate in Document Day is here: > > http://wiki.xenproject.org/wiki/Xen_Document_Days > > Also take a look at the current TODO list to see other items which > need attention: > > http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO > > Please think about how you can help out. If you haven't requested > to be made a Wiki editor, save time and do it now so you are ready to > go on Document Day. Just fill out the form below: > > http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html > > We hope to see you Wednesday in #xendocs! _______________________________________________ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api