Re: [pve-devel] [PATCH 2/2] parse_drive : return correct format

2013-04-30 Thread Dietmar Maurer
> >>Btw, your clone patches have the feature to set the format for each > >>drive. Do we really need that? > > Yes, because we create the volume before using qemu-img convert. > > But we also need to specify it to qemu-img convert, as auto-detection of the > target volume format don't work. > (I

[pve-devel] Copy from snapshot

2013-04-30 Thread Dietmar Maurer
Just committed a first versions: https://git.proxmox.com/?p=qemu-server.git;a=blobdiff;f=PVE/API2/Qemu.pm;h=fc9b502581fadf9603c4a31bd501602e9d92e3f0;hp=e92a03e990d9fe299005c3f0b2613d4160698581;hb=9076d880a8496f5cd4e8b270b19840bc891250f5;hpb=4e4f83fea0936de1f2e746e2870f2e9d8962ab8a It currently re

Re: [pve-devel] Copy from snapshot

2013-04-30 Thread Alexandre DERUMIER
>>It currently requires the "--full" parameter. Do you think we can >>conditionally clone if the feature is available (else we simply do a full >>copy)?  "Do you think we can conditionally clone" Do you mean linked clone ? I think only full copy is enough, It'll be difficult to manage the par

Re: [pve-devel] [PATCH 2/2] parse_drive : return correct format

2013-04-30 Thread Alexandre DERUMIER
>>Sorry, I do not really understand that. In the other mail you wrote that it >>would  >>be enough to specify one single -format parameter?  Oh, sorry, I have misreaded your previous mail (don't have sleep this night ;) "> >>Btw, your clone patches have the feature to set the format for each > >

Re: [pve-devel] Copy from snapshot

2013-04-30 Thread Dietmar Maurer
> >>It currently requires the "--full" parameter. Do you think we can > >>conditionally > clone if the feature is available (else we simply do a full copy)? > > "Do you think we can conditionally clone" > > Do you mean linked clone ? Yes, 'linked clone'. I will try to use this wording in futur

[pve-devel] qemu-server : vm_copy : add optional format parameter

2013-04-30 Thread Alexandre Derumier
can be raw,qcow2,vmdk require --full parameter ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[pve-devel] [PATCH] vm_copy : add optional format parameter

2013-04-30 Thread Alexandre Derumier
can be qcow2,raw,vmdk Signed-off-by: Alexandre Derumier --- PVE/API2/Qemu.pm | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm index fc9b502..f1fc2b5 100644 --- a/PVE/API2/Qemu.pm +++ b/PVE/API2/Qemu.pm @@ -1815,6 +1815

Re: [pve-devel] [PATCH] vm_copy : add optional format parameter

2013-04-30 Thread Dietmar Maurer
applied, thanks. > -Original Message- > From: pve-devel-boun...@pve.proxmox.com [mailto:pve-devel- > boun...@pve.proxmox.com] On Behalf Of Alexandre Derumier > Sent: Dienstag, 30. April 2013 10:34 > To: pve-devel@pve.proxmox.com > Subject: [pve-devel] [PATCH] vm_copy : add optional format

Re: [pve-devel] Copy from snapshot

2013-04-30 Thread Alexandre DERUMIER
Ah, OK.  >>So what for is that check in your patches? Can't we always create a full >>clone from snapshot?  currently with qemu-img : qcow2,rbd,sheepdog. But nexentait's not possible. (could be done with nexenta with cloning the snapshot then "zfs promote", to detach the clone child from t

Re: [pve-devel] Copy from snapshot

2013-04-30 Thread Dietmar Maurer
> currently with qemu-img : qcow2,rbd,sheepdog. > > But nexentait's not possible. (could be done with nexenta with cloning the > snapshot then "zfs promote", to detach the clone child from the parent) Ah, OK. But why don't you pass the $running parameter to has_feature()? > Maybe future st

[pve-devel] copy_vm: new option -target

2013-04-30 Thread Dietmar Maurer
Just added an option to move the final VM to another node. This works if the VM is on shared storage. Do you see any problems with that? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] copy_vm: new option -target

2013-04-30 Thread Alexandre DERUMIER
I think it's ok. Maybe can we improve this later by checking if the shared storage is available on the target node ? (I could be also usefull for live vm migration in the gui by example) - Mail original - De: "Dietmar Maurer" À: "Alexandre DERUMIER (aderum...@odiso.com)" Cc: pve-de

Re: [pve-devel] Copy from snapshot

2013-04-30 Thread Alexandre DERUMIER
I'll recheck that and send a patch tomorrow. (I'll be busy at work this afternoon) - Mail original - De: "Dietmar Maurer" À: "Alexandre DERUMIER" Cc: pve-devel@pve.proxmox.com Envoyé: Mardi 30 Avril 2013 10:57:57 Objet: RE: Copy from snapshot > currently with qemu-img : qcow2,rb

[pve-devel] vm_copy : signal interrupt don't go in vdisk_free

2013-04-30 Thread Alexandre DERUMIER
I'm doing some tests with signal interrupt when doing a full clone, and it doesn't seem to go in if (my $err = $@) { unlink $conffile; sleep 1; # some storage like rbd need to wait before release volume - really? foreach

Re: [pve-devel] copy_vm: new option -target

2013-04-30 Thread Dietmar Maurer
> Maybe can we improve this later by checking if the shared storage is > available on > the target node ? > (I could be also usefull for live vm migration in the gui by example) I thought we assume a shared storage is always available (unless disabled)? How do you want to check availability? usi