[pve-devel] [PATCH] Implement pending change

Alexandre DERUMIER aderumier at odiso.com
Mon Oct 27 12:20:00 CET 2014


>>Wouldn't it be easier to add an 'delete' option, like:
>>
>>[PENDING]
>>delete: ostype, net0, ide2

yes, no objection


>># qm set VMID --delete ostype,net0,ide2 
>>So a 'qm commit' (see below) just translates [PENDING] into "qm set"? 

mmm, I need to think about it. (my main problem is for disks tracking)


>>Or what is the advantage to allocate immediately?

Because we can do hotplug.
So I create the disk, put in pending.
Then if hotplug fail, we keep the device in pending.

(I could even be possible to always enable hotplug by default with this method)

>>And why do you want to maintain a list of unused disks inside [PENDING]? 

because we can delete and add a new disk on same id. (or swap it)
If I don't maintain a list of unused disk and use delete:


[CONF]
virtio0

-delete the disk

[CONF]
virtio0
[PENDING]
delete : virtio0

now add a new disk on virtio0

[CONF]
virtio0: new disk
[PENDING]
delete: virtio0


So, what happen here ? I lost the reference of previous disk, and I will delete the new disk on pending commit.






----- Mail original ----- 

De: "Dietmar Maurer" <dietmar at proxmox.com> 
À: "Alexandre Derumier" <aderumier at odiso.com>, pve-devel at pve.proxmox.com 
Envoyé: Lundi 27 Octobre 2014 11:30:32 
Objet: RE: [pve-devel] [PATCH] Implement pending change 

Hi Aleandre, comments inline: 

> -----Original Message----- 
> From: pve-devel [mailto:pve-devel-bounces at pve.proxmox.com] On Behalf Of 
> Alexandre Derumier 
> Sent: Mittwoch, 22. Oktober 2014 10:04 
> To: pve-devel at pve.proxmox.com 
> Subject: [pve-devel] [PATCH] Implement pending change 
> 
> This add a new section pending 
> 
> [PENDING] 
> 
> When we change an option, it's always write in pending section first, then 
> if the vm is not running, 
> or if the vm is running and the option|device can be change online we remove 
> it from pending and update the main config 
> 
> On delete, 
> -disks as marked as unused in pending 
> -options are marked as 'delete' in pending, 

Wouldn't it be easier to add an 'delete' option, like: 

[PENDING] 
delete: ostype, net0, ide2 

The also use a 'delete' property on the CLI, for example 

# qm set VMID --delete ostype,net0,ide2 

So a 'qm commit' (see below) just translates [PENDING] into "qm set"? 

> The pending changes are applied on vm_stop and vm_start. 
> (maybe could we add an api to manually apply pending changes when vm is 
> stopped) 

yes, maybe 

# qm commit VMID 

> some examples: 
> 
> delete option 
> ------------- 
> [CONF] 
> ostype: l26 
> 
> qm set -delete ostype 
> 
> [CONF] 
> ostype: l26 
> [PENDING] 
> osdtype : delete 

delete: ostype 

> 
> delete disk 
> ----------- 
> [CONF] 
> virtio1 : local:100/vm-100-disk-1.raw,format=raw 
> 
> qm set -delete virtio1 
> 
> [CONF] 
> virtio1 : local:100/vm-100-disk-1.raw,format=raw 
> [PENDING] 
> unused0 : local:100/vm-100-disk-1.raw,format=raw 

delete: virtio1 

Or why is 'unsedX' better? 

> swap disk with unused disk 
> -------------------------- 
> [CONF] 
> unused0 : local:100/vm-100-disk-2.raw,format=raw 
> virtio1 : local:100/vm-100-disk-1.raw,format=raw 
> 
> qm set 100 -virtio1 local:100/vm-100-disk-2.raw 
> 
> [CONF] 
> unused0 : local:100/vm-100-disk-2.raw,format=raw 
> virtio1 : local:100/vm-100-disk-1.raw,format=raw 
> [PENDING] 
> unused1 : local:100/vm-100-disk-1.raw,format=raw 
> virtio1 : local:100/vm-100-disk-2.raw,format=raw 
> 
> update: swap disk with new disk 
> -------------------------- 
> [CONF] 
> virtio1 : local:100/vm-100-disk-1.raw,format=raw 
> 
> qm set 100 -virtio1 local:1 
> 
> [CONF] 
> virtio1 : local:100/vm-100-disk-1.raw,format=raw 
> [PENDING] 
> unused1 : local:100/vm-100-disk-1.raw,format=raw 
> virtio1 : local:100/vm-100-disk-2.raw,format=raw 

[CONF] 
virtio1 : local:100/vm-100-disk-1.raw,format=raw 
[PENDING] 
virtio1: local:1 

Or what is the advantage to allocate immediately? And why do you want 
to maintain a list of unused disks inside [PENDING]? 



More information about the pve-devel mailing list