Re: [pve-devel] removed ISO files block migration
I think we should eject it automatically instead of do not start the machine! +1 for this. Simply do an eject before migration, if the iso is local - Mail original - De: Wolfgang Link w.l...@proxmox.com À: Stefan Priebe s.pri...@profihost.ag, pve-devel pve-devel@pve.proxmox.com Envoyé: Jeudi 20 Août 2015 09:52:34 Objet: Re: [pve-devel] removed ISO files block migration I think we should eject it automatically instead of do not start the machine! This could be done easily if we check this on start. On 08/20/2015 09:39 AM, Stefan Priebe - Profihost AG wrote: Hi, i've no real idea how to solve this. Currently the following happens pretty easily. You insert a cd iso image into your VM CD ROM. May be driver disk for windows virtio-X. Than some month later somebody updates this one from virtio-X to virtio-Y and deletes the old iso files. From now on every attempt to migrate this VM fails with: volume 'cdisoimages:iso/virtio-win-0.1-100.iso' does not exist It would be great if we can handle this. Stefan ___ 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 mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] removed ISO files block migration
Am 20.08.2015 um 09:52 schrieb Wolfgang Link: I think we should eject it automatically instead of do not start the machine! +1 Will have a look at the 3.4 code. Stefan This could be done easily if we check this on start. On 08/20/2015 09:39 AM, Stefan Priebe - Profihost AG wrote: Hi, i've no real idea how to solve this. Currently the following happens pretty easily. You insert a cd iso image into your VM CD ROM. May be driver disk for windows virtio-X. Than some month later somebody updates this one from virtio-X to virtio-Y and deletes the old iso files. From now on every attempt to migrate this VM fails with: volume 'cdisoimages:iso/virtio-win-0.1-100.iso' does not exist It would be great if we can handle this. Stefan ___ 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] [PATCH] Bugfix 688: if vm is not owner of this disk remove from config
---
PVE/QemuServer.pm | 3 +++
1 file changed, 3 insertions(+)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 5ba8e1c..7115007 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -4038,6 +4038,9 @@ sub try_deallocate_drive {
if $used_paths-{$path};
PVE::Storage::vdisk_free($storecfg, $volid);
return 1;
+ } else {
+ # If vm is not owner of this disk remove from config
+ return 1;
}
}
--
2.1.4
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] removed ISO files block migration
OK the case i have here is even more worth. The CD iso is only in a snapshot not the currently running VM. I have already see this too, livemigration hang if an local iso is in 1 of the snasphot. - Mail original - De: Stefan Priebe s.pri...@profihost.ag À: Wolfgang Link w.l...@proxmox.com, pve-devel pve-devel@pve.proxmox.com Envoyé: Jeudi 20 Août 2015 10:23:58 Objet: Re: [pve-devel] removed ISO files block migration Am 20.08.2015 um 10:05 schrieb Stefan Priebe - Profihost AG: Am 20.08.2015 um 09:52 schrieb Wolfgang Link: I think we should eject it automatically instead of do not start the machine! +1 Will have a look at the 3.4 code. OK the case i have here is even more worth. The CD iso is only in a snapshot not the currently running VM. Stefan This could be done easily if we check this on start. On 08/20/2015 09:39 AM, Stefan Priebe - Profihost AG wrote: Hi, i've no real idea how to solve this. Currently the following happens pretty easily. You insert a cd iso image into your VM CD ROM. May be driver disk for windows virtio-X. Than some month later somebody updates this one from virtio-X to virtio-Y and deletes the old iso files. From now on every attempt to migrate this VM fails with: volume 'cdisoimages:iso/virtio-win-0.1-100.iso' does not exist It would be great if we can handle this. Stefan ___ 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 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] removed ISO files block migration
I would do it this way. skip cdrom and set it.
On 08/20/2015 10:41 AM, Stefan Priebe - Profihost AG wrote:
I'm currently struggling.
There is sync_disks method in QemuMigrate.pm which might be good for
this. But the code is failing before in sub prepare calling
PVE::Storage::activate_volumes($self-{storecfg}, $vollist);
sub activate_volume {
my ($class, $storeid, $scfg, $volname, $exclusive, $cache) = @_;
my $path = $class-filesystem_path($scfg, $volname);
# check is volume exists
if ($scfg-{path}) {
die volume '$storeid:$volname' does not exist\n if ! -e $path;
So where to implement this?
Another method in prepare before calling activate_volume to cleanup the
config?
Another approach would be to skip cdroms in those checks completely and
set a cdrom in vm_start to none if the iso does not exist.
Stefan
Am 20.08.2015 um 10:33 schrieb Alexandre DERUMIER:
I think we should eject it automatically instead of do not start the
machine!
+1 for this.
Simply do an eject before migration, if the iso is local
- Mail original -
De: Wolfgang Link w.l...@proxmox.com
À: Stefan Priebe s.pri...@profihost.ag, pve-devel
pve-devel@pve.proxmox.com
Envoyé: Jeudi 20 Août 2015 09:52:34
Objet: Re: [pve-devel] removed ISO files block migration
I think we should eject it automatically instead of do not start the
machine!
This could be done easily if we check this on start.
On 08/20/2015 09:39 AM, Stefan Priebe - Profihost AG wrote:
Hi,
i've no real idea how to solve this.
Currently the following happens pretty easily.
You insert a cd iso image into your VM CD ROM. May be driver disk for
windows virtio-X.
Than some month later somebody updates this one from virtio-X to
virtio-Y and deletes the old iso files.
From now on every attempt to migrate this VM fails with:
volume 'cdisoimages:iso/virtio-win-0.1-100.iso' does not exist
It would be great if we can handle this.
Stefan
___
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 mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] removed ISO files block migration
Hi, i've no real idea how to solve this. Currently the following happens pretty easily. You insert a cd iso image into your VM CD ROM. May be driver disk for windows virtio-X. Than some month later somebody updates this one from virtio-X to virtio-Y and deletes the old iso files. From now on every attempt to migrate this VM fails with: volume 'cdisoimages:iso/virtio-win-0.1-100.iso' does not exist It would be great if we can handle this. Stefan ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] removed ISO files block migration
I think we should eject it automatically instead of do not start the machine! This could be done easily if we check this on start. On 08/20/2015 09:39 AM, Stefan Priebe - Profihost AG wrote: Hi, i've no real idea how to solve this. Currently the following happens pretty easily. You insert a cd iso image into your VM CD ROM. May be driver disk for windows virtio-X. Than some month later somebody updates this one from virtio-X to virtio-Y and deletes the old iso files. From now on every attempt to migrate this VM fails with: volume 'cdisoimages:iso/virtio-win-0.1-100.iso' does not exist It would be great if we can handle this. Stefan ___ 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] removed ISO files block migration
Hi, Part of the problem is that there isn't any ISO uploading/removing option in GUI, which is something that new users always find quite odd. Having an ISO removal option in GUI could help to check if the ISO is mounted in some VM, and refuse to remove if that is the case. Another option could be some way of listing all mounted ISOs, so that one can check this before removing the file. (would need to remember to do so though). El 20/08/15 a las 09:39, Stefan Priebe - Profihost AG escribió: Hi, i've no real idea how to solve this. Currently the following happens pretty easily. You insert a cd iso image into your VM CD ROM. May be driver disk for windows virtio-X. Than some month later somebody updates this one from virtio-X to virtio-Y and deletes the old iso files. From now on every attempt to migrate this VM fails with: volume 'cdisoimages:iso/virtio-win-0.1-100.iso' does not exist It would be great if we can handle this. Stefan ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel -- Zuzendari Teknikoa / Director Técnico Binovo IT Human Project, S.L. Telf. 943575997 943493611 Astigarraga bidea 2, planta 6 dcha., ofi. 3-2; 20180 Oiartzun (Gipuzkoa) www.binovo.es ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] removed ISO files block migration
I'm currently struggling.
There is sync_disks method in QemuMigrate.pm which might be good for
this. But the code is failing before in sub prepare calling
PVE::Storage::activate_volumes($self-{storecfg}, $vollist);
sub activate_volume {
my ($class, $storeid, $scfg, $volname, $exclusive, $cache) = @_;
my $path = $class-filesystem_path($scfg, $volname);
# check is volume exists
if ($scfg-{path}) {
die volume '$storeid:$volname' does not exist\n if ! -e $path;
So where to implement this?
Another method in prepare before calling activate_volume to cleanup the
config?
Another approach would be to skip cdroms in those checks completely and
set a cdrom in vm_start to none if the iso does not exist.
Stefan
Am 20.08.2015 um 10:33 schrieb Alexandre DERUMIER:
I think we should eject it automatically instead of do not start the
machine!
+1 for this.
Simply do an eject before migration, if the iso is local
- Mail original -
De: Wolfgang Link w.l...@proxmox.com
À: Stefan Priebe s.pri...@profihost.ag, pve-devel
pve-devel@pve.proxmox.com
Envoyé: Jeudi 20 Août 2015 09:52:34
Objet: Re: [pve-devel] removed ISO files block migration
I think we should eject it automatically instead of do not start the
machine!
This could be done easily if we check this on start.
On 08/20/2015 09:39 AM, Stefan Priebe - Profihost AG wrote:
Hi,
i've no real idea how to solve this.
Currently the following happens pretty easily.
You insert a cd iso image into your VM CD ROM. May be driver disk for
windows virtio-X.
Than some month later somebody updates this one from virtio-X to
virtio-Y and deletes the old iso files.
From now on every attempt to migrate this VM fails with:
volume 'cdisoimages:iso/virtio-win-0.1-100.iso' does not exist
It would be great if we can handle this.
Stefan
___
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 mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] removed ISO files block migration
Am 20.08.2015 um 10:50 schrieb Wolfgang Link:
I would do it this way. skip cdrom and set it.
Not easy as i thought. The problem is that sub activate_volumes { in
Storage.pm has no chance no know if a volume id is used as a cdrom or
not and the drive information are not passed.
So the only way seem to add a skip errors flag to activate_volumes ;-(
Stefan
On 08/20/2015 10:41 AM, Stefan Priebe - Profihost AG wrote:
I'm currently struggling.
There is sync_disks method in QemuMigrate.pm which might be good for
this. But the code is failing before in sub prepare calling
PVE::Storage::activate_volumes($self-{storecfg}, $vollist);
sub activate_volume {
my ($class, $storeid, $scfg, $volname, $exclusive, $cache) = @_;
my $path = $class-filesystem_path($scfg, $volname);
# check is volume exists
if ($scfg-{path}) {
die volume '$storeid:$volname' does not exist\n if ! -e $path;
So where to implement this?
Another method in prepare before calling activate_volume to cleanup the
config?
Another approach would be to skip cdroms in those checks completely and
set a cdrom in vm_start to none if the iso does not exist.
Stefan
Am 20.08.2015 um 10:33 schrieb Alexandre DERUMIER:
I think we should eject it automatically instead of do not start the
machine!
+1 for this.
Simply do an eject before migration, if the iso is local
- Mail original -
De: Wolfgang Link w.l...@proxmox.com
À: Stefan Priebe s.pri...@profihost.ag, pve-devel
pve-devel@pve.proxmox.com
Envoyé: Jeudi 20 Août 2015 09:52:34
Objet: Re: [pve-devel] removed ISO files block migration
I think we should eject it automatically instead of do not start the
machine!
This could be done easily if we check this on start.
On 08/20/2015 09:39 AM, Stefan Priebe - Profihost AG wrote:
Hi,
i've no real idea how to solve this.
Currently the following happens pretty easily.
You insert a cd iso image into your VM CD ROM. May be driver disk for
windows virtio-X.
Than some month later somebody updates this one from virtio-X to
virtio-Y and deletes the old iso files.
From now on every attempt to migrate this VM fails with:
volume 'cdisoimages:iso/virtio-win-0.1-100.iso' does not exist
It would be great if we can handle this.
Stefan
___
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 mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] removed ISO files block migration
Am 20.08.2015 um 10:05 schrieb Stefan Priebe - Profihost AG: Am 20.08.2015 um 09:52 schrieb Wolfgang Link: I think we should eject it automatically instead of do not start the machine! +1 Will have a look at the 3.4 code. OK the case i have here is even more worth. The CD iso is only in a snapshot not the currently running VM. Stefan This could be done easily if we check this on start. On 08/20/2015 09:39 AM, Stefan Priebe - Profihost AG wrote: Hi, i've no real idea how to solve this. Currently the following happens pretty easily. You insert a cd iso image into your VM CD ROM. May be driver disk for windows virtio-X. Than some month later somebody updates this one from virtio-X to virtio-Y and deletes the old iso files. From now on every attempt to migrate this VM fails with: volume 'cdisoimages:iso/virtio-win-0.1-100.iso' does not exist It would be great if we can handle this. Stefan ___ 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 mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH] Bugfix 688: prevent copy unused disks in the config.
---
PVE/API2/Qemu.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index c4516de..669cfc2 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -2171,7 +2171,8 @@ __PACKAGE__-register_method({
# do not copy snapshot related info
next if $opt eq 'snapshots' || $opt eq 'parent' || $opt eq
'snaptime' ||
- $opt eq 'vmstate' || $opt eq 'snapstate';
+ $opt eq 'vmstate' || $opt eq 'snapstate' ||
+ $opt =~ m/^unused\d+$/;
# always change MAC! address
if ($opt =~ m/^net(\d+)$/) {
--
2.1.4
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 3/3] mount hook : code cleanup
- use sub path
- manage bind mount for non devices
- split mount and device_cgroup (we'll need mount later for backup for example)
Signed-off-by: Alexandre Derumier aderum...@odiso.com
---
src/lxc-pve-mount-hook | 45 +++--
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/src/lxc-pve-mount-hook b/src/lxc-pve-mount-hook
index 6f25aa1..0655d3c 100755
--- a/src/lxc-pve-mount-hook
+++ b/src/lxc-pve-mount-hook
@@ -92,27 +92,38 @@ __PACKAGE__-register_method ({
my ($ms, $mountpoint) = @_;
my $volid = $mountpoint-{volume};
- return if !$volid;
+ return if !$volid || $ms eq 'rootfs' || !$mountpoint-{mp};
- if ($volid =~ m|^/dev/.+| $mountpoint-{mp} $ms ne 'rootfs') {
- PVE::Tools::run_command(['mount', $volid,
$rootdir$mountpoint-{mp}]);
- return;
- }
+ eval {
+ my $mount_path = $rootdir.$mountpoint-{mp};
+ if (! -d $mount_path) {
+ mkdir($mount_path) || $! == EEXIST || die unable to create
directory '$mount_path' - $!\n;
+ }
- my ($storage, $volname) = PVE::Storage::parse_volume_id($volid);
+ if ($volid =~ m|^/dev/.+|) {
+ PVE::Tools::run_command(['mount', $volid, $mount_path]);
+ return;
+ }
- my $scfg = PVE::Storage::storage_config($storage_cfg, $storage);
+ my $path = PVE::LXC::volid_path($volid, $ms, $storage_cfg,
$loopdevs);
- my $path = PVE::Storage::path($storage_cfg, $volid);
+ if ($path !~ m|^/dev/.+|) {
+ PVE::Tools::run_command(['mount', '-o', 'bind', $path,
$mount_path]);
+ return;
+ }
- my ($vtype, undef, undef, undef, undef, $isBase, $format) =
- PVE::Storage::parse_volname($storage_cfg, $volid);
+ PVE::Tools::run_command(['mount', $path, $mount_path]);
+ };
+ warn $@ if $@;
+ };
- return if $format eq 'subvol';
+ my $setup_cgroup_device = sub {
+ my ($ms, $mountpoint) = @_;
- if ($scfg-{type} eq 'dir' || $scfg-{type} eq 'nfs') {
- $path = PVE::LXC::find_loopdev($loopdevs, $path);
- }
+ my $volid = $mountpoint-{volume};
+ return if !$volid || $volid =~ m|^/dev/.+|;
+
+ my $path = PVE::LXC::volid_path($volid, $ms, $storage_cfg,
$loopdevs);
if (-l $path) {
$path = readlink($path);
@@ -123,14 +134,12 @@ __PACKAGE__-register_method ({
PVE::Tools::run_command(['mknod', '-m', '666', $rootdir$path,
'b', $bdevs-{$path}-{major}, $bdevs-{$path}-{minor}]);
PVE::LXC::write_cgroup_value(devices, $vmid, devices.allow,
b $bdevs-{$path}-{major}:$bdevs-{$path}-{minor} rwm);
}
-
- if ($mountpoint-{mp} ($ms ne 'rootfs')) {
- PVE::Tools::run_command(['mount', $path,
$rootdir$mountpoint-{mp}]);
- }
};
PVE::LXC::foreach_mountpoint($conf, $setup_mountpoint);
+ PVE::LXC::foreach_mountpoint($conf, $setup_cgroup_device);
+
my $lxc_setup = PVE::LXC::Setup-new($conf, $rootdir);
$lxc_setup-pre_start_hook();
--
2.1.4
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 2/3] update_lxc_config : code_clenaup
- use volid_path sub
- we now manage only rootfs, subvol mount.entry will be manage in mount hook
Signed-off-by: Alexandre Derumier aderum...@odiso.com
---
src/PVE/LXC.pm | 33 +++--
1 file changed, 3 insertions(+), 30 deletions(-)
diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm
index fb54069..aaeee7f 100644
--- a/src/PVE/LXC.pm
+++ b/src/PVE/LXC.pm
@@ -1002,39 +1002,12 @@ sub update_lxc_config {
PVE::LXC::foreach_mountpoint($conf, sub {
my ($ms, $mountpoint) = @_;
+ return if $ms ne 'rootfs';
my $volid = $mountpoint-{volume};
return if !$volid || $volid =~ m|^/dev/.+|;
- my ($storage, $volname) = PVE::Storage::parse_volume_id($volid);
-
- my $scfg = PVE::Storage::storage_config($storage_cfg, $storage);
- my $path = PVE::Storage::path($storage_cfg, $volid);
-
- my ($vtype, undef, undef, undef, undef, $isBase, $format) =
- PVE::Storage::parse_volname($storage_cfg, $volid);
-
- die unable to use template as mountpoint\n if $isBase;
-
- if ($format eq 'subvol') {
- $mountpoint-{mp} =~ s/^\///s;
- if ($ms eq 'rootfs') {
- $raw .= lxc.rootfs = $path\n;
- } else {
- $raw .= lxc.mount.entry = $path $mountpoint-{mp} none
defaults,bind 0 0\n;
- }
- } elsif ($format eq 'raw') {
-
- if ($scfg-{path}) {
- $raw .= lxc.rootfs = loop:$path\n if $ms eq 'rootfs';
- } elsif ($scfg-{type} eq 'drbd' || $scfg-{type} eq 'rbd') {
- $raw .= lxc.rootfs = $path\n if $ms eq 'rootfs';
- } else {
- die unsupported storage type '$scfg-{type}'\n;
- }
- } else {
- die unsupported image format '$format'\n;
- }
-
+ my $path = volid_path ($volid, $ms, $storage_cfg);
+ $raw .= lxc.rootfs = $path\n;
});
my $netcount = 0;
--
2.1.4
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] KRDB
only other possiblity could by qemu-nbd with librbd. But that seem complex. krbd is faster than librbd anyway (use 50% less cpu) the only thin is that krbd take more time to catchup last ceph features. (but kernel 4.1 is really recent, so it support all hammer feature) - Mail original - De: dietmar diet...@proxmox.com À: aderumier aderum...@odiso.com, Wolfgang Link w.l...@proxmox.com, pve-devel pve-devel@pve.proxmox.com Envoyé: Jeudi 20 Août 2015 16:12:53 Objet: Re: [pve-devel] KRDB I'm wondering if it is really necessary to use krdb when lxc is on ceph? What do you want to use instead? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] KRDB
only other possiblity could by qemu-nbd with librbd. But that seem complex. Oh, I forgot about that. Looks a bit clumsy, but should not be that hard to implement? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] KRDB
only other possiblity could by qemu-nbd with librbd. But that seem complex. Oh, I forgot about that. Looks a bit clumsy, but should not be that hard to implement? Well, qemu-nbd is really slow, so I guess it is not worth to implement it. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] KRDB
I'm wondering if it is really necessary to use krdb when lxc is on ceph? What do you want to use instead? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] KRDB
I'm wondering if it is really necessary to use krdb when lxc is on ceph? or there are any other possibility? There are any pitfalls with krdb? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] pve-container : cleanup mountpoint code
code cleanup before implementing backup code ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH 1/3] add volid_path
Signed-off-by: Alexandre Derumier aderum...@odiso.com
---
src/PVE/LXC.pm | 36
1 file changed, 36 insertions(+)
diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm
index 3ba8d51..fb54069 100644
--- a/src/PVE/LXC.pm
+++ b/src/PVE/LXC.pm
@@ -1867,4 +1867,40 @@ sub check_ct_modify_config_perm {
return 1;
}
+
+sub volid_path {
+my ($volid, $ms, $storage_cfg, $loopdevs) = @_;
+
+my ($storage, $volname) = PVE::Storage::parse_volume_id($volid);
+my $scfg = PVE::Storage::storage_config($storage_cfg, $storage);
+my $path = PVE::Storage::path($storage_cfg, $volid);
+
+my ($vtype, undef, undef, undef, undef, $isBase, $format) =
+PVE::Storage::parse_volname($storage_cfg, $volid);
+
+die unable to use template as mountpoint\n if $isBase;
+
+if ($format eq 'subvol') {
+ #do nothing
+} elsif ($format eq 'raw') {
+
+if ($scfg-{path}) {
+ if ($ms eq 'rootfs') {
+ $path = loop:$path\n if $ms eq 'rootfs';
+ } elsif ($loopdevs) {
+ $path = PVE::LXC::find_loopdev($loopdevs, $path) if
$loopdevs;
+ }
+
+} elsif ($scfg-{type} eq 'drbd' || $scfg-{type} eq 'rbd') {
+ #do nothing
+} else {
+die unsupported storage type '$scfg-{type}'\n;
+}
+} else {
+die unsupported image format '$format'\n;
+}
+
+ return $path;
+
+}
1;
--
2.1.4
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH] Fix escaping of XML attributes in cluster.conf [#686]
When the cluster config XML gets written we escape the following
characters in attributes:
As the XML standard states, we only have to escape the characters
and ' in attributes. Whereashave to be escaped in tags
only. This addresses bug #686
Signed-off-by: Thomas Lamprecht t.lampre...@proxmox.com
---
data/PVE/Cluster.pm |3 ---
1 file changed, 3 deletions(-)
diff --git a/data/PVE/Cluster.pm b/data/PVE/Cluster.pm
index 5a031cb..78b38ed 100644
--- a/data/PVE/Cluster.pm
+++ b/data/PVE/Cluster.pm
@@ -1429,9 +1429,6 @@ sub xml_escape_attrib {
return '' if !defined($data);
-$data =~ s//amp;/sg;
-$data =~ s//lt;/sg;
-$data =~ s//gt;/sg;
$data =~ s//quot;/sg;
return $data;
--
1.7.10.4
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH] Fix escaping of XML attributes in cluster.conf [#686]
This addresses the stable-3 branch in the pve-cluster package and fixes
https://bugzilla.proxmox.com/show_bug.cgi?id=686
On 08/20/2015 05:10 PM, Thomas Lamprecht wrote:
When the cluster config XML gets written we escape the following
characters in attributes:
As the XML standard states, we only have to escape the characters
and ' in attributes. Whereashave to be escaped in tags
only. This addresses bug #686
Signed-off-by: Thomas Lamprecht t.lampre...@proxmox.com
---
data/PVE/Cluster.pm |3 ---
1 file changed, 3 deletions(-)
diff --git a/data/PVE/Cluster.pm b/data/PVE/Cluster.pm
index 5a031cb..78b38ed 100644
--- a/data/PVE/Cluster.pm
+++ b/data/PVE/Cluster.pm
@@ -1429,9 +1429,6 @@ sub xml_escape_attrib {
return '' if !defined($data);
-$data =~ s//amp;/sg;
-$data =~ s//lt;/sg;
-$data =~ s//gt;/sg;
$data =~ s//quot;/sg;
return $data;
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] Restore quickly by CLI a backup when i have different disks in destination
Hi to all Excuse me please if i do a question in the incorrect site, but i did a same question in different dates in the PVE forum, and no one has responded me (From June-28-2015). The question is: how restore quickly by CLI a backup of a VM when i have several virtual disks on the backup and in destination for restore? If anybody know the answer, please go to this link, read the detail, and answer me: http://forum.proxmox.com/threads/23300-By-CLI-restore-quickly-a-backup-when-i-have-different-disks-in-destination ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] removed ISO files block migration
- Original Message - From: Wolfgang Link w.l...@proxmox.com To: Stefan Priebe - Profihost AG s.pri...@profihost.ag; pve-devel@pve.proxmox.com Sent: Thursday, August 20, 2015 3:52 AM Subject: Re: [pve-devel] removed ISO files block migration I think we should eject it automatically instead of do not start the machine! This could be done easily if we check this on start. +1 for this. Simply do an eject before migration Also applicable for HA. But with caution, for example, if i need to start the VM with a live cd... ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] removed ISO files block migration
I would do it this way. skip cdrom and set it.
+1
Set it to none in the id.conf of the VM
Also applicable for HA.
But with caution, for example, if i need to start the VM manually with a
live cd...
- Original Message -
From: Wolfgang Link w.l...@proxmox.com
To: Stefan Priebe - Profihost AG s.pri...@profihost.ag; Alexandre
DERUMIER aderum...@odiso.com
Cc: pve-devel pve-devel@pve.proxmox.com
Sent: Thursday, August 20, 2015 4:50 AM
Subject: Re: [pve-devel] removed ISO files block migration
I would do it this way. skip cdrom and set it.
On 08/20/2015 10:41 AM, Stefan Priebe - Profihost AG wrote:
I'm currently struggling.
There is sync_disks method in QemuMigrate.pm which might be good for
this. But the code is failing before in sub prepare calling
PVE::Storage::activate_volumes($self-{storecfg}, $vollist);
sub activate_volume {
my ($class, $storeid, $scfg, $volname, $exclusive, $cache) = @_;
my $path = $class-filesystem_path($scfg, $volname);
# check is volume exists
if ($scfg-{path}) {
die volume '$storeid:$volname' does not exist\n if ! -e $path;
So where to implement this?
Another method in prepare before calling activate_volume to cleanup the
config?
Another approach would be to skip cdroms in those checks completely and
set a cdrom in vm_start to none if the iso does not exist.
Stefan
Am 20.08.2015 um 10:33 schrieb Alexandre DERUMIER:
I think we should eject it automatically instead of do not start the
machine!
+1 for this.
Simply do an eject before migration, if the iso is local
- Mail original -
De: Wolfgang Link w.l...@proxmox.com
À: Stefan Priebe s.pri...@profihost.ag, pve-devel
pve-devel@pve.proxmox.com
Envoyé: Jeudi 20 Août 2015 09:52:34
Objet: Re: [pve-devel] removed ISO files block migration
I think we should eject it automatically instead of do not start the
machine!
This could be done easily if we check this on start.
On 08/20/2015 09:39 AM, Stefan Priebe - Profihost AG wrote:
Hi,
i've no real idea how to solve this.
Currently the following happens pretty easily.
You insert a cd iso image into your VM CD ROM. May be driver disk for
windows virtio-X.
Than some month later somebody updates this one from virtio-X to
virtio-Y and deletes the old iso files.
From now on every attempt to migrate this VM fails with:
volume 'cdisoimages:iso/virtio-win-0.1-100.iso' does not exist
It would be great if we can handle this.
Stefan
___
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 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
