> so for vmid:100
>
> disks:
> local:100/vm-100-disk1.raw
> rbd,sheepdog: vm-100-disk-1
>
> become
>
> file: local:100/base-100-disk1.raw
> rbd,sheepdog: base-100-disk-1
>
> is it ok for you ?
Yes, that is what I thought.
> (Note: I have already more/less finish the implementation we talk ye
>>That is not a problem - you also do that with your current approach?
With my current patches, I can't attach a disk to 2 templates.
(It's just a vm with a template flag=1, disk id are attached to vm with same
vmid).
if you want, we can rename the basedisk with vmid when we convert it
And we
> >>So we have a natural grouping of those base images (all belongs to the
> same VM).
> >>
> >>Is that better?
> I don't know, because we want to attach a base image to multiple templates
> ?
That is not a problem - you also do that with your current approach?
>>So we have a natural grouping of those base images (all belongs to the same
>>VM).
>>
>>Is that better?
I don't know, because we want to attach a base image to multiple templates ?
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: pve-devel@pve.proxmox.com
En
> >>You think such system is confusing to the user?
> It's already confusing for me...
Seems you want a closer relation between 'base image' and 'template VM'.
I am not sure, but maybe we should introduce the 'owner' concept also for base
images.
normal volume: local:100/vm-100-disk-1.raw
path
> >>Seems that both sheedpdog and RBD LS returns information about parent
> >>(base).
> >>
> >>For Nexenta we already call get_zvol_props(), so we also have that
> >>info.
> >>
> >>For LVM we can use --options '...,origin' to list the base image.
> >>
> >>So we just need to implement a cache for di
De: "Dietmar Maurer"
À: "Michael Rasmussen" , "Alexandre DERUMIER
(aderum...@odiso.com)" , pve-devel@pve.proxmox.com
Envoyé: Lundi 28 Janvier 2013 07:26:05
Objet: RE: [pve-devel] template considerations
> > > One problem I see is that we do n
> > > One problem I see is that we do not want to call 'qemu-img info' for
> > > a normal content list, so that list would not include that information.
> > >
> > Could the information not be stored some how at creation time? The
> > image is read-only and as such cannot change after creation in wh
>>You think such system is confusing to the user?
It's already confusing for me...
(Maybe convert only a disk to a base image, should remove the disk from the vm
?
Or maybe convert only a disk should copy the disk to a new baseimage,and keep
the original disk.
Both avoid to mix base && non ba
> One thing I'm not sure it's about to have a "semi" template, if a vm have 2
> disks, and we convert only 1 disk to base image.
>
> When we have converted the first disk to base image, we can't start anymore
> the vm.
> But we can't clone the template because the second disk is not a base image.
> > One problem I see is that we do not want to call 'qemu-img info' for a
> > normal content list, so that list would not include that information.
> >
> Could the information not be stored some how at creation time? The image
> is read-only and as such cannot change after creation in which case t
>>Note: extending the volume name parse should be really easy?
Yes, sure no problem, we can go this way,it's just some regex to change ;)
One thing I'm not sure it's about to have a "semi" template, if a vm have 2
disks, and we convert only 1 disk to base image.
When we have converted the fir
>>Note: extending the volume name parse should be really easy?
Yes, sure no problem, we can go this way,it's just some regex to change ;)
One thing I'm not sure it's about to have a "semi" template, if a vm have 2
disks, and we convert only 1 disk to base image.
When we have converted the fir
On Sun, 27 Jan 2013 15:34:14 +
Dietmar Maurer wrote:
>
> One problem I see is that we do not want to call 'qemu-img info' for
> a normal content list, so that list would not include that information.
>
Could the information not be stored some how at creation time? The image
is read-only and
> > Oh, you want only it in config file ? (not in directory structure, or
> > volume
> > name)
>
> yes.
>
> > base volume clone of another base volume :
> > local:base/test.raw/base/test2.raw
> > local volume clone of a base volume : local:base/test.raw/100/vm-100-
> > disk1.raw
> >
> > I think i
> No, it is not needed. I just thought it is good to know?
>
> > With your proposal,how do you do if a base volume is also a clone of
> > another volume ?
>
> >>What problem do you see?
>
> Oh, you want only it in config file ? (not in directory structure, or volume
> name)
yes.
> base volume
>>You have a normal VM. Then you select a disk, press 'create template' button.
>>
>>We can then either:
>>
>>a.) replace the disk with the base image (VM is now a template,
>>because it contains read-only images)
>>
>>or
>>
>>b.) replace the disk with a clone of the base image (keeps VM worki
> >>Why do you need an ID (the name is the ID)?
>
> maybe not an idea, but if you convert a vm with 2 disks to a template. (like a
> filesystem with / on the first disk and /var on second disk), maybe we want
> to identify that these 2 disks works together.
Yes - maybe we can use something like:
> >>Maybe it is also convenient to allow to transform a single disk to a
> >>template on the GUI. The disks gets simple replaced by a clone in the
> >>VM config.
>
> I don't understand , can you provide an example ?
You have a normal VM. Then you select a disk, press 'create template' button.
We
>>Maybe it is also convenient to allow to transform a single disk
>>to a template on the GUI. The disks gets simple replaced by
>>a clone in the VM config.
I don't understand , can you provide an example ?
>>
>>
>>Another thing I am thinking about is how we can mark cloned
>>disks. I would b
>>> arbitray, really ? Doesn't we need some convention names, or ids
>>> somewhere ?
>>
>>Why do you need an ID (the name is the ID)?
maybe not an idea, but if you convert a vm with 2 disks to a template. (like a
filesystem with / on the first disk and /var on second disk),
maybe we want to id
> > >>2.) Transform an existing VM automatically.
> > >>
> >
> > >>If the user wants to modify a template, he need to:
> > >>
> > >>1.) clone/copy the VM
> > >>2.) start the VM, do any modification, then stop
> > >>3.) create a new template from that
> >
> > I could be great to rollback a template
> >>The current VM template patches heavily depend on the ‘live snapshot’
> >>feature. This works well for some storage types (rdb, sheeddog, …),
> >>but not for all. Most important it does not work well with qcow2 files.
>
> Well, my currents patches allow to do clone (clone = linked cloned) of
>
Hi Dietmar, here some comments and questions:
>>The current VM template patches heavily depend on the ‘live snapshot’
>>feature. This works well for some storage types (rdb, sheeddog, …), but
>>not for all. Most important it does not work well with qcow2 files.
Well, my currents patches allow
The current VM template patches heavily depend on the 'live snapshot'
feature. This works well for some storage types (rdb, sheeddog, ...), but
not for all. Most important it does not work well with qcow2 files.
But the major drawback is that our backup/restore does not work
well with 'live snapsh
25 matches
Mail list logo
