Yeah, an SR has metadata that knows things like its UUID, name,
description, etc. Then the VDI (a template, in this case) is laid down
inside of the SR. As far as I know, there is no way to have a VDI outside
of an SR.
It appears the UUID of an SR is immutable (unlike its name and
description). Yo
So if you create a volume and register it as an SR, there is metadata
written to the volume, in addition to simply copying the template?
What happens if you don't like that SR? Are you stuck destroying the
volume, because you can never delete the SR metadata? I assumed you
could create SR, copy te
To be clear, the cloned SAN volume will have a unique name and IQN;
however, the problem is that the data the cloned volume contains (the SR)
includes metadata for an SR that is supposed to be unique (the UUID), but
is immutable.
On Sun, Jan 26, 2014 at 11:39 AM, Mike Tutkowski <
mike.tutkow...@s
So, this is my thinking on how this cloning would work (and why it would be
a problem for an SR):
1) An SR is created on a SAN volume. The SR is essentially a clustered file
system. The VDI on the SR represents a template we downloaded from
secondary storage. The SR itself contains metadata like a
In fact I'd recommend removing the SR of the template from anything
XenServer knows of. It just needs to exist on the SAN so it can be
cloned for new SR root volumes.
On Sun, Jan 26, 2014 at 9:18 AM, Marcus Sorensen wrote:
> Hm, well I guest that's dependent on how your SAN clone works. Ours
> al
But you'd be registering a new SR. It doesn't matter that the original
volume is read-only (in fact it should be, both in name and data),
because your clones will be new SRs.
On Sun, Jan 26, 2014 at 9:17 AM, Mike Tutkowski
wrote:
> Here's a pic that shows some of the properties of an SR:
>
> http
Hm, well I guest that's dependent on how your SAN clone works. Ours
allows you to have a unique name for each clone, so we just name the
clone with the new root volume UUID.
On Sun, Jan 26, 2014 at 9:00 AM, Mike Tutkowski
wrote:
> Hey Marcus,
>
> One thing I thought of late last night was that an
Here's a pic that shows some of the properties of an SR:
http://i.imgur.com/iq6NQ1a.png
According to some Citrix docs I read, it appears the UUID is a read-only
field.
Unless there is some workaround for this, I may have to resort to copying
the template to a new SR each time.
On Sun, Jan 26,
Hey Marcus,
One thing I thought of late last night was that an SR has a UUID associated
with it.
If I clone the SAN volume that houses the SR each time, I'll be giving
XenServer SRs that have the same UUID.
I guess I'll need to look into if there is some way to assign a new UUID to
an existing S
Actually, I shouldn't take the liberty to speak as though I understand
the details about how you use SRs and VDIs. My point though is
basically that you probably can and should treat them the same as
whatever you currently do with data disks. Either create a new one
with every root volume create an
So, Marcus - it sounds like you already have this kind of functionality
working in KVM?
Perhaps it would be a good idea for me to look at it.
Thanks!
On Sat, Jan 25, 2014 at 10:33 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> 2) This is cloning the SAN volume that stores the SR i
2) This is cloning the SAN volume that stores the SR in 1).
3) This is to use the SR on the cloned volume.
On Sat, Jan 25, 2014 at 10:31 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> I see, Marcus. That is an interesting idea definitely.
>
> The process would be on a cluster-by-cl
I see, Marcus. That is an interesting idea definitely.
The process would be on a cluster-by-cluster basis:
1) Download the template to the SR.
2) Clone the SAN volume.
3) Use the new SR.
Later for a new root disk:
Just do 3.
On Sat, Jan 25, 2014 at 10:29 PM, Marcus Sorensen wrote:
> Not's
And when I say 'the first time the template is used, we create an SR',
I mean cloudstack does it automatically.
On Sat, Jan 25, 2014 at 10:29 PM, Marcus Sorensen wrote:
> Not's not really what I was describing, or that's not how we do it at
> least. The first time a template is used, we create an
Not's not really what I was describing, or that's not how we do it at
least. The first time a template is used, we create an SR with one VDI
(using your terminology as we don't do it in Xen, but it should map to
essentially the same thing) and copy the template contents into it.
Then we remove the
On a side note, as I mentioned, to get QoS on a
CloudStack-volume-by-CloudStack-volume basis, we need to use a single SAN
volume per CloudStack volume (because QoS is set at the SAN volume level)
and copy the template in question to each volume every time a new root disk
is need.
This, however, wi
Thanks for your input, Marcus.
Yeah, the SolidFire SAN has the ability to clone, but I can't use it in
this case.
Little note first: I'm going to put some words below in capital letters to
stress some important details. All caps for some words can be annoying to
some, so please understand that I
In other words, if you can't clone, then createDiskFromTemplate should
copy template from secondary storage directly onto root disk every
time, and copyPhysicalDisk really does nothing. If you can clone, then
copyPhysicalDisk should copy template to primary, and
createDiskFromTemplate should clone.
I'm not quite following. With our storage, the template gets copied
to the storage pool upon first use, and then cloned upon subsequent
uses. I don't remember all of the methods immediately, but there's one
called to copy the template to primary storage, and once that's done
as you mention it's tr
Just wanted to throw this out there before I went to bed:
Since each root volume that belongs to managed storage will get its own
copy of some template (assuming we're dealing with templates here and not
an ISO), it is possible I may be able to circumvent a new table (or any
existing table like te
20 matches
Mail list logo
