since qemu 1.5, they are a new migration state : "setup"
it's mainly use for rdma migration, but slow vm can it see and hang on migration
http://git.qemu.org/?p=qemu.git;a=commit;h=3b6959506831193f37cc830c8e111b437c0d1380
Signed-off-by: Alexandre Derumier
---
PVE/QemuMigrate.pm |6 ++
details in commit
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Hi,
I just notice that gluster 3.4.4 and 3.5 debian packages are available in on
gluster repository.
Don't known which one is better to use for proxmox.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listi
Am 16.06.2014 11:49, schrieb Alexandre DERUMIER:
>>> I think this should get cleaned in that case?
>
> currently the cleanup is done:
>
> at vm shutdown
> at vm start
> when you disable|enable firewall on netX through api
>
> but indeed we can improve that (I'll try to have a look at it)
>
>
Am 16.06.2014 11:49, schrieb Alexandre DERUMIER:
>>> I think this should get cleaned in that case?
>
> currently the cleanup is done:
>
> at vm shutdown
> at vm start
> when you disable|enable firewall on netX through api
>
> but indeed we can improve that (I'll try to have a look at it)
>
>
Am 16.06.2014 11:49, schrieb Alexandre DERUMIER:
>>> I think this should get cleaned in that case?
>
> currently the cleanup is done:
>
> at vm shutdown
> at vm start
> when you disable|enable firewall on netX through api
>
> but indeed we can improve that (I'll try to have a look at it)
>
>
>>I think this should get cleaned in that case?
currently the cleanup is done:
at vm shutdown
at vm start
when you disable|enable firewall on netX through api
but indeed we can improve that (I'll try to have a look at it)
>>I just don't get why it works for vmbr1 but not for vmbr0.
can you
> I think this should get cleaned in that case?
Yes, we need better cleanup.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Am 16.06.2014 11:37, schrieb Alexandre DERUMIER:
>>> What is the difference between the normal tap device without firewall -
>>> which works fine for me on vmbr0 and vmbr1 and the firewall tap one?
>
> They are not difference.
>
> we just need a dedicated bridge (fwbrxxx) by firewalled tap interf
>>What is the difference between the normal tap device without firewall -
>>which works fine for me on vmbr0 and vmbr1 and the firewall tap one?
They are not difference.
we just need a dedicated bridge (fwbrxxx) by firewalled tap interface,
and this bridge is plugged to vmbrX through a veth pair(
What is the difference between the normal tap device without firewall -
which works fine for me on vmbr0 and vmbr1 and the firewall tap one?
Stefan
Am 16.06.2014 11:10, schrieb Stefan Priebe - Profihost AG:
> Hi,
>
> i get the same problem with the official redhat PVE Kernel.
>
> What i don't u
Hi,
i get the same problem with the official redhat PVE Kernel.
What i don't understand is that it works fine with vmbr1 but not with
vmbr0.
Interfaces file on host:
auto vmbr0
iface vmbr0 inet static
address XX.XX.XX.XX
netmask 255.255.255.128
gateway XX.XX.XX.XX
>>Things like mac filter should stay enabled, even if the enable is set to 0.
I think it's not the case currently ?
>>But maybe we should use another name for that option?
disablerules ? dont known ...
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER" , "Stefan Priebe
> I think we could remove the enable|disable firewall option
I am quite sure many user wanta that function. It is basically just there
to enable/disable all firewall rules at once. Things like mac filter should
stay enabled, even if the enable is set to 0.
But maybe we should use another name fo
Am 16.06.2014 09:50, schrieb Alexandre DERUMIER:
>>> Do i need a special kernel feature?
> I don't think.
> It's just create a veth pair, then plug them in bridge.
>
> I check my logs, I don't have theses
>
> "netpoll: (null): fwpr2004p0 doesn't support polling, aborting "
>
> do you use a cust
Am 16.06.2014 09:57, schrieb Alexandre DERUMIER:
>>> - Network card base checkbox
>>>
>>> Why do we need the VM based checkbox if we already have that for each nic?
>
> I think we could remove the enable|disable firewall option, for qemu and
> openvz veth.
> (we retrieve net->firewall in firewall
>>- Network card base checkbox
>>
>>Why do we need the VM based checkbox if we already have that for each nic?
I think we could remove the enable|disable firewall option, for qemu and openvz
veth.
(we retrieve net->firewall in firewall rules generation, so no problem here)
the code is:
fore
>>Do i need a special kernel feature?
I don't think.
It's just create a veth pair, then plug them in bridge.
I check my logs, I don't have theses
"netpoll: (null): fwpr2004p0 doesn't support polling, aborting "
do you use a custom kernel ?
- Mail original -
De: "Stefan Priebe - Prof
Hello,
ok since i found the 3rd checkbox. It tries to enable the firewall.
But it fails.
PVE Output:
can't add fwpr2004p0 to bridge vmbr0: Unknown error 524
can't add interface 'iface' to bridge 'vmbr0'
/var/lib/qemu-server/pve-bridge: could not launch network script
Kernel Output:
[1705113.081
Am 16.06.2014 09:28, schrieb Alexandre DERUMIER:
>>> Still need to figure out why the firewall does not work for me at all.
>
> Do you some special network setup ?
Sorry i thought enabling firewall on cluster and on VM is enough. I did
not know that there is a 3rd option on each nic ;-(
Stefan
Am 16.06.2014 09:21, schrieb Stefan Priebe - Profihost AG:
> Am 13.06.2014 20:33, schrieb Dietmar Maurer:
>>> i would like to have different levels of firewall. Something the USER / VM
>>> Owner
>>> can control and something the PVE Manage / Sysadmin can control.
>>>
>>> So i can give the user the
>>Still need to figure out why the firewall does not work for me at all.
Do you some special network setup ?
can you post your vmid.conf , full "#brctl show" ?
also, check that
/var/lib/qemu-server/pve-bridge
is corretly updated
(you should have
PVE::Network::tap_plug($iface, $net->{bridge
Am 13.06.2014 20:33, schrieb Dietmar Maurer:
>> i would like to have different levels of firewall. Something the USER / VM
>> Owner
>> can control and something the PVE Manage / Sysadmin can control.
>>
>> So i can give the user the ability to use the new cool firewall code but i
>> can still
>>
23 matches
Mail list logo