Re: [pve-devel] possible problem with drive-mirror and block-job-completed
Some news:
I can't reproduce on my side currently (doing fio in guest when doing the disk
migrate).
If the target is slower, the migration %progression goes up and down, but when
I'm catching 100% it's ok.
Now, I have tell to the user forum to put a sleep, just before the
block-job-complete, and it's seem to resolve the problem.
So, maybe it's just a race condition, timeframe is short, but it's possible
s-common.offset = end * BDRV_SECTOR_SIZE; #from here we can call the
block-job-complete in proxmox code
if (!s-synced) {
block_job_event_ready(s-common);
s-synced = true;
#but only from here it's ok
}
I don't known how much time take block_job_event_ready, to sent the event (I
think it's async, but I'm not sure)
I don't known if we could add something like
s-synced = true;
s-common.synced = true;
to get the sync status in query-block-job
- Mail original -
De: Alexandre DERUMIER aderum...@odiso.com
À: Dietmar Maurer diet...@proxmox.com
Cc: pve-devel@pve.proxmox.com
Envoyé: Jeudi 2 Octobre 2014 10:03:45
Objet: Re: [pve-devel] possible problem with drive-mirror and
block-job-completed
Would you mind to ask on the qemu list?
Yes,I ll try to reproduce first, to be sure
- Mail original -
De: Dietmar Maurer diet...@proxmox.com
À: Alexandre DERUMIER aderum...@odiso.com
Cc: pve-devel@pve.proxmox.com
Envoyé: Jeudi 2 Octobre 2014 10:01:23
Objet: RE: [pve-devel] possible problem with drive-mirror and
block-job-completed
So, I think current proxmox code detection is correct ?
last if ($stat-{len} == $stat-{offset});
Would you mind to ask on the qemu list?
Maybe it could be possible to retrieve the synced property without event,
with some hack ?
I guess that is possible, because current code ($stat-{len} ==
$stat-{offset}) does the same thing.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH] Add CT suspend/resume to PVE API
First, thanks for the patch. But please can you split the patch into smaller
ones?
Signed-off-by: Dan Hunsaker danhunsa...@gmail.com
---
PVE/API2/OpenVZ.pm| 308
+++---
PVE/OpenVZ.pm | 92 -
bin/pvectl| 16 ++-
www/manager/Utils.js | 80 +--
www/manager/openvz/CmdMenu.js | 28 +++-
www/manager/qemu/CmdMenu.js | 26 +++-
www/mobile/OpenVzSummary.js | 30 ++--
www/mobile/QemuSummary.js | 34 +++--
8 files changed, 401 insertions(+), 213 deletions(-)
diff --git a/PVE/API2/OpenVZ.pm b/PVE/API2/OpenVZ.pm
index 184ebdf..5d8c0c6 100644
--- a/PVE/API2/OpenVZ.pm
+++ b/PVE/API2/OpenVZ.pm
@@ -71,7 +71,7 @@ my $get_container_storage = sub {
my $check_ct_modify_config_perm = sub {
my ($rpcenv, $authuser, $vmid, $pool, $key_list) = @_;
-
+
And there are tons of white-space changes. Please remove them first.
- Dietmar
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] possible problem with drive-mirror and block-job-completed
Now, I have tell to the user forum to put a sleep, Maybe the user uses old qemu-kvm? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] possible problem with drive-mirror and block-job-completed
Maybe the user uses old qemu-kvm? I'll ask . Do you have seen something new in last qemu-kvm ? - Mail original - De: Dietmar Maurer diet...@proxmox.com À: Alexandre DERUMIER aderum...@odiso.com Cc: pve-devel@pve.proxmox.com Envoyé: Vendredi 3 Octobre 2014 08:33:11 Objet: RE: [pve-devel] possible problem with drive-mirror and block-job-completed Now, I have tell to the user forum to put a sleep, Maybe the user uses old qemu-kvm? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] possible problem with drive-mirror and block-job-completed
I'll ask . Do you have seen something new in last qemu-kvm ? Maybe this one: http://lists.nongnu.org/archive/html/qemu-stable/2014-08/msg00189.html ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] possible problem with drive-mirror and block-job-completed
Maybe this one: http://lists.nongnu.org/archive/html/qemu-stable/2014-08/msg00189.html Yes, indeed, could be related. So qemu 2.1.1. Mail original - De: Dietmar Maurer diet...@proxmox.com À: Alexandre DERUMIER aderum...@odiso.com Cc: pve-devel@pve.proxmox.com Envoyé: Vendredi 3 Octobre 2014 09:40:20 Objet: RE: [pve-devel] possible problem with drive-mirror and block-job-completed I'll ask . Do you have seen something new in last qemu-kvm ? Maybe this one: http://lists.nongnu.org/archive/html/qemu-stable/2014-08/msg00189.html ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH] Add CT suspend/resume to PVE API
I noticed the whitespace changes after I sent this one, and resent it
without them shortly after. Sent a reply that I was going to resend, but
it seems not all my emails get through to the list?
How would you recommend I split the changes? They're all related directly
to providing suspend/resume support.
On Oct 3, 2014 12:25 AM, Dietmar Maurer diet...@proxmox.com wrote:
First, thanks for the patch. But please can you split the patch into
smaller ones?
Signed-off-by: Dan Hunsaker danhunsa...@gmail.com
---
PVE/API2/OpenVZ.pm| 308
+++---
PVE/OpenVZ.pm | 92 -
bin/pvectl| 16 ++-
www/manager/Utils.js | 80 +--
www/manager/openvz/CmdMenu.js | 28 +++-
www/manager/qemu/CmdMenu.js | 26 +++-
www/mobile/OpenVzSummary.js | 30 ++--
www/mobile/QemuSummary.js | 34 +++--
8 files changed, 401 insertions(+), 213 deletions(-)
diff --git a/PVE/API2/OpenVZ.pm b/PVE/API2/OpenVZ.pm
index 184ebdf..5d8c0c6 100644
--- a/PVE/API2/OpenVZ.pm
+++ b/PVE/API2/OpenVZ.pm
@@ -71,7 +71,7 @@ my $get_container_storage = sub {
my $check_ct_modify_config_perm = sub {
my ($rpcenv, $authuser, $vmid, $pool, $key_list) = @_;
-
+
And there are tons of white-space changes. Please remove them first.
- Dietmar
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH] Add CT suspend/resume to PVE API
How would you recommend I split the changes? They're all related directly to providing suspend/resume support. 1.) Implement suspend/resume API 2.) add it to pvectl 3.) Implement suspend/resume GUI (extjs) 4.) Implement suspend/resume GUI (mobile) Alright, I'll make that happen tomorrow. Currently just after 02:00 here. :-) I also have some further ideas. Currently qemu suspend/resume does not save state to disk. It would be great to implement that also. I'll have to research that some, but I should be able to write a patch for that as well. Then implement an option in datacenter.cfg like: reboot: stop|suspend So that VMs are suspended while we reboot a host. What do you think? That would probably save a *lot* of time bringing servers back up after reboot. I'll look into that as well, probably next week. To go another step with that logic, I wonder if there might be a benefit to modifying QEMU migrations so they suspend with state, transfer the suspended VM, and resume on the destination node. I could see an advanced implementation where VM snapshots are taken periodically, and if the node experiences a power failure, the VM could resume from the snapshot. HA failover could take advantage of the same snapshots in the same way, thereby (hopefully) losing less data, and possibly resulting in less downtime. This would definitely need to be an option enabled on VMs that would benefit from such an approach, rather than enabled universally, and is advanced enough it might remain in the realm of third-party scripts or packages, but it still might be useful. Before I get too far into the QEMU suspend-with-state patch, I want to ask - does OpenVZ support suspend-with-state? Might be nice to support that in the patch, too, if it does. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH] Add CT suspend/resume to PVE API
1.) Implement suspend/resume API 2.) add it to pvectl 3.) Implement suspend/resume GUI (extjs) 4.) Implement suspend/resume GUI (mobile) Alright, I'll make that happen tomorrow. Currently just after 02:00 here. :-) Thanks! I also have some further ideas. Currently qemu suspend/resume does not save state to disk. It would be great to implement that also. I'll have to research that some, but I should be able to write a patch for that as well. Then implement an option in datacenter.cfg like: reboot: stop|suspend So that VMs are suspended while we reboot a host. What do you think? That would probably save a *lot* of time bringing servers back up after reboot. I'll look into that as well, probably next week. OK To go another step with that logic, I wonder if there might be a benefit to modifying QEMU migrations so they suspend with state, transfer the suspended VM, and resume on the destination node. This is how migrate works (basically). Or what is the difference? I could see an advanced implementation where VM snapshots are taken periodically, and if the node experiences a power failure, the VM could resume from the snapshot. HA failover could take advantage of the same snapshots in the same way, thereby (hopefully) losing less data, and possibly resulting in less downtime. This would definitely need to be an option enabled on VMs that would benefit from such an approach, rather than enabled universally, and is advanced enough it might remain in the realm of third-party scripts or packages, but it still might be useful. Before I get too far into the QEMU suspend-with-state patch, I want to ask - does OpenVZ support suspend-with-state? Might be nice to support that in the patch, too, if it does. You already implemented that! chkpnt CTID [--dumpfile name] This command saves a complete state of a running container to a dump file, and stops the container. If an option --dumpfile is not set, default dump file name /vz/dump/Dump.CTID is used. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH] Add CT suspend/resume to PVE API
Actually, that part wasn't me, but since the answer is yes, I'll look into getting QEMU to save state to disk so we can do the rest. :-) And now to sleep, finally... On Oct 3, 2014 2:53 AM, Dietmar Maurer diet...@proxmox.com wrote: 1.) Implement suspend/resume API 2.) add it to pvectl 3.) Implement suspend/resume GUI (extjs) 4.) Implement suspend/resume GUI (mobile) Alright, I'll make that happen tomorrow. Currently just after 02:00 here. :-) Thanks! I also have some further ideas. Currently qemu suspend/resume does not save state to disk. It would be great to implement that also. I'll have to research that some, but I should be able to write a patch for that as well. Then implement an option in datacenter.cfg like: reboot: stop|suspend So that VMs are suspended while we reboot a host. What do you think? That would probably save a *lot* of time bringing servers back up after reboot. I'll look into that as well, probably next week. OK To go another step with that logic, I wonder if there might be a benefit to modifying QEMU migrations so they suspend with state, transfer the suspended VM, and resume on the destination node. This is how migrate works (basically). Or what is the difference? I could see an advanced implementation where VM snapshots are taken periodically, and if the node experiences a power failure, the VM could resume from the snapshot. HA failover could take advantage of the same snapshots in the same way, thereby (hopefully) losing less data, and possibly resulting in less downtime. This would definitely need to be an option enabled on VMs that would benefit from such an approach, rather than enabled universally, and is advanced enough it might remain in the realm of third-party scripts or packages, but it still might be useful. Before I get too far into the QEMU suspend-with-state patch, I want to ask - does OpenVZ support suspend-with-state? Might be nice to support that in the patch, too, if it does. You already implemented that! chkpnt CTID [--dumpfile name] This command saves a complete state of a running container to a dump file, and stops the container. If an option --dumpfile is not set, default dump file name /vz/dump/Dump.CTID is used. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Task List Migration
Migrate the VM then migrate the logs for that VM. Or use some sort of central logging system/distributed database. A distributed NoSQL database seems like a good place to store the task logs, each task can simply be a document. Three ways to deal with task logs when a VM is deleted: a) never reuse a VMID or b) Delete all task logs for that VM when it is deleted or c)generate a GUID on VM creation, store GUID in the VM conf file. Include GUID as part of the log index eg VMID+GUID If VM is deleted and VMID reused, the tasks with the old GUID would not be displayed for the same VMID with new GUID On Thu, Oct 2, 2014 at 3:18 PM, Dietmar Maurer diet...@proxmox.com wrote: I also like the rsync logs on migration. The only missing part is HA migration here. Can i ignore this one? So you would also need to sync the log on VM start. But from which node ?? What do you think regarding deletion of VM? no opinion ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] Whislist
Hi guys It would be nice if Proxmox came with some monitoring tool, like Centreon, Nagios, Zabbix or Zenoss, to monitoring some resources... I remember that OpenQRM has Nagios build in to monitoring VM's and others stuff... Gilberto Ferreira ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] roadmap for proxmox 3.4 ?
- basic virtio dataplane support (seem that only block jobs are missing now, hotplug,resize,throttling,migration are working fine) about dataplane, blockjobs are coming for qemu 2.2. (first patches already sent to the mailing some days ago) I have talked with paolo, and the roadmap seem to implement all features to dataplane. (and make it the default in the future) - Mail original - De: Alexandre DERUMIER aderum...@odiso.com À: Dietmar Maurer diet...@proxmox.com Cc: pve-devel@pve.proxmox.com Envoyé: Mardi 30 Septembre 2014 11:20:04 Objet: Re: [pve-devel] roadmap for proxmox 3.4 ? - basic virtio dataplane support (seem that only block jobs are missing now, hotplug,resize,throttling,migration are working fine) is that already stable? And is it really faster? yes, the command line is stable now. (no more x-dataplane, it's use -object iothread,id=iothread0 -device virtio-blk-pci,iothread=iothread0,...). I'm going to do some tests next month. Performance are faster, but you need a really fast storage. ( 100.000 iops ;). Maybe it's use less cpu too. So usage is really specific. (for big database for example) - some kind of task scheduler, to automate config changes at specific time (like cpu hotplug,memory hotplug) Mind to elaborate on that a bit more? For their activity, they now that at a specific date, they need a lot more cpu/ram for a specific vm, so they would like to be able to plan auto upgrade memory,cpu at a specific date. (for example, at the begin of the month, they need to compute billing which take a lot of cpu for 2 days) This could be done with cronjobs and qm set ..., but they would like something more integrated. (so, I thinked about something more generic, like a target config which could be applied at a specific date (online hotplug,or offline with vm stop/start). - Mail original - De: Dietmar Maurer diet...@proxmox.com À: Alexandre DERUMIER aderum...@odiso.com, pve-devel@pve.proxmox.com Envoyé: Mardi 30 Septembre 2014 09:55:26 Objet: RE: [pve-devel] roadmap for proxmox 3.4 ? What I have in mind (no priority order) : - ipv6 support (firewall and also pveproxy (maybe other daemons too)) +1 - config pending changes. (and improve hotplug) +1 - memory hotplug support (I have already working patches, I'll send them soon) great - basic virtio dataplane support (seem that only block jobs are missing now, hotplug,resize,throttling,migration are working fine) is that already stable? And is it really faster? During my training last week, I have add some features request from Sisteer company - vm auto balancing scheduler (I also need this feature) - allow network change through gui without reboot (I think it could be easy for bridge without any tap plugged) IMHO this one is really hard to do it right... - some kind of task scheduler, to automate config changes at specific time (like cpu hotplug,memory hotplug) Mind to elaborate on that a bit more? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] roadmap for proxmox 3.4 ?
On Tue, 30 Sep 2014 08:22:04 +0200 (CEST) Alexandre DERUMIER aderum...@odiso.com wrote: Now that proxmox 3.3 , maybe could it be a good time to send features ideas for proxmox 3.4 ? Will there be a prioritiesed list published somewhere? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael at rasmussen dot cc http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD3C9A00E mir at datanom dot net http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE501F51C mir at miras dot org http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE3E80917 -- /usr/games/fortune -es says: There's no use in having a dog and doing your own barking. pgpr1y6QvuO6Y.pgp Description: OpenPGP digital signature ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] roadmap for proxmox 3.4 ?
about dataplane, blockjobs are coming for qemu 2.2. (first patches already sent to the mailing some days ago) I have talked with paolo, and the roadmap seem to implement all features to dataplane. (and make it the default in the future) Great! Thanks for the update. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] roadmap for proxmox 3.4 ?
I would like to see migration between non-shared storage. I can even prepare patches if anyone will help me with where to start. On Fri, Oct 3, 2014 at 6:50 PM, Dietmar Maurer diet...@proxmox.com wrote: about dataplane, blockjobs are coming for qemu 2.2. (first patches already sent to the mailing some days ago) I have talked with paolo, and the roadmap seem to implement all features to dataplane. (and make it the default in the future) Great! Thanks for the update. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel -- Kamil Trzciński ayu...@ayufan.eu www.ayufan.eu ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 1/4] Add CT suspend/resume support via PVE2 API
From: Dan Hunsaker danhunsa...@gmail.com
Suspend/resume support for VMs has been in the PVE2 API for some time,
but even though vzctl supports suspend/resume (what they call checkpoint/
restore), the API doesn't yet support suspend/resume for CTs. This patch
adds that support.
Signed-off-by: Dan Hunsaker danhunsa...@gmail.com
---
PVE/API2/OpenVZ.pm | 96 ++
PVE/OpenVZ.pm | 26 ++-
2 files changed, 121 insertions(+), 1 deletion(-)
diff --git a/PVE/API2/OpenVZ.pm b/PVE/API2/OpenVZ.pm
index 184ebdf..5d8c0c6 100644
--- a/PVE/API2/OpenVZ.pm
+++ b/PVE/API2/OpenVZ.pm
@@ -1459,6 +1459,102 @@ __PACKAGE__-register_method({
}});
__PACKAGE__-register_method({
+ name = 'vm_suspend',
+ path = '{vmid}/status/suspend',
+ method = 'POST',
+ protected = 1,
+ proxyto = 'node',
+ description = Suspend the container.,
+ permissions = {
+ check = ['perm', '/vms/{vmid}', [ 'VM.PowerMgmt' ]],
+ },
+ parameters = {
+ additionalProperties = 0,
+ properties = {
+ node = get_standard_option('pve-node'),
+ vmid = get_standard_option('pve-vmid'),
+ },
+ },
+ returns = {
+ type = 'string',
+ },
+ code = sub {
+ my ($param) = @_;
+
+ my $rpcenv = PVE::RPCEnvironment::get();
+
+ my $authuser = $rpcenv-get_user();
+
+ my $node = extract_param($param, 'node');
+
+ my $vmid = extract_param($param, 'vmid');
+
+ die CT $vmid not running\n if
!PVE::OpenVZ::check_running($vmid);
+
+ my $realcmd = sub {
+ my $upid = shift;
+
+ syslog('info', suspend CT $vmid: $upid\n);
+
+ PVE::OpenVZ::vm_suspend($vmid);
+
+ return;
+ };
+
+ my $upid = $rpcenv-fork_worker('vzsuspend', $vmid, $authuser,
$realcmd);
+
+ return $upid;
+ }});
+
+__PACKAGE__-register_method({
+ name = 'vm_resume',
+ path = '{vmid}/status/resume',
+ method = 'POST',
+ protected = 1,
+ proxyto = 'node',
+ description = Resume the container.,
+ permissions = {
+ check = ['perm', '/vms/{vmid}', [ 'VM.PowerMgmt' ]],
+ },
+ parameters = {
+ additionalProperties = 0,
+ properties = {
+ node = get_standard_option('pve-node'),
+ vmid = get_standard_option('pve-vmid'),
+ },
+ },
+ returns = {
+ type = 'string',
+ },
+ code = sub {
+ my ($param) = @_;
+
+ my $rpcenv = PVE::RPCEnvironment::get();
+
+ my $authuser = $rpcenv-get_user();
+
+ my $node = extract_param($param, 'node');
+
+ my $vmid = extract_param($param, 'vmid');
+
+ die CT $vmid already running\n if
PVE::OpenVZ::check_running($vmid);
+
+ my $realcmd = sub {
+ my $upid = shift;
+
+ syslog('info', resume CT $vmid: $upid\n);
+
+ PVE::OpenVZ::vm_resume($vmid);
+
+ return;
+ };
+
+ my $upid = $rpcenv-fork_worker('vzresume', $vmid, $authuser,
$realcmd);
+
+ return $upid;
+ }});
+
+__PACKAGE__-register_method({
name = 'migrate_vm',
path = '{vmid}/migrate',
method = 'POST',
diff --git a/PVE/OpenVZ.pm b/PVE/OpenVZ.pm
index aa6f502..fcfb0c2 100644
--- a/PVE/OpenVZ.pm
+++ b/PVE/OpenVZ.pm
@@ -6,7 +6,7 @@ use File::stat qw();
use POSIX qw (LONG_MAX);
use IO::Dir;
use IO::File;
-use PVE::Tools qw(extract_param $IPV6RE $IPV4RE);
+use PVE::Tools qw(run_command extract_param $IPV6RE $IPV4RE);
use PVE::ProcFSTools;
use PVE::Cluster qw(cfs_register_file cfs_read_file);
use PVE::SafeSyslog;
@@ -1220,6 +1220,30 @@ sub lock_container {
return $res;
}
+sub vm_suspend {
+my ($vmid) = @_;
+
+my $cmd = ['vzctl', 'chkpnt', $vmid];
+
+eval { run_command($cmd); };
+if (my $err = $@) {
+syslog(err, CT $vmid suspend failed - $err);
+die $err;
+}
+}
+
+sub vm_resume {
+my ($vmid) = @_;
+
+my $cmd = ['vzctl', 'restore', $vmid];
+
+eval { run_command($cmd); };
+if (my $err = $@) {
+syslog(err, CT $vmid resume failed - $err);
+die $err;
+}
+}
+
sub replacepw {
my ($file, $epw) = @_;
--
1.9.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] Resubmit PVE API suspend/resume patch
One more time, as separate patches. This will let us suspend and resume all guests, VM and CT alike, via the API. That in turn will let us do fancy things like suspend guests before node restart, then resume them after (though first we need to get QEMU suspend to save the state to disk). [PATCH 1/4] Add CT suspend/resume support via PVE2 API [PATCH 2/4] Add suspend/resume support to pvectl [PATCH 3/4] Add suspend/resume options to web UI CmdMenus [PATCH 4/4] Add suspend/resume options to the mobile web UI menus ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 2/4] Add suspend/resume support to pvectl
From: Dan Hunsaker danhunsa...@gmail.com
Now that the API supports CT suspend/resume, it makes sense to have pvectl
support it, too. It *does* use different names than vzctl does, but it
seems to make sense to be consistent with the API naming in a PVE utility.
Signed-off-by: Dan Hunsaker danhunsa...@gmail.com
---
bin/pvectl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/bin/pvectl b/bin/pvectl
index f8ae3ad..9e9a797 100755
--- a/bin/pvectl
+++ b/bin/pvectl
@@ -74,6 +74,8 @@ my $cmddef = {
}],
start = [ 'PVE::API2::OpenVZ', 'vm_start', ['vmid'], { node = $nodename
}, $upid_exit],
+suspend = [ 'PVE::API2::OpenVZ', 'vm_suspend', ['vmid'], { node =
$nodename }, $upid_exit],
+resume = [ 'PVE::API2::OpenVZ', 'vm_resume', ['vmid'], { node =
$nodename }, $upid_exit],
shutdown = [ 'PVE::API2::OpenVZ', 'vm_shutdown', ['vmid'], { node =
$nodename }, $upid_exit],
stop = [ 'PVE::API2::OpenVZ', 'vm_stop', ['vmid'], { node = $nodename },
$upid_exit],
mount = [ 'PVE::API2::OpenVZ', 'vm_mount', ['vmid'], { node = $nodename
}, $upid_exit],
--
1.9.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 3/4] Add suspend/resume options to web UI CmdMenus
From: Dan Hunsaker danhunsa...@gmail.com
The PVE2 API supports suspend/resume of VMs (and now CTs), but the web UI
doesn't make these options available. This patch adds Suspend and Resume
items to the CmdMenus of OpenVZ and QEMU guests. I considered adding the
options to the toolbar, but since it is already pretty full, I opted
against doing so for the moment. Perhaps the various startup options can
be combined into a dropdown menu similar to how the console options are
set up, and the various shutdown opitons combined into another. That
would provide the necesarry space to add the Suspend and Resume options
there.
This patch also provides descriptions for Suspend and Resume tasks in the
task logs, bringing full suspend/resume support to the web GUI.
Signed-off-by: Dan Hunsaker danhunsa...@gmail.com
---
www/manager/Utils.js | 2 ++
www/manager/openvz/CmdMenu.js | 24 ++--
www/manager/qemu/CmdMenu.js | 20
3 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/www/manager/Utils.js b/www/manager/Utils.js
index f95c180..151df32 100644
--- a/www/manager/Utils.js
+++ b/www/manager/Utils.js
@@ -510,6 +510,8 @@ Ext.define('PVE.Utils', { statics: {
vzmount: ['CT', gettext('Mount') ],
vzumount: ['CT', gettext('Unmount') ],
vzshutdown: ['CT', gettext('Shutdown') ],
+ vzsuspend: [ 'CT', gettext('Suspend') ],
+ vzresume: [ 'CT', gettext('Resume') ],
hamigrate: [ 'HA', gettext('Migrate') ],
hastart: [ 'HA', gettext('Start') ],
hastop: [ 'HA', gettext('Stop') ],
diff --git a/www/manager/openvz/CmdMenu.js b/www/manager/openvz/CmdMenu.js
index 85589ed..6bb5326 100644
--- a/www/manager/openvz/CmdMenu.js
+++ b/www/manager/openvz/CmdMenu.js
@@ -50,10 +50,30 @@ Ext.define('PVE.openvz.CmdMenu', {
}
},
{
+ text: gettext('Suspend'),
+ icon: '/pve2/images/forward.png',
+ handler: function() {
+ var msg = Ext.String.format(gettext(Do you really want to
suspend CT {0}?), vmid);
+ Ext.Msg.confirm(gettext('Confirm'), msg, function(btn) {
+ if (btn !== 'yes') {
+ return;
+ }
+ vm_command('suspend');
+ });
+ }
+ },
+ {
+ text: gettext('Resume'),
+ icon: '/pve2/images/forward.png',
+ handler: function() {
+ vm_command('resume');
+ }
+ },
+ {
text: gettext('Shutdown'),
icon: '/pve2/images/stop.png',
handler: function() {
- var msg = Ext.String.format(gettext(Do you really want to
shutdown VM {0}?), vmid);
+ var msg = Ext.String.format(gettext(Do you really want to
shutdown CT {0}?), vmid);
Ext.Msg.confirm(gettext('Confirm'), msg, function(btn) {
if (btn !== 'yes') {
return;
@@ -67,7 +87,7 @@ Ext.define('PVE.openvz.CmdMenu', {
text: gettext('Stop'),
icon: '/pve2/images/gtk-stop.png',
handler: function() {
- var msg = Ext.String.format(gettext(Do you really want to
stop VM {0}?), vmid);
+ var msg = Ext.String.format(gettext(Do you really want to
stop CT {0}?), vmid);
Ext.Msg.confirm(gettext('Confirm'), msg, function(btn) {
if (btn !== 'yes') {
return;
diff --git a/www/manager/qemu/CmdMenu.js b/www/manager/qemu/CmdMenu.js
index 853f57b..25591e9 100644
--- a/www/manager/qemu/CmdMenu.js
+++ b/www/manager/qemu/CmdMenu.js
@@ -50,6 +50,26 @@ Ext.define('PVE.qemu.CmdMenu', {
}
},
{
+text: gettext('Suspend'),
+icon: '/pve2/images/forward.png',
+handler: function() {
+var msg = Ext.String.format(gettext(Do you really want to suspend
VM {0}?), vmid);
+Ext.Msg.confirm(gettext('Confirm'), msg, function(btn) {
+if (btn !== 'yes') {
+return;
+}
+vm_command('suspend');
+});
+}
+},
+{
+text: gettext('Resume'),
+icon: '/pve2/images/forward.png',
+handler: function() {
+vm_command('resume');
+}
+},
+{
text: gettext('Shutdown'),
icon: '/pve2/images/stop.png',
handler: function() {
--
1.9.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 4/4] Add suspend/resume options to the mobile web UI menus
From: Dan Hunsaker danhunsa...@gmail.com
With the new mobile interface, we need to implement UI changes in two
places. This lets us simplify our mobile interface so it isn't cluttered
with options that mobile browsers can't easily handle, usually due to size.
This patch implements Suspend and Resume of VMs and CTs via the mobile
web UI.
Signed-off-by: Dan Hunsaker danhunsa...@gmail.com
---
www/mobile/OpenVzSummary.js | 12
www/mobile/QemuSummary.js | 12
2 files changed, 24 insertions(+)
diff --git a/www/mobile/OpenVzSummary.js b/www/mobile/OpenVzSummary.js
index f71fbec..4c27e93 100644
--- a/www/mobile/OpenVzSummary.js
+++ b/www/mobile/OpenVzSummary.js
@@ -159,6 +159,18 @@ Ext.define('PVE.OpenVzSummary', {
}
},
{
+ text: gettext('Suspend'),
+ handler: function() {
+ me.vm_command(suspend, {});
+ }
+ },
+ {
+ text: gettext('Resume'),
+ handler: function() {
+ me.vm_command(resume, {});
+ }
+ },
+ {
text: gettext('Shutdown'),
handler: function() {
me.vm_command(shutdown, {});
diff --git a/www/mobile/QemuSummary.js b/www/mobile/QemuSummary.js
index eb33222..b392e1e 100644
--- a/www/mobile/QemuSummary.js
+++ b/www/mobile/QemuSummary.js
@@ -162,6 +162,18 @@ Ext.define('PVE.QemuSummary', {
}
},
{
+ text: gettext('Suspend'),
+ handler: function() {
+ me.vm_command(suspend, {});
+ }
+ },
+ {
+ text: gettext('Resume'),
+ handler: function() {
+ me.vm_command(resume, {});
+ }
+ },
+ {
text: gettext('Shutdown'),
handler: function() {
me.vm_command(shutdown, {});
--
1.9.1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] roadmap for proxmox 3.4 ?
It's possible, because I were doing it already, but only from command line. Qemu basically transfers all disks and memory state over network. On Fri, Oct 3, 2014 at 8:47 PM, Gilberto Nunes gilberto.nune...@gmail.com wrote: I think that is not possible... Or may I wrong? 2014-10-03 15:12 GMT-03:00 Kamil Trzciński ayu...@ayufan.eu: I would like to see migration between non-shared storage. I can even prepare patches if anyone will help me with where to start. On Fri, Oct 3, 2014 at 6:50 PM, Dietmar Maurer diet...@proxmox.com wrote: about dataplane, blockjobs are coming for qemu 2.2. (first patches already sent to the mailing some days ago) I have talked with paolo, and the roadmap seem to implement all features to dataplane. (and make it the default in the future) Great! Thanks for the update. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel -- Kamil Trzciński ayu...@ayufan.eu www.ayufan.eu ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel -- -- Gilberto Ferreira -- Kamil Trzciński ayu...@ayufan.eu www.ayufan.eu ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] roadmap for proxmox 3.4 ?
In a pinch, even rsync would work, though it would take a while. The trouble is with HA migrations. There's a decent chance your VM is down because your node is, and you can't migrate from a storage which is offline. Still, HA is handled separately, so it shouldn't cause too many issues to support manual migrations to/from local storages. On Oct 3, 2014 2:54 PM, Gilberto Nunes gilberto.nune...@gmail.com wrote: Nice... Over DRBD, I suppose... That is clearly possible... Even over glusterfs ou DRBD+OCFS 2014-10-03 17:47 GMT-03:00 Kamil Trzciński ayu...@ayufan.eu: It's possible, because I were doing it already, but only from command line. Qemu basically transfers all disks and memory state over network. On Fri, Oct 3, 2014 at 8:47 PM, Gilberto Nunes gilberto.nune...@gmail.com wrote: I think that is not possible... Or may I wrong? 2014-10-03 15:12 GMT-03:00 Kamil Trzciński ayu...@ayufan.eu: I would like to see migration between non-shared storage. I can even prepare patches if anyone will help me with where to start. On Fri, Oct 3, 2014 at 6:50 PM, Dietmar Maurer diet...@proxmox.com wrote: about dataplane, blockjobs are coming for qemu 2.2. (first patches already sent to the mailing some days ago) I have talked with paolo, and the roadmap seem to implement all features to dataplane. (and make it the default in the future) Great! Thanks for the update. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel -- Kamil Trzciński ayu...@ayufan.eu www.ayufan.eu ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel -- -- Gilberto Ferreira -- Kamil Trzciński ayu...@ayufan.eu www.ayufan.eu -- -- Gilberto Ferreira ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Whislist
There's some RDB stuff already in the API/web UI, if that's what you're after. As far as anything more complex, it would be nice to have, but there are a number of features it's nice to leave up to sysadmins to select and implement. On Oct 3, 2014 8:28 AM, Gilberto Nunes gilberto.nune...@gmail.com wrote: Hi guys It would be nice if Proxmox came with some monitoring tool, like Centreon, Nagios, Zabbix or Zenoss, to monitoring some resources... I remember that OpenQRM has Nagios build in to monitoring VM's and others stuff... Gilberto Ferreira ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
