Am 06.05.2013 13:30, schrieb Dietmar Maurer:
>> Hi yes in this case. But imagine someone is using qemu-img in their on
>> scripts on
>> shell.
>
> qemu-img convert always creates the disk.
>
> The -C option is not documented and only used by pve commands. So what do you
> think
> is the problem
> Hi yes in this case. But imagine someone is using qemu-img in their on
> scripts on
> shell.
qemu-img convert always creates the disk.
The -C option is not documented and only used by pve commands. So what do you
think
is the problem?
___
pve-devel
Am 03.05.2013 08:39, schrieb Dietmar Maurer:
>> great idea - but who knows if the target i really zero init or not? so if
>> somebody
>> generally uses qemu-img and copy on top of an existing disk this is not
>> correct...
>
> Either we or qemu-img creates the file, so we know its zero.
>
Hi y
tefan
> - Mail original -
>
> De: "Stefan Priebe - Profihost AG"
> À: "Alexandre DERUMIER"
> Cc: pve-devel@pve.proxmox.com, "Dietmar Maurer"
> Envoyé: Vendredi 3 Mai 2013 10:14:08
> Objet: Re: [pve-devel] copy_vm: new option -tar
@pve.proxmox.com, "Dietmar Maurer"
Envoyé: Vendredi 3 Mai 2013 10:14:08
Objet: Re: [pve-devel] copy_vm: new option -target
Hi,
Am 03.05.2013 10:11, schrieb Alexandre DERUMIER:
> Hi Stefan,
>
> Just to known, why don't you use linked clone ? (Do you have tried it, does
cool feature.
Stefan
>
> - Mail original -
>
> De: "Dietmar Maurer"
> À: "Alexandre DERUMIER"
> Cc: pve-devel@pve.proxmox.com, "Stefan Priebe - Profihost AG"
>
> Envoyé: Vendredi 3 Mai 2013 08:42:25
> Objet: RE: [pve-de
.proxmox.com, "Stefan Priebe - Profihost AG"
Envoyé: Vendredi 3 Mai 2013 08:42:25
Objet: RE: [pve-devel] copy_vm: new option -target
> >>Should be possible to fix qemu-img?
> Yes, I think it should be possible. Code is not so huge.
>
> But Maybe do you have a
> >>Should be possible to fix qemu-img?
> Yes, I think it should be possible. Code is not so huge.
>
> But Maybe do you have a better understanding of the code. (As you have played
> with backup ;)
Maybe, but I need to make the other things stable first (this is only an
'optimization')
_
> great idea - but who knows if the target i really zero init or not? so if
> somebody
> generally uses qemu-img and copy on top of an existing disk this is not
> correct...
Either we or qemu-img creates the file, so we know its zero.
___
pve-devel m
ndre DERUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Jeudi 2 Mai 2013 14:06:39
Objet: Re: [pve-devel] copy_vm: new option -target
great idea - but who knows if the target i really zero init or not? so
if somebody generally uses qemu-img and copy on top of an existing disk
this is not
great idea - but who knows if the target i really zero init or not? so
if somebody generally uses qemu-img and copy on top of an existing disk
this is not correct...
Stefan
Am 02.05.2013 13:47, schrieb Alexandre DERUMIER:
> I'll test this:
>
>
> From 1b3f5a7812b0dd750e5010441708fee1a6117318 Mon
ER"
À: "Stefan Priebe - Profihost AG"
Cc: pve-devel@pve.proxmox.com
Envoyé: Jeudi 2 Mai 2013 13:27:48
Objet: Re: [pve-devel] copy_vm: new option -target
>>Oh OK so that's because we create the DISK before we start qemu-img?
Yes!
>>But we still loose spars
c: pve-devel@pve.proxmox.com
Envoyé: Jeudi 2 Mai 2013 13:27:48
Objet: Re: [pve-devel] copy_vm: new option -target
>>Oh OK so that's because we create the DISK before we start qemu-img?
Yes!
>>But we still loose sparseness?
I have done test, I think it depend the source.
ot;
> À: "Alexandre DERUMIER"
> Cc: pve-devel@pve.proxmox.com
> Envoyé: Jeudi 2 Mai 2013 13:22:33
> Objet: Re: [pve-devel] copy_vm: new option -target
>
> Oh OK so that's because we create the DISK before we start qemu-img? But
> we still loose sparsenes
it sparse.
- Mail original -
De: "Stefan Priebe - Profihost AG"
À: "Alexandre DERUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Jeudi 2 Mai 2013 13:22:33
Objet: Re: [pve-devel] copy_vm: new option -target
Oh OK so that's because we create the DISK before w
00.00 %
>
> # rbd info vm-301-disk-1
> rbd image 'vm-301-disk-1':
> size 15360 MB in 3840 objects
> order 22 (4096 KB objects)
> block_name_prefix: rbd_data.3c190a6b8b4567
> format: 2
> features: layering, striping
> stripe unit: 40
a i have is:
1.) disk must be created before
2.) qemu-img must skip blocks with 0 for rbd
Stefan
> - Mail original -
>
> De: "Dietmar Maurer"
> À: "Stefan Priebe - Profihost AG" , "Alexandre
> DERUMIER"
> Cc: pve-devel@pve.proxmox.
DERUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Jeudi 2 Mai 2013 13:16:08
Objet: Re: [pve-devel] copy_vm: new option -target
Am 02.05.2013 13:05, schrieb Alexandre DERUMIER:
>>> I also read that we'll loose sparseness with qemu-img as it does raw
>
>>> export a
Am 02.05.2013 13:05, schrieb Alexandre DERUMIER:
>>> I also read that we'll loose sparseness with qemu-img as it does raw
>
>>> export and import.
>
> I'm not sure about it, qemu-img code is
>
>
>if (has_zero_init) {
> /* If the output image is being created as a c
copy block sector from source to target, and I
think that rbd format infos are outside the volume.
- Mail original -
De: "Dietmar Maurer"
À: "Stefan Priebe - Profihost AG" , "Alexandre DERUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Jeudi 2 Mai 2013 13:0
> >>I also read that we'll loose sparseness with qemu-img as it does raw
>
> >>export and import.
>
> I'm not sure about it, qemu-img code is
>
>
>if (has_zero_init) {
> /* If the output image is being created as a copy on write
> image,
>assume
> I also read that we'll loose sparseness with qemu-img as it does raw export
> and
> import.
Maybe option -S helps here?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
aix
12 rue Marivaux 75002 Paris
- Mail original -
De: "Alexandre DERUMIER"
À: "Stefan Priebe - Profihost AG"
Cc: pve-devel@pve.proxmox.com
Envoyé: Jeudi 2 Mai 2013 12:57:12
Objet: Re: [pve-devel] copy_vm: new option -target
>>The problem is qemu-img here
> I also read that we'll loose sparseness with qemu-img as it does raw export
> and
> import.
>
> The best way would be to use rbd cp in this case which does all the things.
Should be possible to fix qemu-img?
___
pve-devel mailing list
pve-devel@pve.p
But rbd cp is only from rbd to rbd ?
- Mail original -
De: "Stefan Priebe - Profihost AG"
À: "Alexandre DERUMIER"
Cc: "Dietmar Maurer" , pve-devel@pve.proxmox.com
Envoyé: Jeudi 2 Mai 2013 12:39:32
Objet: Re: [pve-devel] copy_vm: new option -target
> >>Ah, OK. I thought we already check that for migrate?
> Yes, indeed
>
># check if storage is available on both nodes
> my $scfg = PVE::Storage::storage_check_node($self->{storecfg},
> $sid);
> PVE::Storage::storage_check_node($self->{storecfg}, $sid, $self-
> À: "Alexandre DERUMIER"
> Cc: "Dietmar Maurer" , pve-devel@pve.proxmox.com
> Envoyé: Jeudi 2 Mai 2013 12:15:08
> Objet: Re: [pve-devel] copy_vm: new option -target
>
> Hi Alexandre,
>
> have you checked which rbd format qemu-img creates? I mean we have
fan Priebe - Profihost AG"
À: "Alexandre DERUMIER"
Cc: "Dietmar Maurer" , pve-devel@pve.proxmox.com
Envoyé: Jeudi 2 Mai 2013 12:15:08
Objet: Re: [pve-devel] copy_vm: new option -target
Hi Alexandre,
have you checked which rbd format qemu-img creates? I mean we have rbd
f
Hi Alexandre,
have you checked which rbd format qemu-img creates? I mean we have rbd
format 1 and format 2.
In my tests qemu-img always create the slower and older format v1. But
normally if we clone a VM we should have the same settings of source and
target disk.
Greets,
Stefan
Am 02.05.2013 1
>>Ah, OK. I thought we already check that for migrate?
Yes, indeed
# check if storage is available on both nodes
my $scfg = PVE::Storage::storage_check_node($self->{storecfg},
$sid);
PVE::Storage::storage_check_node($self->{storecfg}, $sid,
$self->{node});
B
> >>I thought we assume a shared storage is always available (unless disabled)?
> It's possible that a shared can be assigned to specific nodes only. (nodes
> in
> storage.cfg).
> I have some shared storage in production not shared on all servers in same
> cluster. (because of differents netw
>>I thought we assume a shared storage is always available (unless disabled)?
It's possible that a shared can be assigned to specific nodes only. (nodes
in storage.cfg).
I have some shared storage in production not shared on all servers in same
cluster. (because of differents networks)
But
>>I thought we assume a shared storage is always available (unless disabled)?
It's possible that a shared can be assigned to specific nodes only. (nodes
in storage.cfg).
I have some shared storage in production not shared on all servers in same
cluster. (because of differents networks)
But
> 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
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
35 matches
Mail list logo
