That's wrong because they exist also a thread option for processor (we
don't use it currently).
That is the point, i believe that incomplete options that aren't use it
currently in the PVE GUI can do a confusion for those with less knowledges,
and finally, will run their VMs more slowly.
full
Are there any proposal for a place to put a piece of code for restore snapshot
during startup ?
Probably the place where the option start at boot is evaluated.
Please point me to this place
With kind regards
Immo
___
pve-devel mailing list
pve-deve
Thanks,I'll try to look at them tomorrow.
(BTW, I'm going to holidays for 2 weeks at the end of this week)
- Mail original -
De: "Wolfgang Bumiller"
À: "pve-devel"
Envoyé: Lundi 6 Juillet 2015 13:43:37
Objet: [pve-devel] [RFC PATCH v7 0/4] cloudinit via regular storage syntax
Changes s
From: Alexandre Derumier
when we change ip address, network configuration is correctly writen in guest,
but cloud-init don't apply it and keep previous ip address.
workaround with forcing ifdown ifup
Signed-off-by: Alexandre Derumier
---
PVE/QemuServer.pm | 3 +++
1 file changed, 3 insertions
Changes since v6:
* Removed 'cloudinit' standalone option.
* Searching for a cloudinit storage disk from the config.
See the FIXME from the commit message of patch 4/4:
> Config drives are recognized by their storage name of the
> form: VMID/vm-VMID-cloudinit.qcow2
> Example:
> ahci0: local:112/vm
The config-disk is now generated into a qcow2 located on a
configured storage.
It is now also storage-managed and so live-migration and
live-snapshotting should work as they do for regular hard
drives.
Config drives are recognized by their storage name of the
form: VMID/vm-VMID-cloudinit.qcow2
Exam
* Add ipconfigX for all netX configuration options and
using ip=CIDR, gw=IP, ip6=CIDR, gw6=IP as option names
like in LXC.
* Adding explicit ip=dhcp and ip6=dhcp options.
* Removing the config-update code and instead generating
the ide3 commandline in config_to_command.
- Adding a co
From: Alexandre Derumier
Signed-off-by: Alexandre Derumier
---
PVE/QemuServer.pm | 181 +-
control.in| 2 +-
2 files changed, 179 insertions(+), 4 deletions(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index ab9ac74..7956c5
> ahciX : local:vm-xxx-cloudinit
That would work. Just need to find a way to implement it without
changing too much.
> >>maybe could we add some kind of api to generate the configdrive once ?
> >>something like : ( enable|disable) cloudinit api : create|delete the
> >>config drive on selected
>>maybe could we add some kind of api to generate the configdrive once ?
>>something like : ( enable|disable) cloudinit api : create|delete the config
>>drive on selected interface.
maybe simply extend : qm set xxx -(sata|ide|virtio)X storeid:configdrive
- Mail original -
De: "ade
>>the idea of changing the config when starting a VM is weird. It makes
>>everything more complicated to handle.
>>It would be nicer if the user was presented with an interface similar to
>>when adding CDROMs: They'd choose a controler (IDE/SATA/...) and the
>>disk gets added to it.
>>From the
> +if( $scfg->{path}) {
> + $name .= ".qcow2";
> + $fmt = 'qcow2';
> +}else{
> + $fmt = 'raw';
> +}
This looks like a weird condition?
> +$conf->{cloudinitdrive0} = PVE::QemuServer::print_drive($vmid, $drive);
> +update_config_nolock($vmid, $conf);
The idea of cha
>>Maybe will be better change the terms in the GUI of PVE, ie, for create or
>>change the CPU configuration, instead say "Cores", must say "Threads of
>>Processor", of this mode, all people will know that the threads also are
>>considered when should choose the configuration more right.
That's
13 matches
Mail list logo
