Re: [pve-devel] [PATCH pve-docs 0/1] vxlan l3 routing
>>That "transport zone" looks interesting. >>We you just mark physical interfaces (or bridges?) as part of a transport >>zone. >>Then we have everything to setup the vxlan (each vlan belong to a zone)? yes, it should work. (interface could be better I think). /etc/network/interfaces iface eth0 transportzone 1 address 192.168.0.1 for vlan /etc/pve/network.cfg vlan : mycustombridge transportzone 1 vlan 2 bridge-vlan-aware 1|0 (for QinQ) This create iface mycustombridge bridge-ports eth0.2 for vxlan multicast --- /etc/pve/network.cfg vxlan : mycustombridge transportzone 1 mode multicast multicast_address 225.20.1.1 vxlan 2 This create iface vxlan2 vxlan-id 2 vxlan-svcnodeip 225.20.1.1 vxlan-physdev eth0 iface mycustombridge bridge-ports vxlan2 for vxlan + frr --- /etc/pve/network.cfg vxlan : mycustombridge transportzone 1 mode frr vxlan 2 this create auto vxlan2 iface vxlan2 inet manual vxlan-id 2 vxlan-local-tunnelip 192.168.0.1 ->get ip from transport interface bridge-learning off bridge-arp-nd-suppress on bridge-unicast-flood off bridge-multicast-flood off auto mycustombridge iface mycustombridge inet manual bridge_ports vxlan2 bridge_stp off bridge_fd 0 for vxlan unicast --- vxlan : mycustombridge transportzone 1 mode unicast peers 192.168.0.1,192.168.0.2,192.168.0.3 vxlan 2 this create auto vxlan2 iface vxlan2 inet manual vxlan-id 2 vxlan_remoteip 192.168.0.2 vxlan_remoteip 192.168.0.3 -> add all ips, excluding ip from transportzone interface auto mycustombridge iface mycustombridge inet manual bridge_ports vxlan2 bridge_stp off bridge_fd 0 Note that it could work with transportzone + ip address on bridge. (But in this case, maybe we can consider the bridge as the transport zone). I need to check with underlay layer3 + 2 interface with ecmp, but I think we have a loopback address, so it could be enslaved in a bridge too. - Mail original - De: "dietmar" À: "aderumier" Cc: "pve-devel" Envoyé: Mercredi 12 Décembre 2018 10:13:41 Objet: Re: [pve-devel] [PATCH pve-docs 0/1] vxlan l3 routing > I need to check, they have a concept of "transport zone", seem to be an > abstraction between distributed switch and physical host.(and some kind of > vrf/vlan isolation) > https://www.youtube.com/watch?v=Lsgz88OvxDk That "transport zone" looks interesting. We you just mark physical interfaces (or bridges?) as part of a transport zone. Then we have everything to setup the vxlan (each vlan belong to a zone)? ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-docs 0/1] vxlan l3 routing
>>Another way, could be make somekind of template on each local host. (as we
>>only need to duplicate them for each vlan/vxlan).
for vlan,
-
keep using an vmbr a template
auto vmbr0
iface vmbr0 inet manual
bridge-ports eno1
bridge-stp off
bridge-fd 0
Maybe it could be possible to reuse ifupdown2 native template too ?
%for v in [1,2]:
auto vmbr0v${v}
iface vmbr0v${v}
bridge-ports eno1
bridge-stp off
bridge-fd 0
%endfor
not sure if we could define the vlan/vxlan id in a list/variable somewhere, an
simply reuse them.
/etc/pve/interfaces.vlanlist
$mylist=[1,2]
then in
/etc/network/interfaces
include /etc/pve/interfaces.vlanlist
%for v in $mylist:
auto vmbr0v${v}
iface vmbr0v${v}
bridge-ports eno1
bridge-stp off
bridge-fd 0
%endfor
or for vxlan
%for v in $mylist:
auto vxlan${v}
iface vxlan${v} inet manual
vxlan-local-tunnelip 192.168.0.1
bridge-learning off
bridge-arp-nd-suppress on
bridge-unicast-flood off
bridge-multicast-flood off
auto vmbrvx${v}
iface vmbrvx${v}
bridge-ports vxlan${v}
bridge-stp off
bridge-fd 0
%endfor
- Mail original -
De: "aderumier"
À: "dietmar"
Cc: "pve-devel"
Envoyé: Mardi 11 Décembre 2018 10:49:57
Objet: Re: [pve-devel] [PATCH pve-docs 0/1] vxlan l3 routing
>>IMHO this looks like a hack - I wonder how VMware associates the global net
>>to
>>local devices on the host?
From what I have seen, the wizard when you create global net, is able to do
local configuration of all hosts interfaces too. (and associate them to global
switch).
Another way, could be make somekind of template on each local host. (as we only
need to duplicate them for each vlan/vxlan).
I need to check, they have a concept of "transport zone", seem to be an
abstraction between distributed switch and physical host.(and some kind of
vrf/vlan isolation)
https://www.youtube.com/watch?v=Lsgz88OvxDk
- Mail original -
De: "dietmar"
À: "aderumier" , "pve-devel"
Envoyé: Mardi 11 Décembre 2018 10:16:54
Objet: Re: [pve-devel] [PATCH pve-docs 0/1] vxlan l3 routing
> I'll have time to work again on /etc/pve/network.cfg idea.
>
> I don't known if you have some time to check my idea about using ifupdown2
> "alias"
IMHO this looks like a hack - I wonder how VMware associates the global net to
local devices on the host?
> BTW,talking with students on last training (a lot coming from vmware world),
> they think it could be great to be able to define global network (distributed
> virtual switch/ dvs in vmware),
> for vlan or vxlan, and be able to make permissions on it. (maybe be able to
> add them in a proxmox pool).
Yes. Would be great if you work on that.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-docs 0/1] vxlan l3 routing
>>IMHO this looks like a hack - I wonder how VMware associates the global net >>to >>local devices on the host? From what I have seen, the wizard when you create global net, is able to do local configuration of all hosts interfaces too. (and associate them to global switch). Another way, could be make somekind of template on each local host. (as we only need to duplicate them for each vlan/vxlan). I need to check, they have a concept of "transport zone", seem to be an abstraction between distributed switch and physical host.(and some kind of vrf/vlan isolation) https://www.youtube.com/watch?v=Lsgz88OvxDk - Mail original - De: "dietmar" À: "aderumier" , "pve-devel" Envoyé: Mardi 11 Décembre 2018 10:16:54 Objet: Re: [pve-devel] [PATCH pve-docs 0/1] vxlan l3 routing > I'll have time to work again on /etc/pve/network.cfg idea. > > I don't known if you have some time to check my idea about using ifupdown2 > "alias" IMHO this looks like a hack - I wonder how VMware associates the global net to local devices on the host? > BTW,talking with students on last training (a lot coming from vmware world), > they think it could be great to be able to define global network (distributed > virtual switch/ dvs in vmware), > for vlan or vxlan, and be able to make permissions on it. (maybe be able to > add them in a proxmox pool). Yes. Would be great if you work on that. ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v2 qemu-server] fix #1013 : migrate : sync_disk : --targetstorage with offline disk
targetsid was not used, for disk unused (offline copy)
---
PVE/QemuMigrate.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index e9e9075..0bae076 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -446,6 +446,7 @@ sub sync_disks {
foreach my $volid (keys %$local_volumes) {
my ($sid, $volname) = PVE::Storage::parse_volume_id($volid);
+ my $targetsid = $self->{opts}->{targetstorage} ?
$self->{opts}->{targetstorage} : $sid;
if ($self->{running} && $self->{opts}->{targetstorage} &&
$local_volumes->{$volid}->{ref} eq 'config') {
push @{$self->{online_local_volumes}}, $volid;
} else {
@@ -453,7 +454,7 @@ sub sync_disks {
push @{$self->{volumes}}, $volid;
my $insecure = $self->{opts}->{migration_type} eq 'insecure';
my $with_snapshots = $local_volumes->{$volid}->{snapshots};
- PVE::Storage::storage_migrate($self->{storecfg}, $volid,
$self->{ssh_info}, $sid,
+ PVE::Storage::storage_migrate($self->{storecfg}, $volid,
$self->{ssh_info}, $targetsid,
undef, undef, undef, undef,
$insecure, $with_snapshots);
}
}
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-docs 0/1] vxlan l3 routing
Hi Dietmar,
I'll have time to work again on /etc/pve/network.cfg idea.
I don't known if you have some time to check my idea about using ifupdown2
"alias"
BTW,talking with students on last training (a lot coming from vmware world),
they think it could be great to be able to define global network (distributed
virtual switch/ dvs in vmware),
for vlan or vxlan, and be able to make permissions on it. (maybe be able to add
them in a proxmox pool).
- Mail original -
De: "aderumier"
À: "dietmar"
Cc: "pve-devel"
Envoyé: Samedi 25 Août 2018 02:10:33
Objet: Re: [pve-devel] [PATCH pve-docs 0/1] vxlan l3 routing
>>Just try - maybe you can find a way to define a cluster wide config
>>(etc/pve/network.cfg) for those bridges.
>>
>>vnet1000: vxlan # VNI 1000
>> device vmbr0 # => vxlan-local-tunnelip
>> group 239.0.0.1
>>above would create the vtep and the bridge called 'vnet1000'?
Hi Dietmar,
I think I have found a way.
ifupdown2 support "alias" options
"
auto eno1
iface eno1
alias hypervisor_port_1
"
ip link set dev ${interface name} alias "${description}"
Examples:
ip link set dev eno1 alias "hypervisor_port_1"
Link aliases show up in "ip link show" output, like:
2: eno1: mtu 1500 qdisc mq state UP mode
DEFAULT qlen 1000
link/ether 22:ce:e0:99:63:6f brd ff:ff:ff:ff:ff:ff
alias hypervisor_port_1
Like this, we could define a common alias on differents hosts, with differents
interfaces,
and no need to use a vmbr0. (I'm thinking of layer3 underlay, with multiple
interfaces with ecmp)
Some examples:
---
multicast setup
---
vnet1000: vxlan # VNI 1000
device hypervisor_port_1
type multicast
group 239.0.0.1
this will add a vxlan1000 interface with "vxlan-svcnodeip ..." option (with
multicast address)
and vxlan-physdev (interface enX with hypervisor_port_1 alias)
node1
-
auto eno1
iface eno1 inet static
address 192.168.0.1/24
alias hypervisor_port_1
auto vxlan1000
iface vxlan1000 inet manual
vxlan-svcnodeip 239.0.0.1
vxlan-physdev eno1
auto vmbr1000
iface vmbr1000 inet manual
bridge_ports vxlan1000
bridge_stp off
bridge_fd 0
node2
-
auto eno2
iface eno2 inet static
address 192.168.0.2/24
alias hypervisor_port_1
auto vxlan1000
iface vxlan1000 inet manual
vxlan-svcnodeip 239.0.0.1
vxlan-physdev eno2
auto vmbr1000
iface vmbr1000 inet manual
bridge_ports vxlan1000
bridge_stp off
bridge_fd 0
unicast setup
-
vnet1000: vxlan # VNI 1000
device hypervisor_port_1
type unicast
group 192.168.0.1,192.168.0.2,192.168.0.3,ip4,ip5,.. (all proxmox nodes ips or
others ip)
this will add a vxlan1000 interface with "vxlan_remoteip ..." option, with all
ips from "group", excluding ip of hypervisor_port_1 on each host,
and a vmbr1000 with 192.168.0.1 (anycast gateway)
node1
-
auto eno1
iface eno1 inet static
address 192.168.0.1/24
alias hypervisor_port_1
auto vxlan1000
iface vxlan1000 inet manual
vxlan_remoteip 192.168.0.2
vxlan_remoteip 192.168.0.3
auto vmbr1000
iface vmbr1000 inet manual
bridge_ports vxlan1000
bridge_stp off
bridge_fd 0
node2
-
auto eno2
iface eno2 inet static
address 192.168.0.2/24
alias hypervisor_port_1
auto vxlan1000
iface vxlan1000 inet manual
vxlan_remoteip 192.168.0.1
vxlan_remoteip 192.168.0.3
auto vmbr1000
iface vmbr1000 inet manual
bridge_ports vxlan1000
bridge_stp off
bridge_fd 0
evpn-bgp setup
--
vnet1000: vxlan # VNI 1000
device hypervisor_port_1
type evpn-bgp
gateway 10.0.0.1
this will add a vxlan1000 interface "vxlan-local-tunnelip ..." with ip address
of hypervisor_port_1 on each host,
and a vmbr1000 with 192.168.0.1 (anycast gateway)
node1
-
auto eno1
iface eno1 inet static
address 192.168.0.1/24
alias hypervisor_port_1
auto vxlan1000
iface vxlan1000 inet manual
vxlan-id 1000
vxlan-local-tunnelip 192.168.0.1
bridge-learning off
bridge-arp-nd-suppress on
bridge-unicast-flood off
bridge-multicast-flood off
auto vmbr1000
iface vmbr1000 inet static
address 10.0.0.1/24
bridge_ports vxlan1000
bridge_stp off
bridge_fd 0
node2
-
auto eno2
iface eno2 inet static
address 192.168.0.2/24
alias hypervisor_port_1
auto vxlan1000
iface vxlan1000 inet manual
vxlan-id 1000
vxlan-local-tunnelip 192.168.0.2
bridge-learning off
bridge-arp-nd-suppress on
bridge-unicast-flood off
bridge-multicast-flood off
auto vmbr1000
iface vmbr1000 inet static
address 10.0.0.1/24
bridge_ports vxlan1000
bridge_stp off
bridge_fd 0
What do you think about this ?
- Mail original -
De: "dietmar"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Mardi 14 Août 2018 12:09:20
Objet: Re: [pve-devel] [PATCH pve-docs 0/1] vxlan l3 routing
> >>Not sure if the vxlan config is most times node related, so you always have
> >>node
> >>related config anyways?
> with frr, The vxlan interface indeed have the local ip vxlan-local-tunnelip.
> (this could be foun
[pve-devel] [PATCH pve-docs] vxlan : add missing vxlan-id
--- vxlan-and-evpn.adoc | 51 +++ 1 file changed, 51 insertions(+) diff --git a/vxlan-and-evpn.adoc b/vxlan-and-evpn.adoc index 5115d78..bd0bd72 100644 --- a/vxlan-and-evpn.adoc +++ b/vxlan-and-evpn.adoc @@ -51,6 +51,7 @@ iface vmbr0 inet static auto vxlan2 iface vxlan2 inet manual +vxlan-id 2 vxlan-svcnodeip 225.20.1.1 vxlan-physdev eno1 @@ -62,6 +63,7 @@ iface vmbr2 inet manual auto vxlan3 iface vxlan3 inet manual +vxlan-id 3 vxlan-svcnodeip 225.20.1.1 vxlan-physdev eno1 @@ -90,6 +92,7 @@ iface vmbr0 inet static auto vxlan2 iface vxlan2 inet manual +vxlan-id 2 vxlan-svcnodeip 225.20.1.1 vxlan-physdev eno1 @@ -102,6 +105,7 @@ iface vmbr2 inet manual auto vxlan3 iface vxlan3 inet manual +vxlan-id 3 vxlan-svcnodeip 225.20.1.1 vxlan-physdev eno1 @@ -130,6 +134,7 @@ iface vmbr0 inet static auto vxlan2 iface vxlan2 inet manual +vxlan-id 2 vxlan-svcnodeip 225.20.1.1 vxlan-physdev eno1 @@ -142,6 +147,7 @@ iface vmbr2 inet manual auto vxlan3 iface vxlan3 inet manual +vxlan-id 3 vxlan-svcnodeip 225.20.1.1 vxlan-physdev eno1 @@ -180,6 +186,7 @@ iface vmbr0 inet static auto vxlan2 iface vxlan2 inet manual +vxlan-id 2 vxlan_remoteip 192.168.0.2 vxlan_remoteip 192.168.0.3 @@ -193,6 +200,7 @@ iface vmbr2 inet manual auto vxlan3 iface vxlan2 inet manual +vxlan-id 3 vxlan_remoteip 192.168.0.2 vxlan_remoteip 192.168.0.3 @@ -222,6 +230,7 @@ iface vmbr0 inet static auto vxlan2 iface vxlan2 inet manual +vxlan-id 2 vxlan_remoteip 192.168.0.1 vxlan_remoteip 192.168.0.3 @@ -235,6 +244,7 @@ iface vmbr2 inet manual auto vxlan3 iface vxlan2 inet manual +vxlan-id 3 vxlan_remoteip 192.168.0.1 vxlan_remoteip 192.168.0.3 @@ -264,6 +274,7 @@ iface vmbr0 inet static auto vxlan2 iface vxlan2 inet manual +vxlan-id 2 vxlan_remoteip 192.168.0.2 vxlan_remoteip 192.168.0.3 @@ -277,6 +288,7 @@ iface vmbr2 inet manual auto vxlan3 iface vxlan2 inet manual +vxlan-id 3 vxlan_remoteip 192.168.0.2 vxlan_remoteip 192.168.0.3 @@ -317,6 +329,7 @@ iface vmbr0 inet static auto vxlan2 iface vxlan2 inet manual +vxlan-id 2 vxlan-local-tunnelip 192.168.0.1 bridge-learning off bridge-arp-nd-suppress on @@ -333,6 +346,7 @@ iface vmbr2 inet manual auto vxlan3 iface vxlan3 inet manual +vxlan-id 3 vxlan-local-tunnelip 192.168.0.1 bridge-learning off bridge-arp-nd-suppress on @@ -385,6 +399,7 @@ iface vmbr0 inet static auto vxlan2 iface vxlan2 inet manual +vxlan-id 2 vxlan-local-tunnelip 192.168.0.2 bridge-learning off bridge-arp-nd-suppress on @@ -400,6 +415,7 @@ iface vmbr2 inet manual auto vxlan3 iface vxlan3 inet manual +vxlan-id 3 vxlan-local-tunnelip 192.168.0.2 bridge-learning off bridge-arp-nd-suppress on @@ -452,6 +468,7 @@ iface vmbr0 inet static auto vxlan2 iface vxlan2 inet manual +vxlan-id 2 vxlan-local-tunnelip 192.168.0.3 bridge-learning off bridge-arp-nd-suppress on @@ -467,6 +484,7 @@ iface vmbr2 inet manual auto vxlan3 iface vxlan3 inet manual +vxlan-id 3 vxlan-local-tunnelip 192.168.0.3 bridge-learning off bridge-arp-nd-suppress on @@ -550,6 +568,7 @@ iface vmbr0 inet static auto vxlan2 iface vxlan2 inet manual +vxlan-id 2 vxlan-local-tunnelip 192.168.0.1 bridge-learning off bridge-arp-nd-suppress on @@ -569,6 +588,7 @@ iface vmbr2 inet static auto vxlan3 iface vxlan3 inet manual +vxlan-id 3 vxlan-local-tunnelip 192.168.0.1 bridge-learning off bridge-arp-nd-suppress on @@ -625,6 +645,7 @@ iface vmbr0 inet static auto vxlan2 iface vxlan2 inet manual +vxlan-id 2 vxlan-local-tunnelip 192.168.0.2 bridge-learning off bridge-arp-nd-suppress on @@ -644,6 +665,7 @@ iface vmbr2 inet static auto vxlan3 iface vxlan3 inet manual +vxlan-id 3 vxlan-local-tunnelip 192.168.0.2 bridge-learning off bridge-arp-nd-suppress on @@ -700,6 +722,7 @@ iface vmbr0 inet static auto vxlan2 iface vxlan2 inet manual +vxlan-id 2 vxlan-local-tunnelip 192.168.0.3 bridge-learning off bridge-arp-nd-suppress on @@ -719,6 +742,7 @@ iface vmbr2 inet static auto vxlan3 iface vxlan3 inet manual +vxlan-id 3 vxlan-local-tunnelip 192.168.0.3 bridge-learning off bridge-arp-nd-suppress on @@ -806,6 +830,7 @@ iface vmbr0 inet static auto vxlan2 iface vxlan2 inet manual +vxlan-id 2 vx
Re: [pve-devel] [PATCH qemu-server] fix #1013 : migrate : sync_disk : --targetstorage with offline disk
>>$storeid is not know/in scope here... did you mean $sid?
oh, sorry, wrong copy/paste when I have rebased my patch.
do you want a v2 ?
- Mail original -
De: "Thomas Lamprecht"
À: "pve-devel" , "aderumier"
Envoyé: Lundi 10 Décembre 2018 12:05:35
Objet: Re: [pve-devel] [PATCH qemu-server] fix #1013 : migrate : sync_disk :
--targetstorage with offline disk
On 12/7/18 12:03 PM, Alexandre Derumier wrote:
> targetsid was not used, for disk unused (offline copy)
> ---
> PVE/QemuMigrate.pm | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
> index e9e9075..f422f2e 100644
> --- a/PVE/QemuMigrate.pm
> +++ b/PVE/QemuMigrate.pm
> @@ -446,6 +446,7 @@ sub sync_disks {
>
> foreach my $volid (keys %$local_volumes) {
> my ($sid, $volname) = PVE::Storage::parse_volume_id($volid);
> + my $targetsid = $self->{opts}->{targetstorage} ?
> $self->{opts}->{targetstorage} : $storeid;
$storeid is not know/in scope here... did you mean $sid?
> if ($self->{running} && $self->{opts}->{targetstorage} &&
> $local_volumes->{$volid}->{ref} eq 'config') {
> push @{$self->{online_local_volumes}}, $volid;
> } else {
> @@ -453,7 +454,7 @@ sub sync_disks {
> push @{$self->{volumes}}, $volid;
> my $insecure = $self->{opts}->{migration_type} eq 'insecure';
> my $with_snapshots = $local_volumes->{$volid}->{snapshots};
> - PVE::Storage::storage_migrate($self->{storecfg}, $volid, $self->{ssh_info},
> $sid,
> + PVE::Storage::storage_migrate($self->{storecfg}, $volid, $self->{ssh_info},
> $targetsid,
> undef, undef, undef, undef, $insecure, $with_snapshots);
> }
> }
>
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH v3 qemu-server 1/7] api2 : add migrate_vm_external
>>Sorry for the delay, firewall conntrack logging took longer than expected.
no problem, thanks to work on it !
>>'pve-node' does not support fully qualified domain names, only
>>[a-zA-Z0-9]([a-zA-Z0-9\-]*[a-zA-Z0-9])? (copied from
>>pve-common/src/PVE/JSONSchema.pm).
Ok I'll look at this.
- Mail original -
De: "David Limbeck"
À: "pve-devel"
Envoyé: Vendredi 7 Décembre 2018 15:49:52
Objet: Re: [pve-devel] [PATCH v3 qemu-server 1/7] api2 : add migrate_vm_external
Sorry for the delay, firewall conntrack logging took longer than expected.
Still need some time to go through your patches in detail, but one thing
inline:
On 11/27/18 4:38 PM, Alexandre Derumier wrote:
> qm migrate_external [--targetstorage otherstorage]
> [--targetbridge otherbridge]
> ---
> PVE/API2/Qemu.pm | 79
>
> PVE/CLI/qm.pm | 2 ++
> 2 files changed, 81 insertions(+)
>
> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
> index c82e2fa..b23db56 100644
> --- a/PVE/API2/Qemu.pm
> +++ b/PVE/API2/Qemu.pm
> @@ -3162,6 +3162,85 @@ __PACKAGE__->register_method({
> }});
>
> __PACKAGE__->register_method({
> + name => 'migrate_vm_external',
> + path => '{vmid}/migrate_external',
> + method => 'POST',
> + protected => 1,
> + proxyto => 'node',
> + description => "Migrate virtual machine to an external cluster. Creates a
> new migration task.",
> + permissions => {
> + check => ['perm', '/vms/{vmid}', [ 'VM.Migrate' ]],
> + },
> + parameters => {
> + additionalProperties => 0,
> + properties => {
> + node => get_standard_option('pve-node'),
> + vmid => get_standard_option('pve-vmid', { completion =>
> \&PVE::QemuServer::complete_vmid }),
> + target => get_standard_option('pve-node', {
> + description => "Target node.",
> + }),
'pve-node' does not support fully qualified domain names, only
[a-zA-Z0-9]([a-zA-Z0-9\-]*[a-zA-Z0-9])? (copied from
pve-common/src/PVE/JSONSchema.pm).
> + targetstorage => get_standard_option('pve-storage-id', {
> + description => "Target remote storage.",
> + optional => 1,
> + }),
> + targetbridge => {
> + type => 'string',
> + description => "Target remote bridge.",
> + format_description => 'bridge',
> + optional => 1,
> + },
> + },
> + },
> + returns => {
> + type => 'string',
> + description => "the task ID.",
> + },
> + code => sub {
> + my ($param) = @_;
> +
> + my $rpcenv = PVE::RPCEnvironment::get();
> +
> + my $authuser = $rpcenv->get_user();
> +
> + die "Only root can do external migration." if $authuser ne 'root@pam';
> +
> + my $target = extract_param($param, 'target');
> +
> + my $vmid = extract_param($param, 'vmid');
> +
> + PVE::Cluster::check_cfs_quorum();
> +
> + raise_param_exc({ target => "target is member of local cluster."}) if
> PVE::Cluster::check_node_exists($target, 1);
> +
> + die "HA must be disable for external migration." if
> PVE::HA::Config::vm_is_ha_managed($vmid);
> +
> + my $targetip = PVE::Network::get_ip_from_hostname($target, 1);
> +
> + # test if VM exists
> + my $conf = PVE::QemuConfig->load_config($vmid);
> +
> + # try to detect errors early
> +
> + PVE::QemuConfig->check_lock($conf);
> +
> + die "VM need to be online for external migration" if
> !PVE::QemuServer::check_running($vmid);
> +
> + $param->{online} = 1;
> + $param->{migration_external} = 1;
> +
> + my $realcmd = sub {
> + PVE::QemuMigrate->migrate($target, $targetip, $vmid, $param);
> + };
> +
> + my $worker = sub {
> + return PVE::GuestHelpers::guest_migration_lock($vmid, 10, $realcmd);
> + };
> +
> + return $rpcenv->fork_worker('qmigrate', $vmid, $authuser, $worker);
> +
> + }});
> +
> +__PACKAGE__->register_method({
> name => 'monitor',
> path => '{vmid}/monitor',
> method => 'POST',
> diff --git a/PVE/CLI/qm.pm b/PVE/CLI/qm.pm
> index eceb9b3..5aa1d48 100755
> --- a/PVE/CLI/qm.pm
> +++ b/PVE/CLI/qm.pm
> @@ -850,6 +850,8 @@ our $cmddef = {
>
> migrate => [ "PVE::API2::Qemu", 'migrate_vm', ['vmid', 'target'], { node =>
> $nodename }, $upid_exit ],
>
> + migrate_external => [ "PVE::API2::Qemu", 'migrate_vm_external', ['vmid',
> 'target'], { node => $nodename }, $upid_exit ],
> +
> set => [ "PVE::API2::Qemu", 'update_vm', ['vmid'], { node => $nodename } ],
>
> resize => [ "PVE::API2::Qemu", 'resize_vm', ['vmid', 'disk', 'size'], { node
> => $nodename } ],
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server] fix #1013 : migrate : sync_disk : --targetstorage with offline disk
targetsid was not used, for disk unused (offline copy)
---
PVE/QemuMigrate.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index e9e9075..f422f2e 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -446,6 +446,7 @@ sub sync_disks {
foreach my $volid (keys %$local_volumes) {
my ($sid, $volname) = PVE::Storage::parse_volume_id($volid);
+ my $targetsid = $self->{opts}->{targetstorage} ?
$self->{opts}->{targetstorage} : $storeid;
if ($self->{running} && $self->{opts}->{targetstorage} &&
$local_volumes->{$volid}->{ref} eq 'config') {
push @{$self->{online_local_volumes}}, $volid;
} else {
@@ -453,7 +454,7 @@ sub sync_disks {
push @{$self->{volumes}}, $volid;
my $insecure = $self->{opts}->{migration_type} eq 'insecure';
my $with_snapshots = $local_volumes->{$volid}->{snapshots};
- PVE::Storage::storage_migrate($self->{storecfg}, $volid,
$self->{ssh_info}, $sid,
+ PVE::Storage::storage_migrate($self->{storecfg}, $volid,
$self->{ssh_info}, $targetsid,
undef, undef, undef, undef,
$insecure, $with_snapshots);
}
}
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server] clone_disk : cloudinit drive: don't clone snapname
we don't snapshot cloudinit drive,
this fix "qm clone --snapname mysnap" when a cloudinit
drive exist
---
PVE/QemuServer.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index a162db9..1e9dec6 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -6655,6 +6655,7 @@ sub clone_disk {
my $name = undef;
if (drive_is_cloudinit($drive)) {
$name = "vm-$newvmid-cloudinit";
+ $snapname = undef;
# cloudinit only supports raw and qcow2 atm:
if ($dst_format eq 'qcow2') {
$name .= '.qcow2';
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] pve-firewall : nftables ?
>>I mean, it does "work™" if we keep the firewall bridges around, as we
>>can match on `fwbr404i0` etc...
>>But it would be nice if we could get rid of those...
AFAIK, we also have added fwbr because we wanted the packet going twice in
netfilter,
once for vm1 output
once for vm2 input
don't remember if it was for simplicity of rules matching,
like vm1 accept out tcp/80, vm2 reject in tcp/80, both vms on same bridge.
Need to look in my archives, but first patches was without fwbr.
>>But it would be nice if we could get rid of those...
>>I currently only see hacky workarounds for that, though... One way
>>would be to create indexed chains for each set of guest/interface pairs,
>>and use the netdev table's ingress hook to mark packets for them...
>>We'd be using up more space in the 'mark' though (currently we only use
>>1 bit of it). But it would get rid of the extra firewall-bridges...
oh, didn't known about netdev table
>>(And no, we can't simply mark the packets with the VMID itself because
>>that already eats up 30 of the 32 bits and there wouldn't be enough
>>space left for the interface number...)
:/
>>I'd really like to just get the damn info... it's not like it's not
>>available for iptables already anyway -_- a `log` rule even prints all
>>of it ...
which info ?
- Mail original -
De: "Wolfgang Bumiller"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Mercredi 28 Novembre 2018 10:54:28
Objet: Re: [pve-devel] pve-firewall : nftables ?
On Wed, Nov 28, 2018 at 09:21:53AM +0100, Alexandre DERUMIER wrote:
> >>sysctl net.bridge.bridge-nf-call-iptables=1
> >>(don't have tested more than this, but i'm seeing vm connections in
> >>conntrack)
>
> Damned, don't work because all is going to ip filter, and tap interface are
> physin/physout in this case
> (and physdev is not supported by nftables)
I mean, it does "work™" if we keep the firewall bridges around, as we
can match on `fwbr404i0` etc...
But it would be nice if we could get rid of those...
I currently only see hacky workarounds for that, though... One way
would be to create indexed chains for each set of guest/interface pairs,
and use the netdev table's ingress hook to mark packets for them...
(And no, we can't simply mark the packets with the VMID itself because
that already eats up 30 of the 32 bits and there wouldn't be enough
space left for the interface number...)
We'd be using up more space in the 'mark' though (currently we only use
1 bit of it). But it would get rid of the extra firewall-bridges...
Like so:
table netdev PVE {
chain veth404i0 {
type filter hook ingress device veth404i0 priority 0; policy accept;
mark set 1
}
}
table inet filter pve {
chain Forward {
type filter hook forward priority 0;
ct state invalid drop
ct state {established, related} return
mark vmap {
1: jump Guest404i0,
2: jump Guest404i1,
...
}
}
chain Guest404i0 {
#put rules for vmid 404 interface 0 here...
}
chain Guest404i1 {
#put rules for vmid 404 interface 1 here...
}
}
I'd really like to just get the damn info... it's not like it's not
available for iptables already anyway -_- a `log` rule even prints all
of it ...
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] pve-firewall : nftables ?
>>sysctl net.bridge.bridge-nf-call-iptables=1
>>(don't have tested more than this, but i'm seeing vm connections in
>>conntrack)
Damned, don't work because all is going to ip filter, and tap interface are
physin/physout in this case
(and physdev is not supported by nftables)
:/
- Mail original -
De: "aderumier"
À: "pve-devel"
Envoyé: Mercredi 28 Novembre 2018 06:57:27
Objet: Re: [pve-devel] pve-firewall : nftables ?
>>Also,
>>it seem than conntrack is not yet implemented on bridge filtering :(
>>
>>seem to be a blocking point for now
I have send a mail to the guy from the paper,
devs are currently working on bridge conntrack.
for now, it's possible to use a workaround, with
sysctl net.bridge.bridge-nf-call-iptables=1
then, something like this seem to work:
nft add table bridge filter
nft add chain bridge filter forward { type filter hook forward priority 0 \; }
nft add rule bridge filter forward log
nft add table filter
nft add chain filter forward { type filter hook forward priority 0 \; }
nft add rule filter forward ct state established,related counter accept
(don't have tested more than this, but i'm seeing vm connections in conntrack)
- Mail original -
De: "aderumier"
À: "pve-devel"
Envoyé: Mardi 27 Novembre 2018 16:55:50
Objet: Re: [pve-devel] pve-firewall : nftables ?
Also,
it seem than conntrack is not yet implemented on bridge filtering :(
seem to be a blocking point for now
- Mail original -
De: "Alexandre Derumier"
À: "Wolfgang Bumiller"
Cc: "pve-devel"
Envoyé: Mardi 27 Novembre 2018 15:19:41
Objet: Re: [pve-devel] pve-firewall : nftables ?
>
>>The issue was that the regular filter forward table isn't really used
>>for bridged traffic (IIRC?), while the bridge filter forward table
>>doesn't have access to conntrack. There may be other ways (at some
>>point I marked packets in the netdev tables), but I haven't checked in
>>a while.
>>At least I haven't produced any kernel crashes in a while ;-D
I have found an interesting paper from netdevconf 1.1 here:
https://www.netdevconf.org/1.1/proceedings/papers/Bridge-filter-with-nftables.pdf
I'll to do some tests in coming week.
>>The pve-firewall code is very iptables-oriented though, and I'm not sure
>>if maybe we're not better off splitting the rule-generating part out
>>and write the nftables variant from scratch...
yes, indeed. could be better to rewrite it from stratch. (and maybe better than
iptables, with all the new features like vmap,...)
>>The iptables part would be considered feature-frozen from that point on I'd
>>say/hope/think...
Still missing some log features.
(Currently I can't have any log on an accept/reject rule)
- Mail original -
De: "Wolfgang Bumiller"
À: "Alexandre Derumier"
Cc: "pve-devel"
Envoyé: Mardi 27 Novembre 2018 14:55:52
Objet: Re: [pve-devel] pve-firewall : nftables ?
On Mon, Nov 26, 2018 at 09:00:47AM +0100, Alexandre DERUMIER wrote:
> Hi,
>
> I would like to known if somebody have already made some test with nftables
> recently ?
>
> Mainly, is not possible to use physdev direction,
>
> like:
>
> -A PVEFW-FWBR-OUT -m physdev --physdev-in tap160i1 --physdev-is-bridged -j
> tap160i1-OUT
>
>
> I wonder if a simple vmap like this could work: ?
>
> https://wiki.nftables.org/wiki-nftables/index.php/Classic_perimetral_firewall_example
>
>
>
> chain forward {
> type filter hook forward priority 0; policy drop;
> jump global
> oifname vmap { $nic_dmz : jump dmz_in , $nic_lan : jump lan_in }
> oifname $nic_inet iifname vmap { $nic_dmz : jump dmz_out , $nic_lan : jump
> lan_out }
> }
The issue was that the regular filter forward table isn't really used
for bridged traffic (IIRC?), while the bridge filter forward table
doesn't have access to conntrack. There may be other ways (at some
point I marked packets in the netdev tables), but I haven't checked in
a while.
At least I haven't produced any kernel crashes in a while ;-D
IIRC the issue with netdev tables on the other hand was that they'd have
to be created after a network device was created. Can't have them "wait
around" for the device. (Not a big deal, just needs a little more
callbacks in our interface creation code and lxc bridge hook.) I'd want
source mac & ip checks to be moved to those tables for outgoing
packets, they happen quite early in the stack.
The pve-firewall code is very iptables-oriented though, and I'm not sure
if maybe we're not better off splitting the rule-g
Re: [pve-devel] pve-firewall : nftables ?
>>Also,
>>it seem than conntrack is not yet implemented on bridge filtering :(
>>
>>seem to be a blocking point for now
I have send a mail to the guy from the paper,
devs are currently working on bridge conntrack.
for now, it's possible to use a workaround, with
sysctl net.bridge.bridge-nf-call-iptables=1
then, something like this seem to work:
nft add table bridge filter
nft add chain bridge filter forward { type filter hook forward priority 0 \; }
nft add rule bridge filter forward log
nft add table filter
nft add chain filter forward { type filter hook forward priority 0 \; }
nft add rule filter forward ct state established,related counter accept
(don't have tested more than this, but i'm seeing vm connections in conntrack)
- Mail original -
De: "aderumier"
À: "pve-devel"
Envoyé: Mardi 27 Novembre 2018 16:55:50
Objet: Re: [pve-devel] pve-firewall : nftables ?
Also,
it seem than conntrack is not yet implemented on bridge filtering :(
seem to be a blocking point for now
- Mail original -
De: "Alexandre Derumier"
À: "Wolfgang Bumiller"
Cc: "pve-devel"
Envoyé: Mardi 27 Novembre 2018 15:19:41
Objet: Re: [pve-devel] pve-firewall : nftables ?
>
>>The issue was that the regular filter forward table isn't really used
>>for bridged traffic (IIRC?), while the bridge filter forward table
>>doesn't have access to conntrack. There may be other ways (at some
>>point I marked packets in the netdev tables), but I haven't checked in
>>a while.
>>At least I haven't produced any kernel crashes in a while ;-D
I have found an interesting paper from netdevconf 1.1 here:
https://www.netdevconf.org/1.1/proceedings/papers/Bridge-filter-with-nftables.pdf
I'll to do some tests in coming week.
>>The pve-firewall code is very iptables-oriented though, and I'm not sure
>>if maybe we're not better off splitting the rule-generating part out
>>and write the nftables variant from scratch...
yes, indeed. could be better to rewrite it from stratch. (and maybe better than
iptables, with all the new features like vmap,...)
>>The iptables part would be considered feature-frozen from that point on I'd
>>say/hope/think...
Still missing some log features.
(Currently I can't have any log on an accept/reject rule)
- Mail original -
De: "Wolfgang Bumiller"
À: "Alexandre Derumier"
Cc: "pve-devel"
Envoyé: Mardi 27 Novembre 2018 14:55:52
Objet: Re: [pve-devel] pve-firewall : nftables ?
On Mon, Nov 26, 2018 at 09:00:47AM +0100, Alexandre DERUMIER wrote:
> Hi,
>
> I would like to known if somebody have already made some test with nftables
> recently ?
>
> Mainly, is not possible to use physdev direction,
>
> like:
>
> -A PVEFW-FWBR-OUT -m physdev --physdev-in tap160i1 --physdev-is-bridged -j
> tap160i1-OUT
>
>
> I wonder if a simple vmap like this could work: ?
>
> https://wiki.nftables.org/wiki-nftables/index.php/Classic_perimetral_firewall_example
>
>
>
> chain forward {
> type filter hook forward priority 0; policy drop;
> jump global
> oifname vmap { $nic_dmz : jump dmz_in , $nic_lan : jump lan_in }
> oifname $nic_inet iifname vmap { $nic_dmz : jump dmz_out , $nic_lan : jump
> lan_out }
> }
The issue was that the regular filter forward table isn't really used
for bridged traffic (IIRC?), while the bridge filter forward table
doesn't have access to conntrack. There may be other ways (at some
point I marked packets in the netdev tables), but I haven't checked in
a while.
At least I haven't produced any kernel crashes in a while ;-D
IIRC the issue with netdev tables on the other hand was that they'd have
to be created after a network device was created. Can't have them "wait
around" for the device. (Not a big deal, just needs a little more
callbacks in our interface creation code and lxc bridge hook.) I'd want
source mac & ip checks to be moved to those tables for outgoing
packets, they happen quite early in the stack.
The pve-firewall code is very iptables-oriented though, and I'm not sure
if maybe we're not better off splitting the rule-generating part out
and write the nftables variant from scratch... The iptables part would
be considered feature-frozen from that point on I'd say/hope/think...
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] pve-firewall : nftables ?
Also,
it seem than conntrack is not yet implemented on bridge filtering :(
seem to be a blocking point for now
- Mail original -
De: "Alexandre Derumier"
À: "Wolfgang Bumiller"
Cc: "pve-devel"
Envoyé: Mardi 27 Novembre 2018 15:19:41
Objet: Re: [pve-devel] pve-firewall : nftables ?
>
>>The issue was that the regular filter forward table isn't really used
>>for bridged traffic (IIRC?), while the bridge filter forward table
>>doesn't have access to conntrack. There may be other ways (at some
>>point I marked packets in the netdev tables), but I haven't checked in
>>a while.
>>At least I haven't produced any kernel crashes in a while ;-D
I have found an interesting paper from netdevconf 1.1 here:
https://www.netdevconf.org/1.1/proceedings/papers/Bridge-filter-with-nftables.pdf
I'll to do some tests in coming week.
>>The pve-firewall code is very iptables-oriented though, and I'm not sure
>>if maybe we're not better off splitting the rule-generating part out
>>and write the nftables variant from scratch...
yes, indeed. could be better to rewrite it from stratch. (and maybe better than
iptables, with all the new features like vmap,...)
>>The iptables part would be considered feature-frozen from that point on I'd
>>say/hope/think...
Still missing some log features.
(Currently I can't have any log on an accept/reject rule)
- Mail original -
De: "Wolfgang Bumiller"
À: "Alexandre Derumier"
Cc: "pve-devel"
Envoyé: Mardi 27 Novembre 2018 14:55:52
Objet: Re: [pve-devel] pve-firewall : nftables ?
On Mon, Nov 26, 2018 at 09:00:47AM +0100, Alexandre DERUMIER wrote:
> Hi,
>
> I would like to known if somebody have already made some test with nftables
> recently ?
>
> Mainly, is not possible to use physdev direction,
>
> like:
>
> -A PVEFW-FWBR-OUT -m physdev --physdev-in tap160i1 --physdev-is-bridged -j
> tap160i1-OUT
>
>
> I wonder if a simple vmap like this could work: ?
>
> https://wiki.nftables.org/wiki-nftables/index.php/Classic_perimetral_firewall_example
>
>
>
> chain forward {
> type filter hook forward priority 0; policy drop;
> jump global
> oifname vmap { $nic_dmz : jump dmz_in , $nic_lan : jump lan_in }
> oifname $nic_inet iifname vmap { $nic_dmz : jump dmz_out , $nic_lan : jump
> lan_out }
> }
The issue was that the regular filter forward table isn't really used
for bridged traffic (IIRC?), while the bridge filter forward table
doesn't have access to conntrack. There may be other ways (at some
point I marked packets in the netdev tables), but I haven't checked in
a while.
At least I haven't produced any kernel crashes in a while ;-D
IIRC the issue with netdev tables on the other hand was that they'd have
to be created after a network device was created. Can't have them "wait
around" for the device. (Not a big deal, just needs a little more
callbacks in our interface creation code and lxc bridge hook.) I'd want
source mac & ip checks to be moved to those tables for outgoing
packets, they happen quite early in the stack.
The pve-firewall code is very iptables-oriented though, and I'm not sure
if maybe we're not better off splitting the rule-generating part out
and write the nftables variant from scratch... The iptables part would
be considered feature-frozen from that point on I'd say/hope/think...
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 qemu-server 6/7] migrate : phase3_cleanup : migrate_external
we don't move original config
---
PVE/QemuMigrate.pm | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 9e963d3..ed8df71 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -1000,6 +1000,8 @@ sub phase3 {
sub phase3_cleanup {
my ($self, $vmid, $err) = @_;
+my $targetvmid = $self->{opts}->{targetvmid} ? $self->{opts}->{targetvmid}
: $vmid;
+
my $conf = $self->{vmconf};
return if $self->{phase2errors};
@@ -1013,7 +1015,7 @@ sub phase3_cleanup {
eval { PVE::QemuServer::qemu_blockjobs_cancel($vmid,
$self->{storage_migration_jobs}) };
eval { PVE::QemuMigrate::cleanup_remotedisks($self) };
die "Failed to completed storage migration\n";
- } else {
+ } elsif (!$self->{opts}->{migration_external}) {
foreach my $target_drive (keys %{$self->{target_drive}}) {
my $drive = PVE::QemuServer::parse_drive($target_drive,
$self->{target_drive}->{$target_drive}->{volid});
$conf->{$target_drive} = PVE::QemuServer::print_drive($vmid,
$drive);
@@ -1022,22 +1024,25 @@ sub phase3_cleanup {
}
}
-# transfer replication state before move config
-$self->transfer_replication_state() if $self->{replicated_volumes};
+if (!$self->{opts}->{migration_external}) {
-# move config to remote node
-my $conffile = PVE::QemuConfig->config_file($vmid);
-my $newconffile = PVE::QemuConfig->config_file($vmid, $self->{node});
+ # transfer replication state before move config
+ $self->transfer_replication_state() if $self->{replicated_volumes};
-die "Failed to move config to node '$self->{node}' - rename failed: $!\n"
-if !rename($conffile, $newconffile);
+ # move config to remote node
+ my $conffile = PVE::QemuConfig->config_file($vmid);
+ my $newconffile = PVE::QemuConfig->config_file($vmid, $self->{node});
-$self->switch_replication_job_target() if $self->{replicated_volumes};
+ die "Failed to move config to node '$self->{node}' - rename failed:
$!\n"
+ if !rename($conffile, $newconffile);
+
+ $self->switch_replication_job_target() if $self->{replicated_volumes};
+}
if ($self->{livemigration}) {
if ($self->{storage_migration}) {
# stop nbd server on remote vm - requirement for resume since 2.9
- my $cmd = [@{$self->{rem_ssh}}, 'qm', 'nbdstop', $vmid];
+ my $cmd = [@{$self->{rem_ssh}}, 'qm', 'nbdstop', $targetvmid];
eval{ PVE::Tools::run_command($cmd, outfunc => sub {}, errfunc =>
sub {}) };
if (my $err = $@) {
@@ -1049,14 +1054,14 @@ sub phase3_cleanup {
# config moved and nbd server stopped - now we can resume vm on target
if ($tunnel && $tunnel->{version} && $tunnel->{version} >= 1) {
eval {
- $self->write_tunnel($tunnel, 30, "resume $vmid");
+ $self->write_tunnel($tunnel, 30, "resume $targetvmid");
};
if (my $err = $@) {
$self->log('err', $err);
$self->{errors} = 1;
}
} else {
- my $cmd = [@{$self->{rem_ssh}}, 'qm', 'resume', $vmid,
'--skiplock', '--nocheck'];
+ my $cmd = [@{$self->{rem_ssh}}, 'qm', 'resume', $targetvmid,
'--skiplock', '--nocheck'];
my $logf = sub {
my $line = shift;
$self->log('err', $line);
@@ -1114,7 +1119,7 @@ sub phase3_cleanup {
$self->{errors} = 1;
}
-if($self->{storage_migration}) {
+if($self->{storage_migration} && !$self->{opts}->{migration_external}) {
# destroy local copies
my $volids = $self->{online_local_volumes};
@@ -1130,7 +1135,7 @@ sub phase3_cleanup {
}
# clear migrate lock
-my $cmd = [ @{$self->{rem_ssh}}, 'qm', 'unlock', $vmid ];
+my $cmd = [ @{$self->{rem_ssh}}, 'qm', 'unlock', $targetvmid ];
$self->cmd_logerr($cmd, errmsg => "failed to clear migrate lock");
}
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 qemu-server 7/7] migrate: add sshkey in /etc/pve/priv/migrate_external/
ssh key need to be in
/etc/pve/priv/migrate_external/id_rsa_mytargetnode
---
PVE/API2/Qemu.pm | 5 +
PVE/QemuMigrate.pm | 2 ++
2 files changed, 7 insertions(+)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index b85fd6d..d31fd96 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -3226,6 +3226,10 @@ __PACKAGE__->register_method({
die "HA must be disable for external migration." if
PVE::HA::Config::vm_is_ha_managed($vmid);
+ my $migration_external_sshkey =
"/etc/pve/priv/migrate_external/id_rsa_$target";
+
+ die "ssh privatekey is missing for $target" if !-e
$migration_external_sshkey;
+
my $targetip = PVE::Network::get_ip_from_hostname($target, 1);
# test if VM exists
@@ -3239,6 +3243,7 @@ __PACKAGE__->register_method({
$param->{online} = 1;
$param->{migration_external} = 1;
+ $param->{migration_external_sshkey} = $migration_external_sshkey;
my $realcmd = sub {
PVE::QemuMigrate->migrate($target, $targetip, $vmid, $param);
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index ed8df71..9942757 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -234,6 +234,8 @@ sub prepare {
if($self->{opts}->{migration_external}) {
+ push @{$self->{rem_ssh}}, '-i',
$self->{opts}->{migration_external_sshkey};
+
#get remote nextvmid
eval {
my $cmd = [@{$self->{rem_ssh}}, 'pvesh', 'get', '/cluster/nextid'];
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 qemu-server 1/7] api2 : add migrate_vm_external
qm migrate_external [--targetstorage otherstorage]
[--targetbridge otherbridge]
---
PVE/API2/Qemu.pm | 79
PVE/CLI/qm.pm| 2 ++
2 files changed, 81 insertions(+)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index c82e2fa..b23db56 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -3162,6 +3162,85 @@ __PACKAGE__->register_method({
}});
__PACKAGE__->register_method({
+name => 'migrate_vm_external',
+path => '{vmid}/migrate_external',
+method => 'POST',
+protected => 1,
+proxyto => 'node',
+description => "Migrate virtual machine to an external cluster. Creates a
new migration task.",
+permissions => {
+ check => ['perm', '/vms/{vmid}', [ 'VM.Migrate' ]],
+},
+parameters => {
+ additionalProperties => 0,
+ properties => {
+ node => get_standard_option('pve-node'),
+ vmid => get_standard_option('pve-vmid', { completion =>
\&PVE::QemuServer::complete_vmid }),
+ target => get_standard_option('pve-node', {
+ description => "Target node.",
+}),
+targetstorage => get_standard_option('pve-storage-id', {
+ description => "Target remote storage.",
+ optional => 1,
+}),
+ targetbridge => {
+ type => 'string',
+ description => "Target remote bridge.",
+ format_description => 'bridge',
+ optional => 1,
+ },
+ },
+},
+returns => {
+ type => 'string',
+ description => "the task ID.",
+},
+code => sub {
+ my ($param) = @_;
+
+ my $rpcenv = PVE::RPCEnvironment::get();
+
+ my $authuser = $rpcenv->get_user();
+
+ die "Only root can do external migration." if $authuser ne 'root@pam';
+
+ my $target = extract_param($param, 'target');
+
+ my $vmid = extract_param($param, 'vmid');
+
+ PVE::Cluster::check_cfs_quorum();
+
+ raise_param_exc({ target => "target is member of local cluster."}) if
PVE::Cluster::check_node_exists($target, 1);
+
+die "HA must be disable for external migration." if
PVE::HA::Config::vm_is_ha_managed($vmid);
+
+ my $targetip = PVE::Network::get_ip_from_hostname($target, 1);
+
+ # test if VM exists
+ my $conf = PVE::QemuConfig->load_config($vmid);
+
+ # try to detect errors early
+
+ PVE::QemuConfig->check_lock($conf);
+
+ die "VM need to be online for external migration" if
!PVE::QemuServer::check_running($vmid);
+
+ $param->{online} = 1;
+ $param->{migration_external} = 1;
+
+ my $realcmd = sub {
+ PVE::QemuMigrate->migrate($target, $targetip, $vmid, $param);
+ };
+
+ my $worker = sub {
+ return PVE::GuestHelpers::guest_migration_lock($vmid, 10, $realcmd);
+ };
+
+ return $rpcenv->fork_worker('qmigrate', $vmid, $authuser, $worker);
+
+}});
+
+__PACKAGE__->register_method({
name => 'monitor',
path => '{vmid}/monitor',
method => 'POST',
diff --git a/PVE/CLI/qm.pm b/PVE/CLI/qm.pm
index eceb9b3..5aa1d48 100755
--- a/PVE/CLI/qm.pm
+++ b/PVE/CLI/qm.pm
@@ -850,6 +850,8 @@ our $cmddef = {
migrate => [ "PVE::API2::Qemu", 'migrate_vm', ['vmid', 'target'], { node
=> $nodename }, $upid_exit ],
+migrate_external => [ "PVE::API2::Qemu", 'migrate_vm_external', ['vmid',
'target'], { node => $nodename }, $upid_exit ],
+
set => [ "PVE::API2::Qemu", 'update_vm', ['vmid'], { node => $nodename } ],
resize => [ "PVE::API2::Qemu", 'resize_vm', ['vmid', 'disk', 'size'], {
node => $nodename } ],
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 qemu-server 5/7] migrate : phase2_cleanup : migrate_external
we destroy target vm in case of failure in phase2
---
PVE/QemuMigrate.pm | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index b4dc8f7..9e963d3 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -915,6 +915,9 @@ sub phase2_cleanup {
my ($self, $vmid, $err) = @_;
return if !$self->{errors};
+
+my $targetvmid = $self->{opts}->{targetvmid} ? $self->{opts}->{targetvmid}
: $vmid;
+
$self->{phase2errors} = 1;
$self->log('info', "aborting phase 2 - cleanup resources");
@@ -948,13 +951,26 @@ sub phase2_cleanup {
my $nodename = PVE::INotify::nodename();
-my $cmd = [@{$self->{rem_ssh}}, 'qm', 'stop', $vmid, '--skiplock',
'--migratedfrom', $nodename];
+my $cmd = [@{$self->{rem_ssh}}, 'qm', 'stop', $targetvmid, '--skiplock'];
+push @$cmd, '--migratedfrom', $nodename if
!$self->{opts}->{migration_external};
+
eval{ PVE::Tools::run_command($cmd, outfunc => sub {}, errfunc => sub {})
};
if (my $err = $@) {
$self->log('err', $err);
$self->{errors} = 1;
}
+if ($self->{opts}->{migration_external}) {
+ my $cmd = [@{$self->{rem_ssh}}, 'qm', 'destroy', $targetvmid,
'--skiplock'];
+
+ eval{ PVE::Tools::run_command($cmd, outfunc => sub {}, errfunc => sub
{}) };
+ if (my $err = $@) {
+ $self->log('err', $err);
+ $self->{errors} = 1;
+ }
+
+}
+
if ($self->{tunnel}) {
eval { finish_tunnel($self, $self->{tunnel}); };
if (my $err = $@) {
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 qemu-server 4/7] migrate : phase2 : migrate external
---
PVE/API2/Qemu.pm | 18 +++---
PVE/QemuMigrate.pm | 21 ++---
PVE/QemuServer.pm | 20
3 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index b23db56..b85fd6d 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -1932,7 +1932,7 @@ __PACKAGE__->register_method({
migratedfrom => get_standard_option('pve-node',{ optional => 1 }),
migration_type => {
type => 'string',
- enum => ['secure', 'insecure'],
+ enum => ['secure', 'insecure', 'external'],
description => "Migration traffic is encrypted using an SSH " .
"tunnel by default. On secure, completely private networks " .
"this can be disabled to increase performance.",
@@ -1948,7 +1948,12 @@ __PACKAGE__->register_method({
description => "Target storage for the migration. (Can be '1'
to use the same storage id as on the source node.)",
type => 'string',
optional => 1
- }
+ },
+ external_migration => {
+ description => "Enable external migration.",
+ type => 'boolean',
+ optional => 1,
+ },
},
},
returns => {
@@ -1994,6 +1999,13 @@ __PACKAGE__->register_method({
raise_param_exc({ targetstorage => "targetstorage can only by used with
migratedfrom." })
if $targetstorage && !$migratedfrom;
+ my $external_migration = extract_param($param, 'external_migration');
+ raise_param_exc({ external_migration => "Only root may use this
option." })
+ if $external_migration && $authuser ne 'root@pam';
+
+ raise_param_exc({ external_migration => "targetstorage can't be used
with external_migration." })
+ if ($targetstorage && $external_migration);
+
# read spice ticket from STDIN
my $spice_ticket;
if ($stateuri && ($stateuri eq 'tcp') && $migratedfrom &&
($rpcenv->{type} eq 'cli')) {
@@ -2034,7 +2046,7 @@ __PACKAGE__->register_method({
syslog('info', "start VM $vmid: $upid\n");
PVE::QemuServer::vm_start($storecfg, $vmid, $stateuri,
$skiplock, $migratedfrom, undef,
- $machine, $spice_ticket,
$migration_network, $migration_type, $targetstorage);
+ $machine, $spice_ticket,
$migration_network, $migration_type, $targetstorage, $external_migration);
return;
};
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 1dea286..b4dc8f7 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -597,7 +597,9 @@ sub phase2 {
my $conf = $self->{vmconf};
-$self->log('info', "starting VM $vmid on remote node '$self->{node}'");
+my $targetvmid = $self->{opts}->{targetvmid} ? $self->{opts}->{targetvmid}
: $vmid;
+
+$self->log('info', "starting VM $targetvmid on remote node
'$self->{node}'");
my $raddr;
my $rport;
@@ -613,10 +615,14 @@ sub phase2 {
$spice_ticket = $res->{ticket};
}
-push @$cmd , 'qm', 'start', $vmid, '--skiplock', '--migratedfrom',
$nodename;
-
my $migration_type = $self->{opts}->{migration_type};
+push @$cmd , 'qm', 'start', $targetvmid, '--skiplock';
+
+push @$cmd, '--migratedfrom', $nodename if
!$self->{opts}->{migration_external};
+
+push @$cmd, '--external_migration' if $self->{opts}->{migration_external};
+
push @$cmd, '--migration_type', $migration_type;
push @$cmd, '--migration_network', $self->{opts}->{migration_network}
@@ -633,7 +639,7 @@ sub phase2 {
}
if ($self->{opts}->{targetstorage}) {
- push @$cmd, '--targetstorage', $self->{opts}->{targetstorage};
+ push @$cmd, '--targetstorage', $self->{opts}->{targetstorage} if
!$self->{opts}->{migration_external};
}
my $spice_port;
@@ -650,7 +656,7 @@ sub phase2 {
}
elsif ($line =~ m!^migration listens on
unix:(/run/qemu-server/(\d+)\.migrate)$!) {
$raddr = $1;
- die "Destination UNIX sockets VMID does not match source VMID" if
$vmid ne $2;
+ die "Destination UNIX sockets VMID does not match source VMID" if
$targetvmid ne $2;
$ruri = "unix:$raddr";
}
elsif ($line =~ m/^migration listens on port (\d+)$/) {
@@ -720,13 +726,14 @@ sub phase2 {
my $start = time();
-if ($self->{opts}->{targetstorage} &&
defined($self->{online_local_volumes})) {
+if (($self->{opts}->{targetstorage} &&
defined($self->{online_local_volumes})) || $self->{opts}->{migration_external})
{
$self->{storage_migration} = 1;
$self->{storage_migration_jobs} = {};
$self->log('info', "starting storage migration");
die "The number of local disks does not match between the source and
the destination.\n"
-
[pve-devel] [PATCH v3 qemu-server 0/7] online vm migration to external cluster
This add support to migrate a vm online to an different external cluster. (This a rework of a previous patch series sent 2years ago) qm migrate_external [--targetstorage otherstorage] [--targetbridge otherbridge] targetstorage && targetbridge are optional, if not defined it's used same name than source targetremotenode is a fqdn host from another cluster. (source node must be able to root ssh to target node with public key) source vm is not deleted currently for safety, just stopped and the migrate lock keeped to avoid to restart it. 1 private ssh key need to be created for each targetremotenode in: /etc/pve/priv/migrate_external/id_rsa_mytargetnode Changelog v3: - prepare : shell_quote arguments in vm create (to escape options like -cpu +spectre;+ssbd;) - phase2 : bugfix for --targetstorage option Changelog v2: - add migrate_external api2 (please check the api root permission) - add targetbridge option - fix targetremotenode fqdn resolution - use pvesh to get nextvmid on remote cluster - add sshkey - add missing "\n" in some die messages. Alexandre Derumier (7): api2 : add migrate_vm_external migrate : prepare : add create_vm for external migration migrate : phase1 : skip sync_disk for external migration migrate : phase2 : migrate external migrate : phase2_cleanup : migrate_external migrate : phase3_cleanup : migrate_external migrate: add sshkey in /etc/pve/priv/migrate_external/ PVE/API2/Qemu.pm | 102 - PVE/CLI/qm.pm | 2 + PVE/QemuMigrate.pm | 164 - PVE/QemuServer.pm | 20 +-- 4 files changed, 253 insertions(+), 35 deletions(-) -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 qemu-server 3/7] migrate : phase1 : skip sync_disk for external migration
we don't need sync_disk as we mirror all disks through qemu
---
PVE/QemuMigrate.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 922d76c..1dea286 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -568,7 +568,7 @@ sub phase1 {
$conf->{lock} = 'migrate';
PVE::QemuConfig->write_config($vmid, $conf);
-sync_disks($self, $vmid);
+sync_disks($self, $vmid) if !$self->{opts}->{migration_external};
};
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 qemu-server 2/7] migrate : prepare : add create_vm for external migration
Create vm on target cluster with same options.
Disks are created with same size and same options than source
---
PVE/QemuMigrate.pm | 88 ++
1 file changed, 83 insertions(+), 5 deletions(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index e9e9075..922d76c 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -227,6 +227,89 @@ sub prepare {
}
}
+# test ssh connection
+my $cmd = [ @{$self->{rem_ssh}}, '/bin/true' ];
+eval { $self->cmd_quiet($cmd); };
+die "Can't connect to destination address using public key\n" if $@;
+
+if($self->{opts}->{migration_external}) {
+
+ #get remote nextvmid
+ eval {
+ my $cmd = [@{$self->{rem_ssh}}, 'pvesh', 'get', '/cluster/nextid'];
+ PVE::Tools::run_command($cmd, outfunc => sub {
+ my $line = shift;
+ if ($line =~ m/^(\d+)/) {
+ $self->{opts}->{targetvmid} = $line;
+ }
+ });
+ };
+if (my $err = $@) {
+$self->log('err', $err);
+$self->{errors} = 1;
+die $err;
+}
+
+ die "can't find the next free vmid on remote cluster\n" if
!$self->{opts}->{targetvmid};
+
+ #create vm
+ my $cmd = [@{$self->{rem_ssh}}, 'qm', 'create',
$self->{opts}->{targetvmid}];
+
+ foreach my $opt (keys %{$conf}) {
+ next if $opt =~ m/^(pending|snapshots|digest|parent)/;
+ next if $opt =~ m/^(ide|scsi|virtio)(\d+)/;
+
+ if ($opt =~ m/^(net)(\d+)/ && $self->{opts}->{targetbridge}) {
+ my $netid = "net$2";
+ my $d = PVE::QemuServer::parse_net($conf->{$netid});
+ $d->{bridge} = $self->{opts}->{targetbridge};
+ $conf->{$opt} = PVE::QemuServer::print_net($d);
+ }
+
+ die "can't migrate unused disk. please remove it before migrate\n"
if $opt =~ m/^(unused)(\d+)/;
+ push @$cmd , "-$opt", PVE::Tools::shellquote($conf->{$opt});
+ }
+
+ PVE::QemuServer::foreach_drive($conf, sub {
+ my ($ds, $drive) = @_;
+
+ if (PVE::QemuServer::drive_is_cdrom($drive, 1)) {
+ push @$cmd , "-$ds", PVE::Tools::shellquote($conf->{$ds});
+ return;
+ }
+
+ my $volid = $drive->{file};
+ return if !$volid;
+
+ my ($sid, $volname) = PVE::Storage::parse_volume_id($volid, 1);
+ return if !$sid;
+ my $size = PVE::Storage::volume_size_info($self->{storecfg},
$volid, 5);
+ die "can't get size\n" if !$size;
+ $size = $size/1024/1024/1024;
+ my $targetsid = $self->{opts}->{targetstorage} ?
$self->{opts}->{targetstorage} : $sid;
+
+ my $data = { %$drive };
+ delete $data->{$_} for qw(index interface file size);
+ my $drive_conf = "$targetsid:$size";
+foreach my $drive_opt (keys %{$data}) {
+ $drive_conf .= ",$drive_opt=$data->{$drive_opt}";
+ }
+
+ push @$cmd , "-$ds", PVE::Tools::shellquote($drive_conf);
+ });
+
+ push @$cmd , '-lock', 'migrate';
+
+ eval{ PVE::Tools::run_command($cmd, outfunc => sub {}, errfunc => sub
{}) };
+ if (my $err = $@) {
+ $self->log('err', $err);
+ $self->{errors} = 1;
+ die $err;
+ }
+
+ return 1;
+}
+
my $vollist = PVE::QemuServer::get_vm_volumes($conf);
my $need_activate = [];
@@ -253,11 +336,6 @@ sub prepare {
# activate volumes
PVE::Storage::activate_volumes($self->{storecfg}, $need_activate);
-# test ssh connection
-my $cmd = [ @{$self->{rem_ssh}}, '/bin/true' ];
-eval { $self->cmd_quiet($cmd); };
-die "Can't connect to destination address using public key\n" if $@;
-
return $running;
}
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] pve-firewall : nftables ?
>
>>The issue was that the regular filter forward table isn't really used
>>for bridged traffic (IIRC?), while the bridge filter forward table
>>doesn't have access to conntrack. There may be other ways (at some
>>point I marked packets in the netdev tables), but I haven't checked in
>>a while.
>>At least I haven't produced any kernel crashes in a while ;-D
I have found an interesting paper from netdevconf 1.1 here:
https://www.netdevconf.org/1.1/proceedings/papers/Bridge-filter-with-nftables.pdf
I'll to do some tests in coming week.
>>The pve-firewall code is very iptables-oriented though, and I'm not sure
>>if maybe we're not better off splitting the rule-generating part out
>>and write the nftables variant from scratch...
yes, indeed. could be better to rewrite it from stratch. (and maybe better than
iptables, with all the new features like vmap,...)
>>The iptables part would be considered feature-frozen from that point on I'd
>>say/hope/think...
Still missing some log features.
(Currently I can't have any log on an accept/reject rule)
- Mail original -
De: "Wolfgang Bumiller"
À: "Alexandre Derumier"
Cc: "pve-devel"
Envoyé: Mardi 27 Novembre 2018 14:55:52
Objet: Re: [pve-devel] pve-firewall : nftables ?
On Mon, Nov 26, 2018 at 09:00:47AM +0100, Alexandre DERUMIER wrote:
> Hi,
>
> I would like to known if somebody have already made some test with nftables
> recently ?
>
> Mainly, is not possible to use physdev direction,
>
> like:
>
> -A PVEFW-FWBR-OUT -m physdev --physdev-in tap160i1 --physdev-is-bridged -j
> tap160i1-OUT
>
>
> I wonder if a simple vmap like this could work: ?
>
> https://wiki.nftables.org/wiki-nftables/index.php/Classic_perimetral_firewall_example
>
>
>
> chain forward {
> type filter hook forward priority 0; policy drop;
> jump global
> oifname vmap { $nic_dmz : jump dmz_in , $nic_lan : jump lan_in }
> oifname $nic_inet iifname vmap { $nic_dmz : jump dmz_out , $nic_lan : jump
> lan_out }
> }
The issue was that the regular filter forward table isn't really used
for bridged traffic (IIRC?), while the bridge filter forward table
doesn't have access to conntrack. There may be other ways (at some
point I marked packets in the netdev tables), but I haven't checked in
a while.
At least I haven't produced any kernel crashes in a while ;-D
IIRC the issue with netdev tables on the other hand was that they'd have
to be created after a network device was created. Can't have them "wait
around" for the device. (Not a big deal, just needs a little more
callbacks in our interface creation code and lxc bridge hook.) I'd want
source mac & ip checks to be moved to those tables for outgoing
packets, they happen quite early in the stack.
The pve-firewall code is very iptables-oriented though, and I'm not sure
if maybe we're not better off splitting the rule-generating part out
and write the nftables variant from scratch... The iptables part would
be considered feature-frozen from that point on I'd say/hope/think...
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] pve-firewall : nftables ?
>>Wasn't nftables mostly iptables compatible?
mostly :/
https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families
Deprecated extensions
-
physdev
br_netfilter aims to be deprecated by nftables.
quota
nfacct already provides quota support.
tos
deprecated by dscp
- Mail original -
De: "Josef Johansson"
À: "pve-devel"
Envoyé: Mardi 27 Novembre 2018 14:58:31
Objet: Re: [pve-devel] pve-firewall : nftables ?
On 11/27/18 2:55 PM, Wolfgang Bumiller wrote:
> On Mon, Nov 26, 2018 at 09:00:47AM +0100, Alexandre DERUMIER wrote:
>> Hi,
>>
>> I would like to known if somebody have already made some test with nftables
>> recently ?
>>
>> Mainly, is not possible to use physdev direction,
>>
>> like:
>>
>> -A PVEFW-FWBR-OUT -m physdev --physdev-in tap160i1 --physdev-is-bridged -j
>> tap160i1-OUT
>>
>>
>> I wonder if a simple vmap like this could work: ?
>>
>> https://wiki.nftables.org/wiki-nftables/index.php/Classic_perimetral_firewall_example
>>
>>
>>
>> chain forward {
>> type filter hook forward priority 0; policy drop;
>> jump global
>> oifname vmap { $nic_dmz : jump dmz_in , $nic_lan : jump lan_in }
>> oifname $nic_inet iifname vmap { $nic_dmz : jump dmz_out , $nic_lan : jump
>> lan_out }
>> }
> The issue was that the regular filter forward table isn't really used
> for bridged traffic (IIRC?), while the bridge filter forward table
> doesn't have access to conntrack. There may be other ways (at some
> point I marked packets in the netdev tables), but I haven't checked in
> a while.
> At least I haven't produced any kernel crashes in a while ;-D
>
> IIRC the issue with netdev tables on the other hand was that they'd have
> to be created after a network device was created. Can't have them "wait
> around" for the device. (Not a big deal, just needs a little more
> callbacks in our interface creation code and lxc bridge hook.) I'd want
> source mac & ip checks to be moved to those tables for outgoing
> packets, they happen quite early in the stack.
>
> The pve-firewall code is very iptables-oriented though, and I'm not sure
> if maybe we're not better off splitting the rule-generating part out
> and write the nftables variant from scratch... The iptables part would
> be considered feature-frozen from that point on I'd say/hope/think...
Wasn't nftables mostly iptables compatible?
Maybe it's a good thing to not freeze the current implementation.
> ___
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
--
Med vänliga hälsningar
Josef Johansson
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] pve-firewall : nftables ?
Hi,
I would like to known if somebody have already made some test with nftables
recently ?
Mainly, is not possible to use physdev direction,
like:
-A PVEFW-FWBR-OUT -m physdev --physdev-in tap160i1 --physdev-is-bridged -j
tap160i1-OUT
I wonder if a simple vmap like this could work: ?
https://wiki.nftables.org/wiki-nftables/index.php/Classic_perimetral_firewall_example
chain forward {
type filter hook forward priority 0; policy drop;
jump global
oifname vmap { $nic_dmz : jump dmz_in , $nic_lan : jump lan_in }
oifname $nic_inet iifname vmap { $nic_dmz : jump dmz_out , $nic_lan :
jump lan_out }
}
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] pve-firewall : log conntrack sessions ?
>>Will look into it. Thanks ! - Mail original - De: "David Limbeck" À: "pve-devel" Envoyé: Mercredi 21 Novembre 2018 11:14:17 Objet: Re: [pve-devel] pve-firewall : log conntrack sessions ? Will look into it. On 11/21/18 7:50 AM, Alexandre DERUMIER wrote: > Hi, > > I'm currently to finally use proxmox firewall in production next year, > > and I missing piece is session logging (create in conntrack, end in > conntrack). > > It's currently possible with ulogd2, but ulogd2 don't start with pve fw > logger is running. > > > I have found a blog about it: > > https://home.regit.org/2014/02/logging-connection-tracking-event-with-ulogd/ > > > It's need to enable : > > echo "1"> /proc/sys/net/netfilter/nf_conntrack_acct > echo "1"> /proc/sys/net/netfilter/nf_conntrack_timestamp > > then ulogd2 listen for 2 netlink events: > > NF_NETLINK_CONNTRACK_NEW: 0x0001 > NF_NETLINK_CONNTRACK_DESTROY: 0x0004 > > https://git.netfilter.org/ulogd2/tree/input/flow/ulogd_inpflow_NFCT.c > > > I'm pretty poor in C , don't known if it's difficult to port this ulogd code > in pve fw logger ? > > ___ > pve-devel mailing list > pve-devel@pve.proxmox.com > https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] pve-firewall : can't have log on drop/reject rules
Hi, I'm not sure it was working before, but I can't get any log for a vm rule with a drop/reject. It's only works with default vm drop/reject action. I found an old patch about adding log by rules https://pve.proxmox.com/pipermail/pve-devel/2017-September/028816.html But I don't see anywhere how to define it in rules. any idea ? ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v2 pve-common] Network : veth pair : fix mtu
The ip link set command which create the veth pair is not setting mtu on both
peers
example:
vm 106 is on a bridge with mtu 9000
222: tap160i1: mtu 9000 qdisc
pfifo_fast master fwbr160i1 state UNKNOWN group default qlen 1000
223: fwbr160i1: mtu 1500 qdisc noqueue state
UP group default qlen 1000
224: fwpr160p1@fwln160i1: mtu 9000 qdisc
noqueue state UP group default qlen 1000
225: fwln160i1@fwpr160p1: mtu 1500 qdisc
noqueue state UP group default qlen 1000
fwpr160p1@fwln160i1 is correctly created with mtu 9000
but
fwln160i1@fwpr160p1 is created with mtu 1500.
(and then vmbr106i1 is lowered to 1500 too).
This is doing network problem, as tap160i1 is mtu9000.
After this patch:
222: tap160i1: mtu 9000 qdisc
pfifo_fast master fwbr160i1 state UNKNOWN group default qlen 1000
223: fwbr160i1: mtu 9000 qdisc noqueue state
UP group default qlen 1000
224: fwpr160p1@fwln160i1: mtu 9000 qdisc
noqueue state UP group default qlen 1000
225: fwln160i1@fwpr160p1: mtu 9000 qdisc
noqueue state UP group default qlen 1000
---
src/PVE/Network.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/PVE/Network.pm b/src/PVE/Network.pm
index 3421532..8dfc9c2 100644
--- a/src/PVE/Network.pm
+++ b/src/PVE/Network.pm
@@ -291,7 +291,7 @@ sub veth_create {
# create veth pair
if (! -d "/sys/class/net/$veth") {
- my $cmd = "/sbin/ip link add name $veth type veth peer name $vethpeer
mtu $bridgemtu";
+ my $cmd = "/sbin/ip link add name $veth mtu $bridgemtu type veth peer
name $vethpeer mtu $bridgemtu";
$cmd .= " addr $mac" if $mac;
system($cmd) == 0 || die "can't create interface $veth\n";
}
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-common] Network : veth pair : fix mtu
The ip link set command which create the veth pair is not setting mtu on both
peers
example:
vm 106 is on a bridge with mtu 9000
222: tap160i1: mtu 9000 qdisc
pfifo_fast master fwbr160i1 state UNKNOWN group default qlen 1000
223: fwbr160i1: mtu 1500 qdisc noqueue state
UP group default qlen 1000
224: fwpr160p1@fwln160i1: mtu 9000 qdisc
noqueue state UP group default qlen 1000
225: fwln160i1@fwpr160p1: mtu 1500 qdisc
noqueue state UP group default qlen 1000
fwpr160p1@fwln160i1 is correctly created with mtu 9000
but
fwln160i1@fwpr160p1 is created with mtu 1500.
(and then vmbr106i1 is lowered to 1500 too).
This is doing network problem, as tap160i1 is mtu9000.
After this patch:
222: tap160i1: mtu 9000 qdisc
pfifo_fast master fwbr160i1 state UNKNOWN group default qlen 1000
223: fwbr160i1: mtu 9000 qdisc noqueue state
UP group default qlen 1000
224: fwpr160p1@fwln160i1: mtu 9000 qdisc
noqueue state UP group default qlen 1000
225: fwln160i1@fwpr160p1: mtu 9000 qdisc
noqueue state UP group default qlen 1000
---
src/PVE/Network.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/PVE/Network.pm b/src/PVE/Network.pm
index 3421532..7cd6fc0 100644
--- a/src/PVE/Network.pm
+++ b/src/PVE/Network.pm
@@ -296,6 +296,8 @@ sub veth_create {
system($cmd) == 0 || die "can't create interface $veth\n";
}
+PVE::Tools::run_command(['/sbin/ip', 'link', 'set', $veth, 'mtu',
$bridgemtu]);
+
# up vethpair
disable_ipv6($veth);
disable_ipv6($vethpeer);
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] pve-firewall : log conntrack sessions ?
Hi, I'm currently to finally use proxmox firewall in production next year, and I missing piece is session logging (create in conntrack, end in conntrack). It's currently possible with ulogd2, but ulogd2 don't start with pve fw logger is running. I have found a blog about it: https://home.regit.org/2014/02/logging-connection-tracking-event-with-ulogd/ It's need to enable : echo "1"> /proc/sys/net/netfilter/nf_conntrack_acct echo "1"> /proc/sys/net/netfilter/nf_conntrack_timestamp then ulogd2 listen for 2 netlink events: NF_NETLINK_CONNTRACK_NEW: 0x0001 NF_NETLINK_CONNTRACK_DESTROY: 0x0004 https://git.netfilter.org/ulogd2/tree/input/flow/ulogd_inpflow_NFCT.c I'm pretty poor in C , don't known if it's difficult to port this ulogd code in pve fw logger ? ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v2 qemu-server 5/7] migrate : phase2_cleanup : migrate_external
we destroy target vm in case of failure in phase2
---
PVE/QemuMigrate.pm | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 87afde6..6059a10 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -913,6 +913,9 @@ sub phase2_cleanup {
my ($self, $vmid, $err) = @_;
return if !$self->{errors};
+
+my $targetvmid = $self->{opts}->{targetvmid} ? $self->{opts}->{targetvmid}
: $vmid;
+
$self->{phase2errors} = 1;
$self->log('info', "aborting phase 2 - cleanup resources");
@@ -946,13 +949,26 @@ sub phase2_cleanup {
my $nodename = PVE::INotify::nodename();
-my $cmd = [@{$self->{rem_ssh}}, 'qm', 'stop', $vmid, '--skiplock',
'--migratedfrom', $nodename];
+my $cmd = [@{$self->{rem_ssh}}, 'qm', 'stop', $targetvmid, '--skiplock'];
+push @$cmd, '--migratedfrom', $nodename if
!$self->{opts}->{migration_external};
+
eval{ PVE::Tools::run_command($cmd, outfunc => sub {}, errfunc => sub {})
};
if (my $err = $@) {
$self->log('err', $err);
$self->{errors} = 1;
}
+if ($self->{opts}->{migration_external}) {
+ my $cmd = [@{$self->{rem_ssh}}, 'qm', 'destroy', $targetvmid,
'--skiplock'];
+
+ eval{ PVE::Tools::run_command($cmd, outfunc => sub {}, errfunc => sub
{}) };
+ if (my $err = $@) {
+ $self->log('err', $err);
+ $self->{errors} = 1;
+ }
+
+}
+
if ($self->{tunnel}) {
eval { finish_tunnel($self, $self->{tunnel}); };
if (my $err = $@) {
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v2 qemu-server 3/7] migrate : phase1 : skip sync_disk for external migration
we don't need sync_disk as we mirror all disks through qemu
---
PVE/QemuMigrate.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index e965e2b..c54f655 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -568,7 +568,7 @@ sub phase1 {
$conf->{lock} = 'migrate';
PVE::QemuConfig->write_config($vmid, $conf);
-sync_disks($self, $vmid);
+sync_disks($self, $vmid) if !$self->{opts}->{migration_external};
};
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v2 qemu-server 2/7] migrate : prepare : add create_vm for external migration
Create vm on target cluster with same options.
Disks are created with same size and same options than source
---
PVE/QemuMigrate.pm | 88 ++
1 file changed, 83 insertions(+), 5 deletions(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index e9e9075..e965e2b 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -227,6 +227,89 @@ sub prepare {
}
}
+# test ssh connection
+my $cmd = [ @{$self->{rem_ssh}}, '/bin/true' ];
+eval { $self->cmd_quiet($cmd); };
+die "Can't connect to destination address using public key\n" if $@;
+
+if($self->{opts}->{migration_external}) {
+
+ #get remote nextvmid
+ eval {
+ my $cmd = [@{$self->{rem_ssh}}, 'pvesh', 'get', '/cluster/nextid'];
+ PVE::Tools::run_command($cmd, outfunc => sub {
+ my $line = shift;
+ if ($line =~ m/^(\d+)/) {
+ $self->{opts}->{targetvmid} = $line;
+ }
+ });
+ };
+if (my $err = $@) {
+$self->log('err', $err);
+$self->{errors} = 1;
+die $err;
+}
+
+ die "can't find the next free vmid on remote cluster\n" if
!$self->{opts}->{targetvmid};
+
+ #create vm
+ my $cmd = [@{$self->{rem_ssh}}, 'qm', 'create',
$self->{opts}->{targetvmid}];
+
+ foreach my $opt (keys %{$conf}) {
+ next if $opt =~ m/^(pending|snapshots|digest|parent)/;
+ next if $opt =~ m/^(ide|scsi|virtio)(\d+)/;
+
+ if ($opt =~ m/^(net)(\d+)/ && $self->{opts}->{targetbridge}) {
+ my $netid = "net$2";
+ my $d = PVE::QemuServer::parse_net($conf->{$netid});
+ $d->{bridge} = $self->{opts}->{targetbridge};
+ $conf->{$opt} = PVE::QemuServer::print_net($d);
+ }
+
+ die "can't migrate unused disk. please remove it before migrate\n"
if $opt =~ m/^(unused)(\d+)/;
+ push @$cmd , "-$opt", $conf->{$opt};
+ }
+
+ PVE::QemuServer::foreach_drive($conf, sub {
+ my ($ds, $drive) = @_;
+
+ if (PVE::QemuServer::drive_is_cdrom($drive, 1)) {
+ push @$cmd , "-$ds", $conf->{$ds};
+ return;
+ }
+
+ my $volid = $drive->{file};
+ return if !$volid;
+
+ my ($sid, $volname) = PVE::Storage::parse_volume_id($volid, 1);
+ return if !$sid;
+ my $size = PVE::Storage::volume_size_info($self->{storecfg},
$volid, 5);
+ die "can't get size\n" if !$size;
+ $size = $size/1024/1024/1024;
+ my $targetsid = $self->{opts}->{targetstorage} ?
$self->{opts}->{targetstorage} : $sid;
+
+ my $data = { %$drive };
+ delete $data->{$_} for qw(index interface file size);
+ my $drive_conf = "$targetsid:$size";
+foreach my $drive_opt (keys %{$data}) {
+ $drive_conf .= ",$drive_opt=$data->{$drive_opt}";
+ }
+
+ push @$cmd , "-$ds", $drive_conf;
+ });
+
+ push @$cmd , '-lock', 'migrate';
+
+ eval{ PVE::Tools::run_command($cmd, outfunc => sub {}, errfunc => sub
{}) };
+ if (my $err = $@) {
+ $self->log('err', $err);
+ $self->{errors} = 1;
+ die $err;
+ }
+
+ return 1;
+}
+
my $vollist = PVE::QemuServer::get_vm_volumes($conf);
my $need_activate = [];
@@ -253,11 +336,6 @@ sub prepare {
# activate volumes
PVE::Storage::activate_volumes($self->{storecfg}, $need_activate);
-# test ssh connection
-my $cmd = [ @{$self->{rem_ssh}}, '/bin/true' ];
-eval { $self->cmd_quiet($cmd); };
-die "Can't connect to destination address using public key\n" if $@;
-
return $running;
}
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v2 qemu-server 0/7] online vm migration to external cluster
This add support to migrate a vm online to an different external cluster. (This a rework of a previous patch series sent 2years ago) qm migrate_external [--targetstorage otherstorage] [--targetbridge otherbridge] targetstorage && targetbridge are optional, if not defined it's used same name than source targetremotenode is a fqdn host from another cluster. (source node must be able to root ssh to target node with public key) source vm is not deleted currently for safety, just stopped and the migrate lock keeped to avoid to restart it. 1 private ssh key need to be created for each targetremotenode in: /etc/pve/priv/migrate_external/id_rsa_mytargetnode Changelog v2: - add migrate_external api2 (please check the api root permission) - add targetbridge option - fix targetremotenode fqdn resolution - use pvesh to get nextvmid on remote cluster - add sshkey - add missing "\n" in some die messages. Alexandre Derumier (7): api2 : add migrate_vm_external migrate : prepare : add create_vm for external migration migrate : phase1 : skip sync_disk for external migration migrate : phase2 : migrate external migrate : phase2_cleanup : migrate_external migrate : phase3_cleanup : migrate_external migrate: add sshkey in /etc/pve/priv/migrate_external/ PVE/API2/Qemu.pm | 104 -- PVE/CLI/qm.pm | 2 + PVE/QemuMigrate.pm | 160 - PVE/QemuServer.pm | 20 +-- 4 files changed, 251 insertions(+), 35 deletions(-) -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v2 qemu-server 4/7] migrate : phase2 : migrate external
---
PVE/API2/Qemu.pm | 20
PVE/QemuMigrate.pm | 17 +++--
PVE/QemuServer.pm | 20
3 files changed, 43 insertions(+), 14 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index e40c6a0..9971e73 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -1932,7 +1932,7 @@ __PACKAGE__->register_method({
migratedfrom => get_standard_option('pve-node',{ optional => 1 }),
migration_type => {
type => 'string',
- enum => ['secure', 'insecure'],
+ enum => ['secure', 'insecure', 'external'],
description => "Migration traffic is encrypted using an SSH " .
"tunnel by default. On secure, completely private networks " .
"this can be disabled to increase performance.",
@@ -1948,7 +1948,12 @@ __PACKAGE__->register_method({
description => "Target storage for the migration. (Can be '1'
to use the same storage id as on the source node.)",
type => 'string',
optional => 1
- }
+ },
+ external_migration => {
+ description => "Enable external migration.",
+ type => 'boolean',
+ optional => 1,
+ },
},
},
returns => {
@@ -1992,7 +1997,14 @@ __PACKAGE__->register_method({
if $targetstorage && $authuser ne 'root@pam';
raise_param_exc({ targetstorage => "targetstorage can only by used with
migratedfrom." })
- if $targetstorage && !$migratedfrom;
+ if $targetstorage && !$migratedfrom && !($migration_type &&
$migration_type eq 'external');
+
+ my $external_migration = extract_param($param, 'external_migration');
+ raise_param_exc({ external_migration => "Only root may use this
option." })
+ if $external_migration && $authuser ne 'root@pam';
+
+ raise_param_exc({ external_migration => "targetstorage can't be used
with external_migration." })
+ if ($targetstorage && $external_migration);
# read spice ticket from STDIN
my $spice_ticket;
@@ -2034,7 +2046,7 @@ __PACKAGE__->register_method({
syslog('info', "start VM $vmid: $upid\n");
PVE::QemuServer::vm_start($storecfg, $vmid, $stateuri,
$skiplock, $migratedfrom, undef,
- $machine, $spice_ticket,
$migration_network, $migration_type, $targetstorage);
+ $machine, $spice_ticket,
$migration_network, $migration_type, $targetstorage, $external_migration);
return;
};
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index c54f655..87afde6 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -597,7 +597,9 @@ sub phase2 {
my $conf = $self->{vmconf};
-$self->log('info', "starting VM $vmid on remote node '$self->{node}'");
+my $targetvmid = $self->{opts}->{targetvmid} ? $self->{opts}->{targetvmid}
: $vmid;
+
+$self->log('info', "starting VM $targetvmid on remote node
'$self->{node}'");
my $raddr;
my $rport;
@@ -613,10 +615,12 @@ sub phase2 {
$spice_ticket = $res->{ticket};
}
-push @$cmd , 'qm', 'start', $vmid, '--skiplock', '--migratedfrom',
$nodename;
-
my $migration_type = $self->{opts}->{migration_type};
+push @$cmd , 'qm', 'start', $targetvmid, '--skiplock';
+
+push @$cmd, '--migratedfrom', $nodename if
!$self->{opts}->{migration_external};
+
push @$cmd, '--migration_type', $migration_type;
push @$cmd, '--migration_network', $self->{opts}->{migration_network}
@@ -650,7 +654,7 @@ sub phase2 {
}
elsif ($line =~ m!^migration listens on
unix:(/run/qemu-server/(\d+)\.migrate)$!) {
$raddr = $1;
- die "Destination UNIX sockets VMID does not match source VMID" if
$vmid ne $2;
+ die "Destination UNIX sockets VMID does not match source VMID" if
$targetvmid ne $2;
$ruri = "unix:$raddr";
}
elsif ($line =~ m/^migration listens on port (\d+)$/) {
@@ -720,13 +724,14 @@ sub phase2 {
my $start = time();
-if ($self->{opts}->{targetstorage} &&
defined($self->{online_local_volumes})) {
+if (($self->{opts}->{targetstorage} &&
defined($self->{online_local_volumes})) || $self->{opts}->{migration_external})
{
$self->{storage_migration} = 1;
$self->{storage_migration_jobs} = {};
$self->log('info', "starting storage migration");
die "The number of local disks does not match between the source and
the destination.\n"
- if (scalar(keys %{$self->{target_drive}}) != scalar
@{$self->{online_local_volumes}});
+ if !$self->{opts}->{migration_external} && (scalar(keys
%{$self->{target_drive}}) != scalar @{$self->{online_local_volumes}});
+
foreach my $drive (keys %{$self->{target_drive}}){
my $
[pve-devel] [PATCH v2 qemu-server 7/7] migrate: add sshkey in /etc/pve/priv/migrate_external/
ssh key need to be in
/etc/pve/priv/migrate_external/id_rsa_mytargetnode
---
PVE/API2/Qemu.pm | 5 +
PVE/QemuMigrate.pm | 2 ++
2 files changed, 7 insertions(+)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 9971e73..549b129 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -3226,6 +3226,10 @@ __PACKAGE__->register_method({
die "HA must be disable for external migration." if
PVE::HA::Config::vm_is_ha_managed($vmid);
+ my $migration_external_sshkey =
"/etc/pve/priv/migrate_external/id_rsa_$target";
+
+ die "ssh privatekey is missing for $target" if !-e
$migration_external_sshkey;
+
my $targetip = PVE::Network::get_ip_from_hostname($target, 1);
# test if VM exists
@@ -3239,6 +3243,7 @@ __PACKAGE__->register_method({
$param->{online} = 1;
$param->{migration_external} = 1;
+ $param->{migration_external_sshkey} = $migration_external_sshkey;
my $realcmd = sub {
PVE::QemuMigrate->migrate($target, $targetip, $vmid, $param);
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index a1d9cdd..84b3b11 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -234,6 +234,8 @@ sub prepare {
if($self->{opts}->{migration_external}) {
+ push @{$self->{rem_ssh}}, '-i',
$self->{opts}->{migration_external_sshkey};
+
#get remote nextvmid
eval {
my $cmd = [@{$self->{rem_ssh}}, 'pvesh', 'get', '/cluster/nextid'];
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v2 qemu-server 6/7] migrate : phase3_cleanup : migrate_external
we don't move original config
---
PVE/QemuMigrate.pm | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 6059a10..a1d9cdd 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -998,6 +998,8 @@ sub phase3 {
sub phase3_cleanup {
my ($self, $vmid, $err) = @_;
+my $targetvmid = $self->{opts}->{targetvmid} ? $self->{opts}->{targetvmid}
: $vmid;
+
my $conf = $self->{vmconf};
return if $self->{phase2errors};
@@ -1011,7 +1013,7 @@ sub phase3_cleanup {
eval { PVE::QemuServer::qemu_blockjobs_cancel($vmid,
$self->{storage_migration_jobs}) };
eval { PVE::QemuMigrate::cleanup_remotedisks($self) };
die "Failed to completed storage migration\n";
- } else {
+ } elsif (!$self->{opts}->{migration_external}) {
foreach my $target_drive (keys %{$self->{target_drive}}) {
my $drive = PVE::QemuServer::parse_drive($target_drive,
$self->{target_drive}->{$target_drive}->{volid});
$conf->{$target_drive} = PVE::QemuServer::print_drive($vmid,
$drive);
@@ -1020,22 +1022,25 @@ sub phase3_cleanup {
}
}
-# transfer replication state before move config
-$self->transfer_replication_state() if $self->{replicated_volumes};
+if (!$self->{opts}->{migration_external}) {
-# move config to remote node
-my $conffile = PVE::QemuConfig->config_file($vmid);
-my $newconffile = PVE::QemuConfig->config_file($vmid, $self->{node});
+ # transfer replication state before move config
+ $self->transfer_replication_state() if $self->{replicated_volumes};
-die "Failed to move config to node '$self->{node}' - rename failed: $!\n"
-if !rename($conffile, $newconffile);
+ # move config to remote node
+ my $conffile = PVE::QemuConfig->config_file($vmid);
+ my $newconffile = PVE::QemuConfig->config_file($vmid, $self->{node});
-$self->switch_replication_job_target() if $self->{replicated_volumes};
+ die "Failed to move config to node '$self->{node}' - rename failed:
$!\n"
+ if !rename($conffile, $newconffile);
+
+ $self->switch_replication_job_target() if $self->{replicated_volumes};
+}
if ($self->{livemigration}) {
if ($self->{storage_migration}) {
# stop nbd server on remote vm - requirement for resume since 2.9
- my $cmd = [@{$self->{rem_ssh}}, 'qm', 'nbdstop', $vmid];
+ my $cmd = [@{$self->{rem_ssh}}, 'qm', 'nbdstop', $targetvmid];
eval{ PVE::Tools::run_command($cmd, outfunc => sub {}, errfunc =>
sub {}) };
if (my $err = $@) {
@@ -1047,14 +1052,14 @@ sub phase3_cleanup {
# config moved and nbd server stopped - now we can resume vm on target
if ($tunnel && $tunnel->{version} && $tunnel->{version} >= 1) {
eval {
- $self->write_tunnel($tunnel, 30, "resume $vmid");
+ $self->write_tunnel($tunnel, 30, "resume $targetvmid");
};
if (my $err = $@) {
$self->log('err', $err);
$self->{errors} = 1;
}
} else {
- my $cmd = [@{$self->{rem_ssh}}, 'qm', 'resume', $vmid,
'--skiplock', '--nocheck'];
+ my $cmd = [@{$self->{rem_ssh}}, 'qm', 'resume', $targetvmid,
'--skiplock', '--nocheck'];
my $logf = sub {
my $line = shift;
$self->log('err', $line);
@@ -1112,7 +1117,7 @@ sub phase3_cleanup {
$self->{errors} = 1;
}
-if($self->{storage_migration}) {
+if($self->{storage_migration} && !$self->{opts}->{migration_external}) {
# destroy local copies
my $volids = $self->{online_local_volumes};
@@ -1128,7 +1133,7 @@ sub phase3_cleanup {
}
# clear migrate lock
-my $cmd = [ @{$self->{rem_ssh}}, 'qm', 'unlock', $vmid ];
+my $cmd = [ @{$self->{rem_ssh}}, 'qm', 'unlock', $targetvmid ];
$self->cmd_logerr($cmd, errmsg => "failed to clear migrate lock");
}
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v2 qemu-server 1/7] api2 : add migrate_vm_external
qm migrate_external [--targetstorage otherstorage]
[--targetbridge otherbridge]
---
PVE/API2/Qemu.pm | 79
PVE/CLI/qm.pm| 2 ++
2 files changed, 81 insertions(+)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index c82e2fa..e40c6a0 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -3162,6 +3162,85 @@ __PACKAGE__->register_method({
}});
__PACKAGE__->register_method({
+name => 'migrate_vm_external',
+path => '{vmid}/migrate_external',
+method => 'POST',
+protected => 1,
+proxyto => 'node',
+description => "Migrate virtual machine to an external cluster. Creates a
new migration task.",
+permissions => {
+ check => ['perm', '/vms/{vmid}', [ 'VM.Migrate' ]],
+},
+parameters => {
+ additionalProperties => 0,
+ properties => {
+ node => get_standard_option('pve-node'),
+ vmid => get_standard_option('pve-vmid', { completion =>
\&PVE::QemuServer::complete_vmid }),
+ target => get_standard_option('pve-node', {
+ description => "Target node.",
+}),
+targetstorage => get_standard_option('pve-storage-id', {
+ description => "Target remote storage.",
+ optional => 1,
+}),
+ targetbridge => {
+ type => 'string',
+ description => "Target remote bridge.",
+ format_description => 'bridge',
+ optional => 1,
+ },
+ },
+},
+returns => {
+ type => 'string',
+ description => "the task ID.",
+},
+code => sub {
+ my ($param) = @_;
+
+ my $rpcenv = PVE::RPCEnvironment::get();
+
+ my $authuser = $rpcenv->get_user();
+
+ die "Only root can do external migration." if $authuser ne 'root@pam';
+
+ my $target = extract_param($param, 'target');
+
+ my $vmid = extract_param($param, 'vmid');
+
+ PVE::Cluster::check_cfs_quorum();
+
+ raise_param_exc({ target => "target is member of local cluster."}) if
PVE::Cluster::check_node_exists($target, 1);
+
+die "HA must be disable for external migration." if
PVE::HA::Config::vm_is_ha_managed($vmid);
+
+ my $targetip = PVE::Network::get_ip_from_hostname($target, 1);
+
+ # test if VM exists
+ my $conf = PVE::QemuConfig->load_config($vmid);
+
+ # try to detect errors early
+
+ PVE::QemuConfig->check_lock($conf);
+
+ die "VM need to be online for external migration" if
!PVE::QemuServer::check_running($vmid);
+
+ $param->{online} = 1;
+ $param->{migration_external} = 1;
+
+ my $realcmd = sub {
+ PVE::QemuMigrate->migrate($target, $targetip, $vmid, $param);
+ };
+
+ my $worker = sub {
+ return PVE::GuestHelpers::guest_migration_lock($vmid, 10, $realcmd);
+ };
+
+ return $rpcenv->fork_worker('qmigrate', $vmid, $authuser, $worker);
+
+}});
+
+__PACKAGE__->register_method({
name => 'monitor',
path => '{vmid}/monitor',
method => 'POST',
diff --git a/PVE/CLI/qm.pm b/PVE/CLI/qm.pm
index eceb9b3..5aa1d48 100755
--- a/PVE/CLI/qm.pm
+++ b/PVE/CLI/qm.pm
@@ -850,6 +850,8 @@ our $cmddef = {
migrate => [ "PVE::API2::Qemu", 'migrate_vm', ['vmid', 'target'], { node
=> $nodename }, $upid_exit ],
+migrate_external => [ "PVE::API2::Qemu", 'migrate_vm_external', ['vmid',
'target'], { node => $nodename }, $upid_exit ],
+
set => [ "PVE::API2::Qemu", 'update_vm', ['vmid'], { node => $nodename } ],
resize => [ "PVE::API2::Qemu", 'resize_vm', ['vmid', 'disk', 'size'], {
node => $nodename } ],
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server 1/7] api2 : migrate_vm : add migration_type "external"
>>@Alexandre: please set the permissions to root@pam only for this new API
>>path.
yes, sure.
>>I see the following problematic aspects otherwise:
>>- potential back channel from a user/attacker-controlled target host to
>>the source node via bugs in Qemu (might not even require a bug?)
>>- enumeration of hosts that root@pam can automatically connect to
>>- intrusion into node/cluster that root@pam can automatically connect to
>>by live-migrating user/attacker-controlled VM there and trying to
>>escape VM (e.g., the bridge/network there might have totally different
>>assumptions about the trustworthiness of the attached guests, the
>>node/cluster might not have the same patch level, etc.pp.)
>>given the above, I am not sure whether a model with explicit public keys
>>to target mapping somewhere in /etc/pve/priv/ might not be preferable
>>even with a limitation to root@pam.
Ok, I'll look at this.
- Mail original -
De: "Fabian Grünbichler"
À: "pve-devel"
Cc: "aderumier"
Envoyé: Mercredi 14 Novembre 2018 11:37:16
Objet: Re: [pve-devel] [PATCH qemu-server 1/7] api2 : migrate_vm : add
migration_type "external"
On Tue, Nov 13, 2018 at 11:22:23AM +0100, Dietmar Maurer wrote:
> I would like to move forward with that, but changing an existing API makes
> that difficult.
>
> I would suggest to add a second API entry point instead:
>
> __PACKAGE__->register_method({
> name => 'external_migrate_vm',
> path => '{vmid}/external_migrate',
> method => 'POST',
> ...
>
> Feel free to choose a better name ;-) We can the mark this API as
> unstable/experimental, and modify
> the parameters/types. IMHO most existing parameters does not really makes
> sense with external migration.
> I guess it is still possible to factor out most common code to avoid code
> duplication.
>
> What do you think?
@Alexandre: please set the permissions to root@pam only for this new API
path.
I see the following problematic aspects otherwise:
- potential back channel from a user/attacker-controlled target host to
the source node via bugs in Qemu (might not even require a bug?)
- enumeration of hosts that root@pam can automatically connect to
- intrusion into node/cluster that root@pam can automatically connect to
by live-migrating user/attacker-controlled VM there and trying to
escape VM (e.g., the bridge/network there might have totally different
assumptions about the trustworthiness of the attached guests, the
node/cluster might not have the same patch level, etc.pp.)
given the above, I am not sure whether a model with explicit public keys
to target mapping somewhere in /etc/pve/priv/ might not be preferable
even with a limitation to root@pam.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server 1/7] api2 : migrate_vm : add migration_type "external"
>>Feel free to choose a better name ;-) We can the mark this API as
>>unstable/experimental, and modify
>>the parameters/types. IMHO most existing parameters does not really makes
>>sense with external migration.
>>I guess it is still possible to factor out most common code to avoid code
>>duplication.
>>
>>What do you think?
ok no problem.
I'll rework my patches next week (I'm on holiday this week).
Also, I out of idea for the qm command name.
'qm migrate_external" ?
- Mail original -
De: "dietmar"
À: "pve-devel" , "aderumier"
Envoyé: Mardi 13 Novembre 2018 11:22:23
Objet: Re: [pve-devel] [PATCH qemu-server 1/7] api2 : migrate_vm : add
migration_type "external"
I would like to move forward with that, but changing an existing API makes that
difficult.
I would suggest to add a second API entry point instead:
__PACKAGE__->register_method({
name => 'external_migrate_vm',
path => '{vmid}/external_migrate',
method => 'POST',
...
Feel free to choose a better name ;-) We can the mark this API as
unstable/experimental, and modify
the parameters/types. IMHO most existing parameters does not really makes sense
with external migration.
I guess it is still possible to factor out most common code to avoid code
duplication.
What do you think?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-manager] Add "SSD" property to IDE, SATA, and SCSI hard drives
>>That's not the case—it's not enabled by default on any controller (my >>previous e-mail shows this for a guest with VirtIO SCSI), and virtio-blk >>doesn't even support the feature. ok, didn't known, thanks. So you have if it can improve ios in guest ? Maybe some ioscheduler use this value ? - Mail original - De: "Nick Chevsky" À: "pve-devel" Cc: "Thomas Lamprecht" Envoyé: Mercredi 7 Novembre 2018 18:59:57 Objet: Re: [pve-devel] [PATCH pve-manager] Add "SSD" property to IDE, SATA, and SCSI hard drives On Wed, Nov 7, 2018 at 12:36 PM Alexandre DERUMIER wrote: > if rotational is already always enabled by default on virtio-scsi && > virtio-blk, > why not enabled it by default for ide,sata, on next qemu version ? > (without any additional option). > That's not the case—it's not enabled by default on any controller (my previous e-mail shows this for a guest with VirtIO SCSI), and virtio-blk doesn't even support the feature. While emulating drives as solid-state could very well be a good *default* in the future, it should probably remain a setting because we don't want to change (and potentially break) people's existing guests. Nick ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-manager] Add "SSD" property to IDE, SATA, and SCSI hard drives
Hi,
my 2cents:
if rotational is already always enabled by default on virtio-scsi && virtio-blk,
why not enabled it by default for ide,sata, on next qemu version ? (without
any additional option).
- Mail original -
De: "Nick Chevsky"
À: "Dominik Csapak"
Cc: "Thomas Lamprecht" , "pve-devel"
Envoyé: Mercredi 7 Novembre 2018 18:20:37
Objet: Re: [pve-devel] [PATCH pve-manager] Add "SSD" property to IDE, SATA, and
SCSI hard drives
I think there may be some confusion here that the "SSD" flag should only be
used with storage that is actually backed by physical SSDs, and that's not
the case: Just like you can emulate hardware in a guest that you don't
actually have in the host, you may want to emulate SSDs in a guest even if
the storage is backed by rotational HDDs. Benefits of this include:
- the ability to reclaim unused space on thin-provisioned storage*
backed by any type of media,
- guest features that may be arbitrarily restricted to SSDs (e.g. APFS
in a certain fruity OS),
- distinctive visual identification of SSDs in some desktop environments.
(*) Even though Proxmox currently restricts the use of the "Discard"
checkbox to SCSI drives, QEMU actually supports this on the IDE and AHCI
buses as well, and turning it on in combination with SSD emulation allows
thin-provisioned space to be reclaimed in guests that can't use the VirtIO
SCSI controller. This is extremely important, and the very reason I
developed these SSD patches in the first place.
Ultimately, I don't think this setting belongs in the storage layer because
it has no dependency on the backing storage, it can be used with backing
media of any type (even mixed), and people may want to have a mix of
HDD/SSD emulation in any given guest. As I explained in my previous reply
to Thomas, we should merely think of this as a new type of emulated
hardware device like any other.
Nick
On Wed, Nov 7, 2018 at 4:19 AM Dominik Csapak wrote:
> After some discussion off-list, there did come up one thing:
>
> would it not make more sense to set this on the storage level and
> inherit it on the disk then? since the storage will most likely be
> the defining factor for this setting
>
> having this setting per disk in the config makes sense ofc,
> but for the average user it would make more sense to set it
> on the storage, no?
>
>
> On 11/7/18 9:23 AM, Thomas Lamprecht wrote:
> > On 11/6/18 5:45 PM, Nick Chevsky wrote:
> >> On Tue, Nov 6, 2018 at 4:28 AM Thomas Lamprecht <
> t.lampre...@proxmox.com>
> >> wrote:
> >>
> >>> On 11/6/18 10:19 AM, Dominik Csapak wrote:
> patch looks good, but maybe we want to put this in the advanced
> options
> >>> instead ? do you have any strong opinion on that @thomas?
> >>>
> >>> Sounds OK, I guess - no strong feeling either way...
> >>>
> >>
> >> I decided on the top section because:
> >>
> >> 1. Rotational vs. solid-state is a major defining property of a
> drive;
> >> if you were shopping for a physical one, this would probably be
> your first
> >> filter.
> >> 2. This property affects how the drive is presented to the guest,
> unlike
> >> most of the advanced properties which are transparent to the guest.
> >> 3. Putting this in the advanced section would've meant adding a new
> row
> >> to the already crowded bottom half of the dialog box.
> >>
> >> That said, I don't mind moving it at all—just let me know your final
> >> thoughts.
> >
> > In general I don't mind either way, your arguments sound OK and I
> > do not find it intrusive, even OK, so it's Dominik's call.
> >
> > But two things:
> >
> > 1) I also have the checkbox enabled for SCSI with virtio-scsi controller,
> > and it's not needed in that case, AFAICT.
> >
> > 2) I'd add a boxLabel with gettext('autodetected') (or similar) when it
> gets
> > disabled, so that user know that they just do not need to set it in
> those
> > cases, not that someone thinks that the virtio stuff is inferior
> because it
> > can't even handle SSDs properly :) Somewhat similar in principle to:
> >
> https://pve.proxmox.com/pipermail/pve-devel/2018-November/034260.html
> >
> >>
> >>> But in general an sentence/note in qm.adoc would be nice regarding
> this,
> >>> SSD may be a bit confusing (see also below for another comment) else.
> >>>
> >>
> >> I do have a pve-docs patch coming up; I wanted to wait until this one
> was
> >> merged in case changes were requested that would affect the
> documentation.
> >>
> >
> > Awesome!
> >
> >>
> > + xtype: 'proxmoxcheckbox',
> > + fieldLabel: gettext('SSD'),
> >>>
> >>> remove the gettext, SSD is verbatim OK and I cannot imagine
> translations
> >>> of it.
> >>>
> >>
> >> Done! I'll send an updated patch once you guys confirm your preference
> on
> >> the location of the checkbox.
> >>
> >
> > OK, much thanks!
> >
>
>
___
pve-devel mailing list
pve-deve
Re: [pve-devel] [PATCH qemu-server 2/7] qm: add nextvmid
>>why not use pvesh to get the next id in cluster instead of adding a new
>>command?
you are right. I dind't known that it was available through api.
"pvesh get /cluster/nextid"
I'll fix this. Thanks.
- Mail original -
De: "David Limbeck"
À: "pve-devel"
Envoyé: Mercredi 7 Novembre 2018 16:25:02
Objet: Re: [pve-devel] [PATCH qemu-server 2/7] qm: add nextvmid
why not use pvesh to get the next id in cluster instead of adding a new
command?
On 10/29/18 4:38 PM, Alexandre Derumier wrote:
> return the next vmid free
> ---
> PVE/API2/Qemu.pm | 1 -
> PVE/CLI/qm.pm | 19 +++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
> index 64eaa0e..ac8b907 100644
> --- a/PVE/API2/Qemu.pm
> +++ b/PVE/API2/Qemu.pm
> @@ -389,7 +389,6 @@ __PACKAGE__->register_method({
> }});
>
>
> -
> __PACKAGE__->register_method({
> name => 'create_vm',
> path => '',
> diff --git a/PVE/CLI/qm.pm b/PVE/CLI/qm.pm
> index 46a7e2f..b1f146d 100755
> --- a/PVE/CLI/qm.pm
> +++ b/PVE/CLI/qm.pm
> @@ -144,6 +144,23 @@ __PACKAGE__->register_method ({
> }});
>
> __PACKAGE__->register_method ({
> + name => 'nextvmid',
> + path => 'nextvmid',
> + method => 'GET',
> + description => "Return next free vmid.",
> + parameters => {
> + additionalProperties => 0,
> + },
> + returns => { type => 'null'},
> + code => sub {
> + my ($param) = @_;
> +
> + my $nextvmid = PVE::Cluster::complete_next_vmid;
> + print $nextvmid->[0];
> + return undef;
> + }});
> +
> +__PACKAGE__->register_method ({
> name => 'status',
> path => 'status',
> method => 'GET',
> @@ -896,6 +913,8 @@ our $cmddef = {
>
> mtunnel => [ __PACKAGE__, 'mtunnel', []],
>
> + nextvmid => [ __PACKAGE__, 'nextvmid', []],
> +
> nbdstop => [ __PACKAGE__, 'nbdstop', ['vmid']],
>
> terminal => [ __PACKAGE__, 'terminal', ['vmid']],
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server 0/7] online vm migration to external cluster
>>Tested it and it seems to overall work. Thanks to have take time to look at this ! >> >>One thing we're still discussing internally is the SSH tunnel, we're not >>sure how we want to go forward (maybe a different solution). We'll let >>you know once we've further discussed this. I have time this month to work on it, keep me in touch. - Mail original - De: "David Limbeck" À: "pve-devel" Envoyé: Mercredi 7 Novembre 2018 16:17:56 Objet: Re: [pve-devel] [PATCH qemu-server 0/7] online vm migration to external cluster Tested it and it seems to overall work. One thing we're still discussing internally is the SSH tunnel, we're not sure how we want to go forward (maybe a different solution). We'll let you know once we've further discussed this. On 10/29/18 4:38 PM, Alexandre Derumier wrote: > This add support to migrate a vm online to an different external cluster. > (This a rework of a previous patch series sent 2years ago) > > > qm migrate --migration_type external > [--targetstorage monpoolceph_vm] --online > > > targetstorage is optional, if not defined it's used same storagename than > source > targetremotenode is a fqdn host from another cluster. > (source node must be able to root ssh to target node with public key) > > source vm is not deleted currently for safety, just stopped and the migrate > lock keeped to avoid > to restart it. > > > Please review and comment > > Alexandre > > Alexandre Derumier (7): > api2 : migrate_vm : add migration_type "external" > qm: add nextvmid > migrate : prepare : add create_vm for external migration > migrate : phase1 : skip sync_disk for external migration > migrate : phase2 : migrate external > migrate : phase2_cleanup : migrate_external > migrate : phase3_cleanup : migrate_external > > PVE/API2/Qemu.pm | 31 +++ > PVE/CLI/qm.pm | 19 +++ > PVE/QemuMigrate.pm | 156 > +++-- > PVE/QemuServer.pm | 24 +++-- > 4 files changed, 188 insertions(+), 42 deletions(-) > ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server 2/7] qm: add nextvmid
return the next vmid free
---
PVE/API2/Qemu.pm | 1 -
PVE/CLI/qm.pm| 19 +++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 64eaa0e..ac8b907 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -389,7 +389,6 @@ __PACKAGE__->register_method({
}});
-
__PACKAGE__->register_method({
name => 'create_vm',
path => '',
diff --git a/PVE/CLI/qm.pm b/PVE/CLI/qm.pm
index 46a7e2f..b1f146d 100755
--- a/PVE/CLI/qm.pm
+++ b/PVE/CLI/qm.pm
@@ -144,6 +144,23 @@ __PACKAGE__->register_method ({
}});
__PACKAGE__->register_method ({
+name => 'nextvmid',
+path => 'nextvmid',
+method => 'GET',
+description => "Return next free vmid.",
+parameters => {
+ additionalProperties => 0,
+},
+returns => { type => 'null'},
+code => sub {
+ my ($param) = @_;
+
+ my $nextvmid = PVE::Cluster::complete_next_vmid;
+ print $nextvmid->[0];
+ return undef;
+}});
+
+__PACKAGE__->register_method ({
name => 'status',
path => 'status',
method => 'GET',
@@ -896,6 +913,8 @@ our $cmddef = {
mtunnel => [ __PACKAGE__, 'mtunnel', []],
+nextvmid => [ __PACKAGE__, 'nextvmid', []],
+
nbdstop => [ __PACKAGE__, 'nbdstop', ['vmid']],
terminal => [ __PACKAGE__, 'terminal', ['vmid']],
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server 6/7] migrate : phase2_cleanup : migrate_external
we destroy target vm in case of failure in phase2
---
PVE/QemuMigrate.pm | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 6eb629b..856a7db 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -907,6 +907,9 @@ sub phase2_cleanup {
my ($self, $vmid, $err) = @_;
return if !$self->{errors};
+
+my $targetvmid = $self->{opts}->{targetvmid} ? $self->{opts}->{targetvmid}
: $vmid;
+
$self->{phase2errors} = 1;
$self->log('info', "aborting phase 2 - cleanup resources");
@@ -940,13 +943,26 @@ sub phase2_cleanup {
my $nodename = PVE::INotify::nodename();
-my $cmd = [@{$self->{rem_ssh}}, 'qm', 'stop', $vmid, '--skiplock',
'--migratedfrom', $nodename];
+my $cmd = [@{$self->{rem_ssh}}, 'qm', 'stop', $targetvmid, '--skiplock'];
+push @$cmd, '--migratedfrom', $nodename if !$self->{migration_external};
+
eval{ PVE::Tools::run_command($cmd, outfunc => sub {}, errfunc => sub {})
};
if (my $err = $@) {
$self->log('err', $err);
$self->{errors} = 1;
}
+if ($self->{migration_external}) {
+ my $cmd = [@{$self->{rem_ssh}}, 'qm', 'destroy', $targetvmid,
'--skiplock'];
+
+ eval{ PVE::Tools::run_command($cmd, outfunc => sub {}, errfunc => sub
{}) };
+ if (my $err = $@) {
+ $self->log('err', $err);
+ $self->{errors} = 1;
+ }
+
+}
+
if ($self->{tunnel}) {
eval { finish_tunnel($self, $self->{tunnel}); };
if (my $err = $@) {
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server 5/7] migrate : phase2 : migrate external
---
PVE/API2/Qemu.pm | 4 ++--
PVE/QemuMigrate.pm | 21 +
PVE/QemuServer.pm | 24 +---
3 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index ac8b907..509747c 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -1927,7 +1927,7 @@ __PACKAGE__->register_method({
migratedfrom => get_standard_option('pve-node',{ optional => 1 }),
migration_type => {
type => 'string',
- enum => ['secure', 'insecure'],
+ enum => ['secure', 'insecure', 'external'],
description => "Migration traffic is encrypted using an SSH " .
"tunnel by default. On secure, completely private networks " .
"this can be disabled to increase performance.",
@@ -1987,7 +1987,7 @@ __PACKAGE__->register_method({
if $targetstorage && $authuser ne 'root@pam';
raise_param_exc({ targetstorage => "targetstorage can only by used with
migratedfrom." })
- if $targetstorage && !$migratedfrom;
+ if $targetstorage && !$migratedfrom && !($migration_type &&
$migration_type eq 'external');
# read spice ticket from STDIN
my $spice_ticket;
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 3e50f07..6eb629b 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -591,7 +591,9 @@ sub phase2 {
my $conf = $self->{vmconf};
-$self->log('info', "starting VM $vmid on remote node '$self->{node}'");
+my $targetvmid = $self->{opts}->{targetvmid} ? $self->{opts}->{targetvmid}
: $vmid;
+
+$self->log('info', "starting VM $targetvmid on remote node
'$self->{node}'");
my $raddr;
my $rport;
@@ -607,11 +609,13 @@ sub phase2 {
$spice_ticket = $res->{ticket};
}
-push @$cmd , 'qm', 'start', $vmid, '--skiplock', '--migratedfrom',
$nodename;
-
my $migration_type = $self->{opts}->{migration_type};
-push @$cmd, '--migration_type', $migration_type;
+push @$cmd , 'qm', 'start', $targetvmid, '--skiplock';
+
+push @$cmd, '--migratedfrom', $nodename if !$self->{migration_external};
+
+push @$cmd, '--migration_type', $self->{opts}->{migration_type};
push @$cmd, '--migration_network', $self->{opts}->{migration_network}
if $self->{opts}->{migration_network};
@@ -644,7 +648,7 @@ sub phase2 {
}
elsif ($line =~ m!^migration listens on
unix:(/run/qemu-server/(\d+)\.migrate)$!) {
$raddr = $1;
- die "Destination UNIX sockets VMID does not match source VMID" if
$vmid ne $2;
+ die "Destination UNIX sockets VMID does not match source VMID" if
$targetvmid ne $2;
$ruri = "unix:$raddr";
}
elsif ($line =~ m/^migration listens on port (\d+)$/) {
@@ -674,7 +678,7 @@ sub phase2 {
$self->log('info', "start remote tunnel");
-if ($migration_type eq 'secure') {
+if ($migration_type eq 'secure' || $migration_type eq 'external') {
if ($ruri =~ /^unix:/) {
unlink $raddr;
@@ -714,13 +718,14 @@ sub phase2 {
my $start = time();
-if ($self->{opts}->{targetstorage} &&
defined($self->{online_local_volumes})) {
+if (($self->{opts}->{targetstorage} &&
defined($self->{online_local_volumes})) || $self->{migration_external}) {
$self->{storage_migration} = 1;
$self->{storage_migration_jobs} = {};
$self->log('info', "starting storage migration");
die "The number of local disks does not match between the source and
the destination.\n"
- if (scalar(keys %{$self->{target_drive}}) != scalar
@{$self->{online_local_volumes}});
+ if !$self->{migration_external} && (scalar(keys
%{$self->{target_drive}}) != scalar @{$self->{online_local_volumes}});
+
foreach my $drive (keys %{$self->{target_drive}}){
my $nbd_uri = $self->{target_drive}->{$drive}->{nbd_uri};
$self->log('info', "$drive: start migration to $nbd_uri");
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 933f54f..37dcf5f 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -4820,8 +4820,26 @@ sub vm_start {
$ENV{PVE_MIGRATED_FROM} = $migratedfrom if $migratedfrom;
my $local_volumes = {};
+ my $external_migration = undef;
- if ($targetstorage) {
+ if ($migration_type && $migration_type eq 'external') {
+ $migration_type = 'secure';
+ $external_migration = 1;
+ }
+
+ if ($external_migration) {
+ foreach_drive($conf, sub {
+ my ($ds, $drive) = @_;
+
+ return if drive_is_cdrom($drive);
+
+ my $volid = $drive->{file};
+
+ return if !$volid;
+
+ $local_volumes->{$ds} = $volid;
+ });
+ } elsif ($targetstorage) {
foreach_drive($conf, sub {
my ($ds, $drive) = @_;
@@ -5007,7 +5025,7 @@ sub
[pve-devel] [PATCH qemu-server 1/7] api2 : migrate_vm : add migration_type "external"
qm migrate --migration_type external [--targetstorage
monpoolceph_vm] --online
Allow to migrate to an external cluster node.
--targetstorage is optionnal, if not defined it's used same storagename than
source
---
PVE/API2/Qemu.pm | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 52f4a5f..64eaa0e 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -3046,7 +3046,7 @@ __PACKAGE__->register_method({
},
migration_type => {
type => 'string',
- enum => ['secure', 'insecure'],
+ enum => ['secure', 'insecure', 'external'],
description => "Migration traffic is encrypted using an SSH
tunnel by default. On secure, completely private networks this can be disabled
to increase performance.",
optional => 1,
},
@@ -3085,7 +3085,7 @@ __PACKAGE__->register_method({
PVE::Cluster::check_cfs_quorum();
- PVE::Cluster::check_node_exists($target);
+ PVE::Cluster::check_node_exists($target) if $param->{migration_type} ne
'external';
my $targetip = PVE::Cluster::remote_node_ip($target);
@@ -3094,6 +3094,13 @@ __PACKAGE__->register_method({
raise_param_exc({ targetstorage => "Live storage migration can only be
done online." })
if !$param->{online} && $param->{targetstorage};
+ raise_param_exc({ migration_type => "external migration can only be
done online." })
+ if !$param->{online} && $param->{migration_type} eq 'external';
+
+ raise_param_exc({ migration_type => "HA must be disable for external
migration." })
+ if PVE::HA::Config::vm_is_ha_managed($vmid) &&
$param->{migration_type} eq 'external';
+
+
raise_param_exc({ force => "Only root may use this option." })
if $param->{force} && $authuser ne 'root@pam';
@@ -3114,17 +3121,22 @@ __PACKAGE__->register_method({
if (PVE::QemuServer::check_running($vmid)) {
die "cant migrate running VM without --online\n"
if !$param->{online};
+ } else {
+ die "vm need to be online for external migration" if
$param->{migration_type} eq 'external';
}
my $storecfg = PVE::Storage::config();
- if( $param->{targetstorage}) {
- PVE::Storage::storage_check_node($storecfg,
$param->{targetstorage}, $target);
-} else {
- PVE::QemuServer::check_storage_availability($storecfg, $conf,
$target);
+ if ($param->{migration_type} ne 'external') {
+
+ if( $param->{targetstorage} ) {
+ PVE::Storage::storage_check_node($storecfg,
$param->{targetstorage}, $target);
+ } else {
+ PVE::QemuServer::check_storage_availability($storecfg, $conf,
$target);
+ }
}
- if (PVE::HA::Config::vm_is_ha_managed($vmid) && $rpcenv->{type} ne
'ha') {
+ if (PVE::HA::Config::vm_is_ha_managed($vmid) && $rpcenv->{type} ne 'ha'
&& $param->{migration_type} ne 'external') {
my $hacmd = sub {
my $upid = shift;
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server 7/7] migrate : phase3_cleanup : migrate_external
we don't move original config
---
PVE/QemuMigrate.pm | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index 856a7db..a36ce85 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -992,6 +992,8 @@ sub phase3 {
sub phase3_cleanup {
my ($self, $vmid, $err) = @_;
+my $targetvmid = $self->{opts}->{targetvmid} ? $self->{opts}->{targetvmid}
: $vmid;
+
my $conf = $self->{vmconf};
return if $self->{phase2errors};
@@ -1005,7 +1007,7 @@ sub phase3_cleanup {
eval { PVE::QemuServer::qemu_blockjobs_cancel($vmid,
$self->{storage_migration_jobs}) };
eval { PVE::QemuMigrate::cleanup_remotedisks($self) };
die "Failed to completed storage migration\n";
- } else {
+ } elsif (!$self->{migration_external}) {
foreach my $target_drive (keys %{$self->{target_drive}}) {
my $drive = PVE::QemuServer::parse_drive($target_drive,
$self->{target_drive}->{$target_drive}->{volid});
$conf->{$target_drive} = PVE::QemuServer::print_drive($vmid,
$drive);
@@ -1014,22 +1016,25 @@ sub phase3_cleanup {
}
}
-# transfer replication state before move config
-$self->transfer_replication_state() if $self->{replicated_volumes};
+if (!$self->{migration_external}) {
-# move config to remote node
-my $conffile = PVE::QemuConfig->config_file($vmid);
-my $newconffile = PVE::QemuConfig->config_file($vmid, $self->{node});
+ # transfer replication state before move config
+ $self->transfer_replication_state() if $self->{replicated_volumes};
-die "Failed to move config to node '$self->{node}' - rename failed: $!\n"
-if !rename($conffile, $newconffile);
+ # move config to remote node
+ my $conffile = PVE::QemuConfig->config_file($vmid);
+ my $newconffile = PVE::QemuConfig->config_file($vmid, $self->{node});
-$self->switch_replication_job_target() if $self->{replicated_volumes};
+ die "Failed to move config to node '$self->{node}' - rename failed:
$!\n"
+ if !rename($conffile, $newconffile);
+
+ $self->switch_replication_job_target() if $self->{replicated_volumes};
+}
if ($self->{livemigration}) {
if ($self->{storage_migration}) {
# stop nbd server on remote vm - requirement for resume since 2.9
- my $cmd = [@{$self->{rem_ssh}}, 'qm', 'nbdstop', $vmid];
+ my $cmd = [@{$self->{rem_ssh}}, 'qm', 'nbdstop', $targetvmid];
eval{ PVE::Tools::run_command($cmd, outfunc => sub {}, errfunc =>
sub {}) };
if (my $err = $@) {
@@ -1041,14 +1046,14 @@ sub phase3_cleanup {
# config moved and nbd server stopped - now we can resume vm on target
if ($tunnel && $tunnel->{version} && $tunnel->{version} >= 1) {
eval {
- $self->write_tunnel($tunnel, 30, "resume $vmid");
+ $self->write_tunnel($tunnel, 30, "resume $targetvmid");
};
if (my $err = $@) {
$self->log('err', $err);
$self->{errors} = 1;
}
} else {
- my $cmd = [@{$self->{rem_ssh}}, 'qm', 'resume', $vmid,
'--skiplock', '--nocheck'];
+ my $cmd = [@{$self->{rem_ssh}}, 'qm', 'resume', $targetvmid,
'--skiplock', '--nocheck'];
my $logf = sub {
my $line = shift;
$self->log('err', $line);
@@ -1106,7 +,7 @@ sub phase3_cleanup {
$self->{errors} = 1;
}
-if($self->{storage_migration}) {
+if($self->{storage_migration} && !$self->{migration_external}) {
# destroy local copies
my $volids = $self->{online_local_volumes};
@@ -1122,7 +1127,7 @@ sub phase3_cleanup {
}
# clear migrate lock
-my $cmd = [ @{$self->{rem_ssh}}, 'qm', 'unlock', $vmid ];
+my $cmd = [ @{$self->{rem_ssh}}, 'qm', 'unlock', $targetvmid ];
$self->cmd_logerr($cmd, errmsg => "failed to clear migrate lock");
}
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server 3/7] migrate : prepare : add create_vm for external migration
Create vm on target cluster with same options.
Disks are created with same size and same options than source
---
PVE/QemuMigrate.pm | 82 ++
1 file changed, 77 insertions(+), 5 deletions(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index e9e9075..ce43fc9 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -227,6 +227,83 @@ sub prepare {
}
}
+# test ssh connection
+my $cmd = [ @{$self->{rem_ssh}}, '/bin/true' ];
+eval { $self->cmd_quiet($cmd); };
+die "Can't connect to destination address using public key\n" if $@;
+
+$self->{migration_external} = 1 if $self->{opts}->{migration_type} &&
$self->{opts}->{migration_type} eq 'external';
+
+if($self->{migration_external}) {
+
+ #get remote nextvmid
+ eval {
+ my $cmd = [@{$self->{rem_ssh}}, 'qm', 'nextvmid'];
+ PVE::Tools::run_command($cmd, outfunc => sub {
+ my $line = shift;
+ if ($line =~ m/^(\d+)/) {
+ $self->{opts}->{targetvmid} = $line;
+ }
+ });
+ };
+if (my $err = $@) {
+$self->log('err', $err);
+$self->{errors} = 1;
+die $err;
+}
+
+ die "can't find the next free vmid on remote cluster" if
!$self->{opts}->{targetvmid};
+
+ #create vm
+ my $cmd = [@{$self->{rem_ssh}}, 'qm', 'create',
$self->{opts}->{targetvmid}];
+
+ foreach my $opt (keys %{$conf}) {
+ next if $opt =~ m/^(pending|snapshots|digest|parent)/;
+ next if $opt =~ m/^(ide|scsi|virtio)(\d+)/;
+ die "can't migrate unused disk. please remove it before migrate" if
$opt =~ m/^(unused)(\d+)/;
+ push @$cmd , "-$opt", $conf->{$opt};
+ }
+
+ PVE::QemuServer::foreach_drive($conf, sub {
+ my ($ds, $drive) = @_;
+
+ if (PVE::QemuServer::drive_is_cdrom($drive, 1)) {
+ push @$cmd , "-$ds", $conf->{$ds};
+ return;
+ }
+
+ my $volid = $drive->{file};
+ return if !$volid;
+
+ my ($sid, $volname) = PVE::Storage::parse_volume_id($volid, 1);
+ return if !$sid;
+ my $size = PVE::Storage::volume_size_info($self->{storecfg},
$volid, 5);
+ die "can't get size" if !$size;
+ $size = $size/1024/1024/1024;
+ my $targetsid = $self->{opts}->{targetstorage} ?
$self->{opts}->{targetstorage} : $sid;
+
+ my $data = { %$drive };
+ delete $data->{$_} for qw(index interface file size);
+ my $drive_conf = "$targetsid:$size";
+foreach my $drive_opt (keys %{$data}) {
+ $drive_conf .= ",$drive_opt=$data->{$drive_opt}";
+ }
+
+ push @$cmd , "-$ds", $drive_conf;
+ });
+
+ push @$cmd , '-lock', 'migrate';
+
+ eval{ PVE::Tools::run_command($cmd, outfunc => sub {}, errfunc => sub
{}) };
+ if (my $err = $@) {
+ $self->log('err', $err);
+ $self->{errors} = 1;
+ die $err;
+ }
+
+ return 1;
+}
+
my $vollist = PVE::QemuServer::get_vm_volumes($conf);
my $need_activate = [];
@@ -253,11 +330,6 @@ sub prepare {
# activate volumes
PVE::Storage::activate_volumes($self->{storecfg}, $need_activate);
-# test ssh connection
-my $cmd = [ @{$self->{rem_ssh}}, '/bin/true' ];
-eval { $self->cmd_quiet($cmd); };
-die "Can't connect to destination address using public key\n" if $@;
-
return $running;
}
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server 0/7] online vm migration to external cluster
This add support to migrate a vm online to an different external cluster. (This a rework of a previous patch series sent 2years ago) qm migrate --migration_type external [--targetstorage monpoolceph_vm] --online targetstorage is optional, if not defined it's used same storagename than source targetremotenode is a fqdn host from another cluster. (source node must be able to root ssh to target node with public key) source vm is not deleted currently for safety, just stopped and the migrate lock keeped to avoid to restart it. Please review and comment Alexandre Alexandre Derumier (7): api2 : migrate_vm : add migration_type "external" qm: add nextvmid migrate : prepare : add create_vm for external migration migrate : phase1 : skip sync_disk for external migration migrate : phase2 : migrate external migrate : phase2_cleanup : migrate_external migrate : phase3_cleanup : migrate_external PVE/API2/Qemu.pm | 31 +++ PVE/CLI/qm.pm | 19 +++ PVE/QemuMigrate.pm | 156 +++-- PVE/QemuServer.pm | 24 +++-- 4 files changed, 188 insertions(+), 42 deletions(-) -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server 4/7] migrate : phase1 : skip sync_disk for external migration
we don't need sync_disk as we mirror all disks through qemu
---
PVE/QemuMigrate.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/QemuMigrate.pm b/PVE/QemuMigrate.pm
index ce43fc9..3e50f07 100644
--- a/PVE/QemuMigrate.pm
+++ b/PVE/QemuMigrate.pm
@@ -562,7 +562,7 @@ sub phase1 {
$conf->{lock} = 'migrate';
PVE::QemuConfig->write_config($vmid, $conf);
-sync_disks($self, $vmid);
+sync_disks($self, $vmid) if !$self->{migration_external};
};
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-manager] add 'ssbd', 'ibpb', 'virt-ssbd', 'amd-ssbd', 'amd-no-ssb' cpu flags option
Hi,
does someboydy had time to work on it ?
I don't known how to implemented this with extjs. (grid/combo with checkbox)
- Mail original -
De: "aderumier"
À: "Thomas Lamprecht"
Cc: "pve-devel"
Envoyé: Lundi 3 Septembre 2018 10:17:55
Objet: Re: [pve-devel] [PATCH pve-manager] add 'ssbd', 'ibpb', 'virt-ssbd',
'amd-ssbd', 'amd-no-ssb' cpu flags option
>>I think we need another way to show this...
>>Having it like this is very confusing, IMO, and there will probably come
>>more.
yes, I was thinking the same. Waiting for spectre v100 ;)
>>Maybe a grid with checkboxes, a flag name column and a description column
>>where we can put at least a minimal description about what this is?
>>A combobox (with same grid and multiselect) could be done too, would need
>>less
>>space, so maybe even better.
yes, indeed, could be great :)
also, some flag are for amd and other for intel, it could be great to be able
to filter
list from the cpu model.
- Mail original -
De: "Thomas Lamprecht"
À: "pve-devel" , "aderumier"
Envoyé: Lundi 3 Septembre 2018 08:41:43
Objet: Re: [pve-devel] [PATCH pve-manager] add 'ssbd', 'ibpb', 'virt-ssbd',
'amd-ssbd', 'amd-no-ssb' cpu flags option
On 9/2/18 7:54 AM, Alexandre Derumier wrote:
> ---
> www/manager6/qemu/ProcessorEdit.js | 42
> +-
> 1 file changed, 37 insertions(+), 5 deletions(-)
>
> diff --git a/www/manager6/qemu/ProcessorEdit.js
> b/www/manager6/qemu/ProcessorEdit.js
> index 3ecea205..eaec0773 100644
> --- a/www/manager6/qemu/ProcessorEdit.js
> +++ b/www/manager6/qemu/ProcessorEdit.js
> @@ -44,7 +44,7 @@ Ext.define('PVE.qemu.ProcessorInputPanel', {
>
> var flags = [];
>
> - ['pcid', 'spec-ctrl'].forEach(function(flag) {
> + ['pcid', 'spec-ctrl', 'ssbd', 'ibpb', 'virt-ssbd', 'amd-ssbd',
> 'amd-no-ssb'].forEach(function(flag) {
> if (values[flag]) {
> flags.push('+' + flag.toString());
> }
> @@ -150,7 +150,26 @@ Ext.define('PVE.qemu.ProcessorInputPanel', {
> value: '1024',
> deleteEmpty: true,
> allowBlank: true
> + },
> + {
> + xtype: 'proxmoxcheckbox',
> + fieldLabel: 'PCID',
> + name: 'pcid',
> + uncheckedValue: 0
> + },
> + {
> + xtype: 'proxmoxcheckbox',
> + fieldLabel: 'SPEC-CTRL',
> + name: 'spec-ctrl',
> + uncheckedValue: 0
> + },
> + {
> + xtype: 'proxmoxcheckbox',
> + fieldLabel: 'SSBD',
> + name: 'ssbd',
> + uncheckedValue: 0
> }
> +
> ],
>
> advancedColumn2: [
> @@ -162,16 +181,29 @@ Ext.define('PVE.qemu.ProcessorInputPanel', {
> },
> {
> xtype: 'proxmoxcheckbox',
> - fieldLabel: 'PCID',
> - name: 'pcid',
> + fieldLabel: 'IBPB',
> + name: 'ibpb',
> uncheckedValue: 0
> },
> {
> xtype: 'proxmoxcheckbox',
> - fieldLabel: 'SPEC-CTRL',
> - name: 'spec-ctrl',
> + fieldLabel: 'VIRT-SSBD',
> + name: 'virt-ssbd',
> + uncheckedValue: 0
> + },
> + {
> + xtype: 'proxmoxcheckbox',
> + fieldLabel: 'AMD-SSBD',
> + name: 'amd-ssbd',
> + uncheckedValue: 0
> + },
> + {
> + xtype: 'proxmoxcheckbox',
> + fieldLabel: 'AMD-NO-SSB',
> + name: 'amd-no-ssb',
> uncheckedValue: 0
> }
> +
> ]
> });
>
I think we need another way to show this...
Having it like this is very confusing, IMO, and there will probably come more.
Maybe a grid with checkboxes, a flag name column and a description column
where we can put at least a minimal description about what this is?
A combobox (with same grid and multiselect) could be done too, would need less
space, so maybe even better.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server 4/4] implement a 'real' reboot for vms
Wonderful !
It could be great to have something like, shutdown (clean shutdown) + start.
- Mail original -
De: "Dominik Csapak"
À: "pve-devel"
Envoyé: Mardi 16 Octobre 2018 12:07:06
Objet: [pve-devel] [PATCH qemu-server 4/4] implement a 'real' reboot for vms
instead of letting qemu handle a reset, add '-no-reboot' by default
(>= qemu 3.0) and use our cleanup to start the vm again
this has the advantage that pending changes will be applied
on a reboot from within the guest, starts with a new qemu version
and enables us to have a 'reboot' button in the future
(more work for this is needed)
it still respects the 'reboot' config we had
Signed-off-by: Dominik Csapak
---
PVE/CLI/qm.pm | 22 ++
PVE/QemuServer.pm | 7 ++-
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/PVE/CLI/qm.pm b/PVE/CLI/qm.pm
index 6a14c12..8772e8c 100755
--- a/PVE/CLI/qm.pm
+++ b/PVE/CLI/qm.pm
@@ -758,6 +758,8 @@ __PACKAGE__->register_method({
my $guest = $param->{'guest-requested'};
my $reset = $param->{'was-reset'};
+ my $needs_reset = 0;
+
my $storecfg = PVE::Storage::config();
PVE::QemuConfig->lock_config($vmid, sub {
@@ -780,8 +782,28 @@ __PACKAGE__->register_method({
# vm was shutdown from inside the guest or crashed, doing api cleanup
PVE::QemuServer::vm_stop_cleanup($storecfg, $vmid, $conf, 0, 0);
}
+
+ if ((!defined($conf->{reboot}) || $conf->{reboot}) && $reset) {
+ $needs_reset = 1;
+ }
});
+ if ($needs_reset) {
+ my $rpcenv = PVE::RPCEnvironment::get();
+ my $authuser = $rpcenv->get_user();
+ # got reset parameter, we should start the vm again
+ my $realcmd = sub {
+ my $upid = shift;
+
+ syslog('info', "restart VM $vmid: $upid\n");
+
+ PVE::QemuServer::vm_start($storecfg, $vmid);
+ return;
+ };
+
+ $rpcenv->fork_worker('qmrestart', $vmid, $authuser, $realcmd);
+ }
+
return undef;
}});
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index 4838e79..7dad560 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -3402,7 +3402,12 @@ sub config_to_command {
push @$cmd, '-no-acpi' if defined($conf->{acpi}) && $conf->{acpi} == 0;
- push @$cmd, '-no-reboot' if defined($conf->{reboot}) && $conf->{reboot} == 0;
+ # we add it by default and check in the cleanup call if we want to start
+ # it again
+ if ((defined($conf->{reboot}) && $conf->{reboot} == 0) ||
+ qemu_machine_feature_enabled($machine_type, $kvmver, 3, 0)) {
+ push @$cmd, '-no-reboot' if defined($conf->{reboot}) && $conf->{reboot} == 0;
+ }
push @$cmd, '-vga', $vga if $vga && $vga !~ m/^serial\d+$/; # for kvm 77 and
later
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-docs] vxlan evpn : remove rp_filter=0 for symetric model
This seem be to fixed in frr 6.0. (it was packetloss with vm migration, race condition when refreshing routing table) --- vxlan-and-evpn.adoc | 3 --- 1 file changed, 3 deletions(-) diff --git a/vxlan-and-evpn.adoc b/vxlan-and-evpn.adoc index 5115d78..66194e2 100644 --- a/vxlan-and-evpn.adoc +++ b/vxlan-and-evpn.adoc @@ -780,9 +780,6 @@ sysctl.conf tuning #enable routing net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1 -#disable reverse path filtering -net.ipv4.conf.default.rp_filter=0 -net.ipv4.conf.all.rp_filter=0 * node1 -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 frr 6/8] d/rules: delay restart on upgrade
--- debian/rules | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/debian/rules b/debian/rules index 811d45b..ab9c4c5 100755 --- a/debian/rules +++ b/debian/rules @@ -193,11 +193,14 @@ override_dh_auto_install: sed -i "/dependency_libs/ s/'.*'/''/" debian/tmp/usr/lib/*.la sed -i "/dependency_libs/ s/'.*'/''/" debian/tmp/usr/lib/frr/modules/*.la +override_dh_install_init: + dh_installinit --restart-after-upgrade + override_dh_systemd_start: dh_systemd_start frr.service override_dh_systemd_enable: - dh_systemd_enable frr.service + dh_systemd_enable --restart-after-upgrade frr.service # backports SRCPKG = frr -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 frr 8/8] enable zebra && bgp daemons by default
--- .../pve/0001-enable-zebra-and-bgp-daemons.patch| 27 ++ debian/patches/series | 1 + 2 files changed, 28 insertions(+) create mode 100644 debian/patches/pve/0001-enable-zebra-and-bgp-daemons.patch create mode 100644 debian/patches/series diff --git a/debian/patches/pve/0001-enable-zebra-and-bgp-daemons.patch b/debian/patches/pve/0001-enable-zebra-and-bgp-daemons.patch new file mode 100644 index 000..40fc7e8 --- /dev/null +++ b/debian/patches/pve/0001-enable-zebra-and-bgp-daemons.patch @@ -0,0 +1,27 @@ +From b39c6b5bc6835fac2ad91f7805f77089a38685a6 Mon Sep 17 00:00:00 2001 +From: Alexandre Derumier +Date: Fri, 15 Jun 2018 03:18:54 +0200 +Subject: [PATCH] enable zebra and bgp daemons + +--- + tools/etc/frr/daemons | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/tools/etc/frr/daemons b/tools/etc/frr/daemons +index 9a96c0490..c93e8dbd4 100644 +--- a/tools/etc/frr/daemons b/tools/etc/frr/daemons +@@ -21,8 +21,8 @@ + # The watchfrr daemon is always started. Per default in monitoring-only but + # that can be changed via /etc/frr/daemons.conf. + # +-zebra=no +-bgpd=no ++zebra=yes ++bgpd=yes + ospfd=no + ospf6d=no + ripd=no +-- +2.11.0 + diff --git a/debian/patches/series b/debian/patches/series new file mode 100644 index 000..95258cc --- /dev/null +++ b/debian/patches/series @@ -0,0 +1 @@ +pve/0001-enable-zebra-and-bgp-daemons.patch -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 frr 0/8] frr 6.0 package
changelog v3: - bump to 6.0 - remove cumulus_mode patch. (vxlan support is enabled by default now) - add a build depend on python3-dev changelog v2: -bump to 5.0.1 (fix a vrf bug needed for vxlan) -remove some patches not needed This add package for frr routing software 6.0. https://github.com/FRRouting/frr I have take inspiration from this packaging https://github.com/exoscale/pkg-frr/ This is needed for vxlan + bgp-evpn implementation. *** BLURB HERE *** Alexandre Derumier (8): add Makefile add frr git submodule import debianpkg directory as debian add python3-dev to build dependencies add proxmox release in debian/changelog d/rules: delay restart on upgrade source: switch to 3.0 (quilt) format enable zebra && bgp daemons by default -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 frr 2/8] add frr git submodule
--- .gitmodules | 3 +++ frr | 1 + 2 files changed, 4 insertions(+) create mode 100644 .gitmodules create mode 16 frr diff --git a/.gitmodules b/.gitmodules new file mode 100644 index 000..5f1c9e1 --- /dev/null +++ b/.gitmodules @@ -0,0 +1,3 @@ +[submodule "frr"] + path = frr + url = https://github.com/FRRouting/frr diff --git a/frr b/frr new file mode 16 index 000..c8c2427 --- /dev/null +++ b/frr @@ -0,0 +1 @@ +Subproject commit c8c24278b1d1da271089a36303bb7708568ce231 -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 frr 1/8] add Makefile
---
Makefile | 43 +++
1 file changed, 43 insertions(+)
create mode 100644 Makefile
diff --git a/Makefile b/Makefile
new file mode 100644
index 000..18861d0
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,43 @@
+PACKAGE=frr
+VER=6.0
+PKGREL=0+pve
+
+SRCDIR=frr
+BUILDDIR=${SRCDIR}.tmp
+
+ARCH:=$(shell dpkg-architecture -qDEB_BUILD_ARCH)
+
+GITVERSION:=$(shell git rev-parse HEAD)
+
+DEB=${PACKAGE}_${VER}-${PKGREL}_${ARCH}.deb
+
+all: ${DEB}
+ @echo ${DEB}
+
+.PHONY: submodule
+submodule:
+ test -f "${SRCDIR}/debianpkg/changelog" || git submodule update --init
+
+.PHONY: deb
+deb: ${DEB}
+${DEB}: | submodule
+ rm -f *.deb
+ rm -rf $(BUILDDIR)
+ cp -rpa ${SRCDIR} ${BUILDDIR}
+ cp -a debian ${BUILDDIR}
+ cd ${BUILDDIR}; dpkg-buildpackage -rfakeroot -b -uc -us
+
+.PHONY: upload
+upload: ${DEB}
+ tar cf - ${DEB}|ssh -X repo...@repo.proxmox.com -- upload --product
pmg,pve --dist stretch
+
+.PHONY: distclean
+distclean: clean
+
+.PHONY: clean
+clean:
+ rm -rf *~ debian/*~ *.deb ${BUILDDIR} *.changes *.dsc *.buildinfo
+
+.PHONY: dinstall
+dinstall: deb
+ dpkg -i ${DEB}
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 frr 7/8] source: switch to 3.0 (quilt) format
--- debian/source/format | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/source/format b/debian/source/format index af745b3..163aaf8 100644 --- a/debian/source/format +++ b/debian/source/format @@ -1 +1 @@ -3.0 (git) +3.0 (quilt) -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 frr 4/8] add python3-dev to build dependencies
--- debian/control | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/control b/debian/control index 71c412a..829e302 100644 --- a/debian/control +++ b/debian/control @@ -4,7 +4,7 @@ Priority: optional Maintainer: Nobody Uploaders: Nobody XSBC-Original-Maintainer: -Build-Depends: debhelper (>= 7.0.50~), libncurses5-dev, libreadline-dev, texlive-latex-base, texlive-generic-recommended, libpam0g-dev | libpam-dev, libcap-dev, texinfo (>= 4.7), autotools-dev, libpcre3-dev, gawk, chrpath, libsnmp-dev, git, dh-autoreconf, libjson-c-dev, libjson-c2 | libjson-c3, dh-systemd, libsystemd-dev, bison, flex, libc-ares-dev, pkg-config, python (>= 2.7), python-ipaddr, python-sphinx, libpython-dev, install-info +Build-Depends: debhelper (>= 7.0.50~), libncurses5-dev, libreadline-dev, texlive-latex-base, texlive-generic-recommended, libpam0g-dev | libpam-dev, libcap-dev, texinfo (>= 4.7), autotools-dev, libpcre3-dev, gawk, chrpath, libsnmp-dev, git, dh-autoreconf, libjson-c-dev, libjson-c2 | libjson-c3, dh-systemd, libsystemd-dev, bison, flex, libc-ares-dev, pkg-config, python (>= 2.7), python-ipaddr, python-sphinx, libpython-dev, install-info, python3-dev Standards-Version: 3.9.6 Homepage: http://www.frrouting.org/ -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 frr 5/8] add proxmox release in debian/changelog
---
debian/{changelog.in => changelog} | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
rename debian/{changelog.in => changelog} (99%)
diff --git a/debian/changelog.in b/debian/changelog
similarity index 99%
rename from debian/changelog.in
rename to debian/changelog
index 67d3480..753347b 100644
--- a/debian/changelog.in
+++ b/debian/changelog
@@ -1,4 +1,10 @@
-frr (@VERSION@) RELEASED; urgency=medium
+frr (6.0-0+pve) RELEASED; urgency=medium
+
+ * Proxmox initial release.
+
+ -- Alexandre Derumier Mon, 15 Oct 2018 04:46:06 +0200
+
+frr (6.0-0) RELEASED; urgency=medium
* Staticd: New daemon responsible for management of static routes
* ISISd: Implement dst-src routing as per
draft-ietf-isis-ipv6-dst-src-routing
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [RFC PATCH qemu-server] add qemumonitor.c
>>yes you are right, my idea was to have a second qmp socket just >>for those events, ok, great ! >> and of course we could extend it to also >>react to other events (i have no idea what might be interesting >>besides the shutdown event) don't have idea for now (maybe catch disk-io errors), but could be interesting indeed. - Mail original - De: "Dominik Csapak" À: "pve-devel" Envoyé: Mardi 9 Octobre 2018 16:58:24 Objet: Re: [pve-devel] [RFC PATCH qemu-server] add qemumonitor.c On 10/9/18 4:50 PM, Alexandre DERUMIER wrote: >>> this adds a program that can listen to qemu qmp events on a given socket > > Does it work in parallel with sending qmp command ? > > As far I remember, some year ago, it was not possible to have 2 qmp clients > at > the same time. (and needed some kind of proxy betweens clients and qemu) > > Maybe more complex, but t could be great to be able to catch any events, > and use them in QemuServer.pm for example. > > yes you are right, my idea was to have a second qmp socket just for those events, and of course we could extend it to also react to other events (i have no idea what might be interesting besides the shutdown event) ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [RFC PATCH qemu-server] add qemumonitor.c
>>this adds a program that can listen to qemu qmp events on a given socket
Does it work in parallel with sending qmp command ?
As far I remember, some year ago, it was not possible to have 2 qmp clients at
the same time. (and needed some kind of proxy betweens clients and qemu)
Maybe more complex, but t could be great to be able to catch any events,
and use them in QemuServer.pm for example.
- Mail original -
De: "Dominik Csapak"
À: "pve-devel"
Envoyé: Mardi 9 Octobre 2018 14:49:22
Objet: [pve-devel] [RFC PATCH qemu-server] add qemumonitor.c
this adds a program that can listen to qemu qmp events on a given socket
and if a shutdown event followed by a disconnected socket occurs,
execute the given script with the given and additional arguments
this is useful if we want to cleanup after the qemu process exited,
e.g. tap devices, vgpus, etc.
also we could implement a 'proper' reboot with applying pending changes
and a stop/reboot hoook
for now, this needs a not-yet applied patch[1] to qemu
but this should be trivial to backport
1: https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg01271.html
Signed-off-by: Dominik Csapak
---
sending this as rfc, without makefile/manpage/inclusion in the package/use/
build-dependencies/etc.
location and name of it are ofc subject to change :)
i just want a general feedback of the code and the interface
i had imagined starting this tool after a qemu start
with a 'qm cleanup ID' tool to do the general cleanup
the program links against libjansson4, a ~75k library with only libc6 as
dependency, and the program uses about 100k RSS memory,
so i think this is an acceptable overhead
for a vm (with possibly multiple gbs of ram)
qemumonitor.c | 166 ++
1 file changed, 166 insertions(+)
create mode 100644 qemumonitor.c
diff --git a/qemumonitor.c b/qemumonitor.c
new file mode 100644
index 000..13dcfa2
--- /dev/null
+++ b/qemumonitor.c
@@ -0,0 +1,166 @@
+/*
+
+ Copyright (C) 2018 Proxmox Server Solutions GmbH
+
+ Copyright: qemumonitor is under GNU GPL, the GNU General Public License.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; version 2 dated June, 1991.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+ 02111-1307, USA.
+
+ Author: Dominik Csapak
+
+ qemumonitor connects to a given qmp socket, and waits for a
+ shutdown event followed by the closing of the socket,
+ it then calls the given script with following arguments
+
+ SCRIPT [ARGUMENTS]
+
+ parameter explanation:
+
+ graceful:
+ 1|0 depending if it saw a shutdown event before the socket closed
+
+ guest:
+ 1|0 depending if the shutdown was requested from the guest
+
+ was_reset:
+ 1|0 depending if the shutdown was actually a request
+
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+typedef enum { false, true } bool;
+typedef enum { STATE_PRECONNECTING, STATE_CONNECTING, STATE_CONNECTED }
state_t;
+
+#define QMP_ANSWER "{ \"execute\":\"qmp_capabilities\" }\n"
+
+void usage(char *name);
+
+void usage(char *name)
+{
+ fprintf(stderr, "Usage: %s SOCKET SCRIPT [ARGUMENTS..]\n", name);
+}
+
+int main(int argc, char *argv[])
+{
+ if (argc < 3) {
+ usage(argv[0]);
+ exit(EXIT_FAILURE);
+ }
+
+ ssize_t len;
+ bool graceful_shutdown = false;
+ bool guest_requested = false;
+ bool was_reset = false;
+
+ struct sockaddr_un serv_addr;
+ int sock;
+ FILE *socketfile;
+
+ sock = socket(AF_UNIX, SOCK_STREAM, 0);
+ if (sock == -1) {
+ fprintf(stderr, "cannot create unix socket: %s\n", strerror(errno));
+ exit(EXIT_FAILURE);
+ }
+
+ memset(&serv_addr, 0, sizeof(serv_addr));
+ serv_addr.sun_family = AF_UNIX;
+ memcpy(&(serv_addr.sun_path), argv[1], strlen(argv[1]));
+
+ if (connect(sock, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0) {
+ close(sock);
+ fprintf(stderr, "error connecting to %s: %s\n", argv[1], strerror(errno));
+ exit(EXIT_FAILURE);
+ }
+
+ socketfile = fdopen(sock, "r");
+ if (socketfile == NULL) {
+ fclose(socketfile);
+ fprintf(stderr, "error opening %s: %s\n", argv[1], strerror(errno));
+ exit(EXIT_FAILURE);
+ }
+
+ json_t *json;
+ json_error_t err;
+ bool guest;
+ bool reset;
+ const char *event;
+ state_t qmp_state = STATE_PRECONNECTING;
+
+ while (!feof(socketfile)) {
+ json = json_loadf(socketfile, JSON_DISABLE_EOF_CHECK, &err);
+ if (js
Re: [pve-devel] applied: [PATCH v4 pve-manager] API2 : Network : add network config reload
>>applied, and added a few cleanups on top. Thanks Dietmar ! >>Please can you try to solve those issues marked as 'clean me'? I'm not sure what is the best/cleanest way to read/write and parse /etc/network/interfaces ? - Mail original - De: "dietmar" À: "pve-devel" , "aderumier" Envoyé: Lundi 8 Octobre 2018 13:36:21 Objet: applied: [pve-devel] [PATCH v4 pve-manager] API2 : Network : add network config reload applied, and added a few cleanups on top. Please can you try to solve those issues marked as 'clean me'? > On October 2, 2018 at 9:19 AM Alexandre Derumier wrote: > > > This add a new api to online reload networking configuration > with ifupdown2. > > This work with native ifupdown2 modules, as ifupdown2 have > interface dependency relationships. > > Some specific interfaces options can't be reloaded online > (because kernel don't implement it), it this case, we ifdown/ifup > theses interfaces. (mainly vxlan interfaces options) > --- > changelog v4: > - parse running and new config to detect bridge removal && ovs change > instead using diff > - clean whitespaces errors > > changelog v3: > - catch errors on reloading, and try to ifdown/ifup interfaces > - if an interfaces really can't be reloaded, of ifdown/ifup, > revert current config of theses interfaces and keep interfaces.new file > > changelog v2: > > - remove restart option > - check if vm|ct are running on a bridge delete > - run the networking service reload in a task ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH qemu-server] qemu_img_convert : use "-l snapshot.name" instead -s for internal snapshot
qemu-img convert -s has been removed in qemu 3.0
https://git.qemu.org/?p=qemu.git;a=commit;h=46e8d272baa0608adcfdbd8bc1d2312bea06da40
we should use qemu-img convert -l snapshot.name=,
introduced in qemu 2.0 in 2013
http://patchwork.ozlabs.org/patch/296457/
---
PVE/QemuServer.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index fe27005..541d7b0 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -6286,7 +6286,7 @@ sub qemu_img_convert {
my $cmd = [];
push @$cmd, '/usr/bin/qemu-img', 'convert', '-p', '-n';
- push @$cmd, '-s', $snapname if($snapname && $src_format eq "qcow2");
+ push @$cmd, '-l', "snapshot.name=$snapname" if($snapname && $src_format
eq "qcow2");
push @$cmd, '-t', 'none' if $dst_scfg->{type} eq 'zfspool';
push @$cmd, '-T', 'none' if $src_scfg->{type} eq 'zfspool';
push @$cmd, '-f', $src_format, '-O', $dst_format, $src_path;
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v4 pve-manager] API2 : Network : add network config reload
This add a new api to online reload networking configuration
with ifupdown2.
This work with native ifupdown2 modules, as ifupdown2 have
interface dependency relationships.
Some specific interfaces options can't be reloaded online
(because kernel don't implement it), it this case, we ifdown/ifup
theses interfaces. (mainly vxlan interfaces options)
---
changelog v4:
- parse running and new config to detect bridge removal && ovs change
instead using diff
- clean whitespaces errors
changelog v3:
- catch errors on reloading, and try to ifdown/ifup interfaces
- if an interfaces really can't be reloaded, of ifdown/ifup,
revert current config of theses interfaces and keep interfaces.new file
changelog v2:
- remove restart option
- check if vm|ct are running on a bridge delete
- run the networking service reload in a task
PVE/API2/Network.pm | 152 +++-
1 file changed, 151 insertions(+), 1 deletion(-)
diff --git a/PVE/API2/Network.pm b/PVE/API2/Network.pm
index 92256863..69a6b158 100644
--- a/PVE/API2/Network.pm
+++ b/PVE/API2/Network.pm
@@ -4,7 +4,7 @@ use strict;
use warnings;
use Net::IP qw(:PROC);
-use PVE::Tools qw(extract_param);
+use PVE::Tools qw(extract_param dir_glob_regex);
use PVE::SafeSyslog;
use PVE::INotify;
use PVE::Exception qw(raise_param_exc);
@@ -471,6 +471,156 @@ __PACKAGE__->register_method({
}});
__PACKAGE__->register_method({
+name => 'reload_network_config',
+path => '',
+method => 'PUT',
+permissions => {
+ check => ['perm', '/nodes/{node}', [ 'Sys.Modify' ]],
+},
+description => "Reload network configuration",
+protected => 1,
+proxyto => 'node',
+parameters => {
+ additionalProperties => 0,
+ properties => {
+ node => get_standard_option('pve-node'),
+ },
+},
+returns => { type => 'string' },
+code => sub {
+
+ my ($param) = @_;
+
+my $rpcenv = PVE::RPCEnvironment::get();
+
+my $authuser = $rpcenv->get_user();
+
+ my $current_config_file = "/etc/network/interfaces";
+ my $new_config_file = "/etc/network/interfaces.new";
+
+ raise_param_exc({ config => "you need ifupdown2 to reload networking"
}) if !-e '/usr/share/ifupdown2';
+ raise_param_exc({ config => "no new network config to apply" }) if !-e
$new_config_file;
+
+ #clean-me
+ my $fh = IO::File->new("<$current_config_file");
+ my $running_config = PVE::INotify::read_etc_network_interfaces(1,$fh);
+ $fh->close();
+
+ #clean-me
+ $fh = IO::File->new("<$new_config_file");
+ my $new_config = PVE::INotify::read_etc_network_interfaces(1,$fh);
+ $fh->close();
+
+ my $ovs_changes = undef;
+ my $bridges_delete = {};
+ my $running_ifaces = $running_config->{ifaces};
+ my $new_ifaces = $new_config->{ifaces};
+
+ foreach my $iface (keys %$running_ifaces) {
+ my $running_iface = $running_ifaces->{$iface};
+ my $type = $running_iface->{type};
+ my $new_iface = $new_ifaces->{$iface};
+ my $new_type = $new_iface->{type};
+
+ $bridges_delete->{$iface} = 1 if !defined($new_iface) && $type eq
'bridge';
+ if ($type =~ m/^OVS/) {
+ #deleted ovs
+ $ovs_changes = 1 if !defined($new_iface);
+ #change ovs type to new type
+ $ovs_changes = 1 if $new_type ne $type;
+ #deleted or changed option
+ foreach my $iface_option (keys %$running_iface) {
+ if (!defined($new_iface->{$iface_option}) ||
($running_iface->{$iface_option} ne $new_iface->{$iface_option})) {
+ $ovs_changes = 1;
+ }
+ }
+ } else {
+ #change type to ovs
+ $ovs_changes = 1 if $new_type =~ m/^OVS/;
+ }
+ }
+
+ foreach my $iface (keys %$new_ifaces) {
+ my $new_iface = $new_ifaces->{$iface};
+ my $new_type = $new_iface->{type};
+ my $running_iface = $running_ifaces->{$iface};
+ my $type = $running_iface->{type};
+
+ if ($new_type =~ m/^OVS/) {
+ #new ovs
+ $ovs_changes = 1 if !defined($running_iface);
+ #new option
+ foreach my $iface_option (keys %$new_iface) {
+ if (!defined($running_iface->{$iface_option})) {
+ $ovs_changes = 1;
+ }
+ }
+ }
+ }
+
+ raise_param_exc({ config => "reloading config with ovs changes is not
possible currently\n" })
+ if $ovs_changes;
+
+ foreach my $bridge (keys %$bridges_delete) {
+
+ my (undef, $interface) =
dir_glob_regex("/sys/class/net/$bridge/brif", '(tap|veth|fwpr).*');
+ raise_param_exc({ config => "bridge deletion is not possible
currently if vm or ct are running on
[pve-devel] [PATCH V2 pve-common 2/2] improve lookup_type_prio
- use d->{type} instead regex on ifname
- add stacked vlan support
---
src/PVE/INotify.pm | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index 1a60708..c42f885 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -1506,39 +1506,40 @@ NETWORKDOC
my $if_type_hash = {
loopback => 10,
eth => 20,
+ OVSPort => 20,
+ OVSIntPort => 20,
bond => 30,
bridge => 40,
+ OVSBridge => 40,
vxlan => 50,
};
my $lookup_type_prio = sub {
- my $iface = shift;
-
+ my ($iface, $ifaces) = @_;
my $child = 0;
- if ($iface =~ m/^(\S+)(\.|:)\d+$/) {
- $iface = $1;
- $child = 1;
- }
+ my $n = undef;
- my $pri;
- if ($iface eq 'lo') {
- $pri = $if_type_hash->{loopback};
- } elsif ($iface =~ m/^$PVE::Network::PHYSICAL_NIC_RE$/) {
- $pri = $if_type_hash->{eth} + $child;
- } elsif ($iface =~ m/^bond\d+$/) {
- $pri = $if_type_hash->{bond} + $child;
- } elsif ($iface =~ m/^vmbr\d+$/) {
- $pri = $if_type_hash->{bridge} + $child;
+ my $i=1;
+ for my $childiface (split(/(\.|:)/, $iface)) {
+ if ($i > 1) {
+ $child++;
+ } else {
+ $n = $ifaces->{$childiface};
+ }
+ $i++;
}
+ my $pri = $if_type_hash->{$n->{type}} + $child
+ if $n->{type} && $n->{type} ne 'unknown';
+
return $pri;
};
foreach my $iface (sort {
my $ref1 = $ifaces->{$a};
my $ref2 = $ifaces->{$b};
- my $tp1 = &$lookup_type_prio($a);
- my $tp2 = &$lookup_type_prio($b);
+ my $tp1 = &$lookup_type_prio($a, $ifaces);
+ my $tp2 = &$lookup_type_prio($b, $ifaces);
# Only recognized types are in relation to each other. If one type
# is unknown then only consider the interfaces' priority attributes.
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH V2 pve-common 1/2] Inotify: add support for 802.1ad stacked vlans
---
src/PVE/INotify.pm | 11 +--
test/etc_network_interfaces/t.create_network.pl | 14 ++
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index f837596..1a60708 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -954,6 +954,7 @@ sub __read_etc_network_interfaces {
'bridge-multicast-flood' => 1,
'bond_miimon' => 1,
'bond_xmit_hash_policy' => 1,
+ 'vlan-protocol' => 1,
'vxlan-id' => 1,
'vxlan-svcnodeip' => 1,
'vxlan-physdev' => 1,
@@ -1201,6 +1202,10 @@ sub __interface_to_string {
$raw .= "\tbond-xmit-hash-policy $d->{'bond_xmit_hash_policy'}\n";
}
$done->{'bond_xmit_hash_policy'} = 1;
+} elsif ($d->{type} eq 'vlan') {
+ die "$iface: wrong vlan-protocol $d->{'vlan-protocol'}\n"
+ if $d->{'vlan-protocol'} && $d->{'vlan-protocol'} ne '802.1ad' &&
$d->{'vlan-protocol'} ne '802.1q';
+
} elsif ($d->{type} eq 'vxlan') {
foreach my $k (qw(vxlan-id vxlan-svcnodeip vxlan-physdev
vxlan-local-tunnelip)) {
@@ -1441,11 +1446,13 @@ sub __write_etc_network_interfaces {
if ($n->{type} eq 'bridge' && !$n->{bridge_vlan_aware}) {
die "vlan '$iface' - bridge vlan aware is not enabled on parent
'$p'\n";
- } elsif ($n->{type} ne 'eth' && $n->{type} ne 'bridge' &&
$n->{type} ne 'bond') {
+ } elsif ($n->{type} ne 'eth' && $n->{type} ne 'bridge' &&
$n->{type} ne 'bond' && $n->{type} ne 'vlan') {
die "vlan '$iface' - wrong interface type on parent '$p' " .
- "('$n->{type}' != 'eth|bond|bridge' )\n";
+ "('$n->{type}' != 'eth|bond|bridge|vlan' )\n";
}
+
&$check_mtu($ifaces, $p, $iface);
+
}
}
diff --git a/test/etc_network_interfaces/t.create_network.pl
b/test/etc_network_interfaces/t.create_network.pl
index e446f53..bf5b4b6 100644
--- a/test/etc_network_interfaces/t.create_network.pl
+++ b/test/etc_network_interfaces/t.create_network.pl
@@ -305,6 +305,15 @@ $config->{ifaces}->{'bond0.100'} = {
mtu => 1300,
method => 'manual',
families => ['inet'],
+'vlan-protocol' => '802.1ad',
+autostart => 1
+};
+
+$config->{ifaces}->{'bond0.100.10'} = {
+type => 'vlan',
+mtu => 1300,
+method => 'manual',
+families => ['inet'],
autostart => 1
};
@@ -336,6 +345,11 @@ $bond0_part
auto bond0.100
iface bond0.100 inet manual
mtu 1300
+ vlan-protocol 802.1ad
+
+auto bond0.100.10
+iface bond0.100.10 inet manual
+ mtu 1300
$vmbr0_part
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH V2 pve-common 0/2] Add support for 802.1ad stacked vlans
Changelog v2: - make it more generic, can stack any vlan type on any vlan type - check vlan-protocol values (802.1q|802.1ad) add support of vlan-protocol option (ifupdown2), to enable 802.1ad vlans (QinQ). and add support for stacked vlan interface example --- auto eth0.100 iface eth0.100 inet manual vlan-protocol 802.1ad auto eth0.100.10 iface eth0.100.10 inet manual Alexandre Derumier (2): Inotify: add support for 802.1ad stacked vlans improve lookup_type_prio src/PVE/INotify.pm | 48 ++--- test/etc_network_interfaces/t.create_network.pl | 14 2 files changed, 42 insertions(+), 20 deletions(-) -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-docs] firewall doc : remove wrong note
Documentation said that vm need to be restart after enable/disable firewall option on interface. This is wrong, the fwbr is added/removed online, and tap are unplug/plug to fwbr online too --- pve-firewall.adoc | 4 1 file changed, 4 deletions(-) diff --git a/pve-firewall.adoc b/pve-firewall.adoc index 1c94636..bc9df0e 100644 --- a/pve-firewall.adoc +++ b/pve-firewall.adoc @@ -201,10 +201,6 @@ Each virtual network device has its own firewall enable flag. So you can selectively enable the firewall for each interface. This is required in addition to the general firewall `enable` option. -The firewall requires a special network device setup, so you need to -restart the VM/container after enabling the firewall on a network -interface. - Firewall Rules -- -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-common 1/2] Inotify: add support for 802.1ad stacked vlans
>>It's also possible to stack 802.1Q on 802.1Q for example,
>>but I'm unaware of any real switch implementation.
>>AFAIK, only 1 802.1Q on top of 802.1ad seem to be possible on
>>cisco,juniper,arista,
sorry, I speak too fast, 1 user on the forum is currently playing with triple
tags and 802.1Q (with ovs) ;)
https://forum.proxmox.com/threads/1st-core-is-overloaded-by-intel-nic-irqs.47166/
I'll rework the patch, and make it more generic.
- Mail original -
De: "aderumier"
À: "Wolfgang Bumiller"
Cc: "pve-devel"
Envoyé: Mardi 25 Septembre 2018 15:34:50
Objet: Re: [pve-devel] [PATCH pve-common 1/2] Inotify: add support for 802.1ad
stacked vlans
>>While 802.1ad seems to be "specified" to be limited to 2 tags, it may
>>still be nice to just condense this into a single branch:
>>
>>if ($d->{type} eq 'vlan' && $iface =~ m/^(\S+(?:\.\d+)*)\.\d+$/) {
>>my $parent_name = $1;
>>my $parent = $ifaces->{$parent_name};
>>
>>And then add a 'vlan' type branch before the `not eth/bridge/bond`
>>branch in the old code?
>>(And then die if $parent_name contains 2 dots (=~ /\..*\./)).
Ok thanks, I'll rework it.
>>Btw. is this a restriction of ifupdown2? Or do we just want to do this
>>for safety? As from "technical" point of view nothing prevents me from
>>tripple-tagging. The kernel also happily allows me to add a range of
>>multiple 802.1Q tags without even using 802.1ad, or mix them.
>>eg.:
>># ip link add br0.5 link br0 type vlan id 5 protocol 802.1Q
>># ip link add br0.5.6 link br0.5 type vlan id 6 protocol 802.1ad
>># ip link add br0.5.6.7 link br0.5.6 type vlan id 7 protocol 802.1Q
>># ip link add br0.5.6.7.8 link br0.5.6.7 type vlan id 8 protocol 802.1ad
>>
>>tcpdump shows the expected data - I have no idea what it would do to
>>the usual switches out there in real networks though ;-)
yes, it was more by safety to avoid user misconfiguration of something not
working.
It's also possible to stack 802.1Q on 802.1Q for example,
but I'm unaware of any real switch implementation.
AFAIK, only 1 802.1Q on top of 802.1ad seem to be possible on
cisco,juniper,arista,
- Mail original -
De: "Wolfgang Bumiller"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Mardi 25 Septembre 2018 14:55:17
Objet: Re: [pve-devel] [PATCH pve-common 1/2] Inotify: add support for 802.1ad
stacked vlans
On Mon, Sep 24, 2018 at 09:52:46AM +0200, Alexandre Derumier wrote:
> ---
> src/PVE/INotify.pm | 26 -
> test/etc_network_interfaces/t.create_network.pl | 14 +
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
> index f837596..de61d79 100644
> --- a/src/PVE/INotify.pm
> +++ b/src/PVE/INotify.pm
> @@ -1432,7 +1433,25 @@ sub __write_etc_network_interfaces {
> # check vlan
> foreach my $iface (keys %$ifaces) {
> my $d = $ifaces->{$iface};
> - if ($d->{type} eq 'vlan' && $iface =~ m/^(\S+)\.\d+$/) {
> + if ($d->{type} eq 'vlan' && $iface =~ m/^(\S+\.\d+)\.\d+$/) {
While 802.1ad seems to be "specified" to be limited to 2 tags, it may
still be nice to just condense this into a single branch:
if ($d->{type} eq 'vlan' && $iface =~ m/^(\S+(?:\.\d+)*)\.\d+$/) {
my $parent_name = $1;
my $parent = $ifaces->{$parent_name};
And then add a 'vlan' type branch before the `not eth/bridge/bond`
branch in the old code?
(And then die if $parent_name contains 2 dots (=~ /\..*\./)).
> + my $p = $1;
> + my $n = $ifaces->{$p};
> +
> + die "vlan '$iface' - unable to find parent '$p'\n"
> + if !$n;
> +
> + die "stacked vlan '$iface' - parent '$p' is not a vlan interface "
> + if $n->{type} ne 'vlan';
> +
> + die "stacked vlan '$iface' - parent '$p' vlan-protocol is not 802.1ad"
> + if !$n->{'vlan-protocol'} || $n->{'vlan-protocol'} ne '802.1ad';
> +
> + die "stacked vlan '$iface' - vlan-protocol can't be 802.1ad"
> + if $d->{'vlan-protocol'} && $d->{'vlan-protocol'} eq '802.1ad';
Btw. is this a restriction of ifupdown2? Or do we just want to do this
for safety? As from "technical" point of view nothing prevents me from
tripple-tagging. The kernel also happily allows me to add a range of
multiple 802.1Q tags without even using 802.1ad, or mix them.
eg.:
# ip link add br0.5 li
Re: [pve-devel] [PATCH v3 pve-manager] API2 : Network : add network config reload
>>There is absolutely no guarantee that the diff contains the iface line if the
>>interface config contains more than 3 lines.
>>Instead, you need to read/parse both files. Then compare parsed data.
>>
>>> + } elsif ($line =~ m/ovs_type/) {
>>
>>same as above.
Ok, no problem, I'll take a little be more time to implement ;)
>>> + #if we still have error, recopy failed interface old config in current
>>> config
>>
>>not sure rollback is a good idea, because all other commands before
>>assumed the new configuration. Maybe this can result in an inconsistent
>>network config??
I don't rollback all config, only config of failed interfaces.
So it should be safe. (and ifdown/ifup shouldn't failed, until we have a syntax
config error, but previous reload should fail before)
- Mail original -
De: "dietmar"
À: "pve-devel" , "aderumier"
Envoyé: Mercredi 26 Septembre 2018 08:05:33
Objet: Re: [pve-devel] [PATCH v3 pve-manager] API2 : Network : add network
config reload
# git am yourpatch.eml
Applying: API2 : Network : add network config reload
.git/rebase-apply/patch:33: trailing whitespace.
name => 'reload_network_config',
.git/rebase-apply/patch:34: trailing whitespace.
path => '',
.git/rebase-apply/patch:43: space before tab in indent.
additionalProperties => 0,
.git/rebase-apply/patch:75: trailing whitespace.
}
.git/rebase-apply/patch:78: trailing whitespace.
raise_param_exc({ config => "reloading config with ovs changes is not possible
currently\n" })
warning: squelched 2 whitespace errors
warning: 7 lines add whitespace errors.
more comments inline
> On September 25, 2018 at 10:03 AM Alexandre Derumier
> wrote:
>
>
> This add a new api to online reload networking configuration
> with ifupdown2.
>
> This work with native ifupdown2 modules, as ifupdown2 have
> interface dependency relationships.
>
> Some specific interfaces options can't be reloaded online
> (because kernel don't implement it), it this case, we ifdown/ifup
> theses interfaces. (mainly vxlan interfaces options)
> ---
> changelog v3:
> - catch errors on reloading, and try to ifdown/ifup interfaces
> - if an interfaces really can't be reloaded, of ifdown/ifup,
> revert current config of theses interfaces and keep interfaces.new file
>
> changelog v2:
>
> - remove restart option
> - check if vm|ct are running on a bridge delete
> - run the networking service reload in a task
>
> PVE/API2/Network.pm | 114
> +++-
> 1 file changed, 113 insertions(+), 1 deletion(-)
>
> diff --git a/PVE/API2/Network.pm b/PVE/API2/Network.pm
> index 92256863..6d24ae24 100644
> --- a/PVE/API2/Network.pm
> +++ b/PVE/API2/Network.pm
> @@ -4,7 +4,7 @@ use strict;
> use warnings;
>
> use Net::IP qw(:PROC);
> -use PVE::Tools qw(extract_param);
> +use PVE::Tools qw(extract_param dir_glob_regex);
> use PVE::SafeSyslog;
> use PVE::INotify;
> use PVE::Exception qw(raise_param_exc);
> @@ -471,6 +471,118 @@ __PACKAGE__->register_method({
> }});
>
> __PACKAGE__->register_method({
> + name => 'reload_network_config',
> + path => '',
> + method => 'PUT',
> + permissions => {
> + check => ['perm', '/nodes/{node}', [ 'Sys.Modify' ]],
> + },
> + description => "Reload network configuration",
> + protected => 1,
> + proxyto => 'node',
> + parameters => {
> + additionalProperties => 0,
> + properties => {
> + node => get_standard_option('pve-node'),
> + },
> + },
> + returns => { type => 'string' },
> + code => sub {
> +
> + my ($param) = @_;
> +
> + my $rpcenv = PVE::RPCEnvironment::get();
> +
> + my $authuser = $rpcenv->get_user();
> +
> + my $current_config_file = "/etc/network/interfaces";
> + my $new_config_file = "/etc/network/interfaces.new";
> +
> + raise_param_exc({ config => "you need ifupdown2 to reload networking" }) if
> !-e '/usr/share/ifupdown2';
> + raise_param_exc({ config => "no new network config to apply" }) if !-e
> $new_config_file;
> +
> + my $tmp = PVE::INotify::read_file('interfaces', 1);
> + my $config = $tmp->{data};
> + my $changes = $tmp->{changes};
> +
> + my $ovs_changes = undef;
> + my $bridges_delete = {};
> + my @lines = split(/\n/, $changes);
> + foreach my $line (@lines) {
> + if($line =~ m/^\-iface\s(vmbr(\S+))/
Re: [pve-devel] [PATCH pve-common 1/2] Inotify: add support for 802.1ad stacked vlans
>>While 802.1ad seems to be "specified" to be limited to 2 tags, it may
>>still be nice to just condense this into a single branch:
>>
>>if ($d->{type} eq 'vlan' && $iface =~ m/^(\S+(?:\.\d+)*)\.\d+$/) {
>>my $parent_name = $1;
>>my $parent = $ifaces->{$parent_name};
>>
>>And then add a 'vlan' type branch before the `not eth/bridge/bond`
>>branch in the old code?
>>(And then die if $parent_name contains 2 dots (=~ /\..*\./)).
Ok thanks, I'll rework it.
>>Btw. is this a restriction of ifupdown2? Or do we just want to do this
>>for safety? As from "technical" point of view nothing prevents me from
>>tripple-tagging. The kernel also happily allows me to add a range of
>>multiple 802.1Q tags without even using 802.1ad, or mix them.
>>eg.:
>># ip link add br0.5 link br0 type vlan id 5 protocol 802.1Q
>># ip link add br0.5.6 link br0.5 type vlan id 6 protocol 802.1ad
>># ip link add br0.5.6.7 link br0.5.6 type vlan id 7 protocol 802.1Q
>># ip link add br0.5.6.7.8 link br0.5.6.7 type vlan id 8 protocol 802.1ad
>>
>>tcpdump shows the expected data - I have no idea what it would do to
>>the usual switches out there in real networks though ;-)
yes, it was more by safety to avoid user misconfiguration of something not
working.
It's also possible to stack 802.1Q on 802.1Q for example,
but I'm unaware of any real switch implementation.
AFAIK, only 1 802.1Q on top of 802.1ad seem to be possible on
cisco,juniper,arista,
- Mail original -
De: "Wolfgang Bumiller"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Mardi 25 Septembre 2018 14:55:17
Objet: Re: [pve-devel] [PATCH pve-common 1/2] Inotify: add support for 802.1ad
stacked vlans
On Mon, Sep 24, 2018 at 09:52:46AM +0200, Alexandre Derumier wrote:
> ---
> src/PVE/INotify.pm | 26 -
> test/etc_network_interfaces/t.create_network.pl | 14 +
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
> index f837596..de61d79 100644
> --- a/src/PVE/INotify.pm
> +++ b/src/PVE/INotify.pm
> @@ -1432,7 +1433,25 @@ sub __write_etc_network_interfaces {
> # check vlan
> foreach my $iface (keys %$ifaces) {
> my $d = $ifaces->{$iface};
> - if ($d->{type} eq 'vlan' && $iface =~ m/^(\S+)\.\d+$/) {
> + if ($d->{type} eq 'vlan' && $iface =~ m/^(\S+\.\d+)\.\d+$/) {
While 802.1ad seems to be "specified" to be limited to 2 tags, it may
still be nice to just condense this into a single branch:
if ($d->{type} eq 'vlan' && $iface =~ m/^(\S+(?:\.\d+)*)\.\d+$/) {
my $parent_name = $1;
my $parent = $ifaces->{$parent_name};
And then add a 'vlan' type branch before the `not eth/bridge/bond`
branch in the old code?
(And then die if $parent_name contains 2 dots (=~ /\..*\./)).
> + my $p = $1;
> + my $n = $ifaces->{$p};
> +
> + die "vlan '$iface' - unable to find parent '$p'\n"
> + if !$n;
> +
> + die "stacked vlan '$iface' - parent '$p' is not a vlan interface "
> + if $n->{type} ne 'vlan';
> +
> + die "stacked vlan '$iface' - parent '$p' vlan-protocol is not 802.1ad"
> + if !$n->{'vlan-protocol'} || $n->{'vlan-protocol'} ne '802.1ad';
> +
> + die "stacked vlan '$iface' - vlan-protocol can't be 802.1ad"
> + if $d->{'vlan-protocol'} && $d->{'vlan-protocol'} eq '802.1ad';
Btw. is this a restriction of ifupdown2? Or do we just want to do this
for safety? As from "technical" point of view nothing prevents me from
tripple-tagging. The kernel also happily allows me to add a range of
multiple 802.1Q tags without even using 802.1ad, or mix them.
eg.:
# ip link add br0.5 link br0 type vlan id 5 protocol 802.1Q
# ip link add br0.5.6 link br0.5 type vlan id 6 protocol 802.1ad
# ip link add br0.5.6.7 link br0.5.6 type vlan id 7 protocol 802.1Q
# ip link add br0.5.6.7.8 link br0.5.6.7 type vlan id 8 protocol 802.1ad
tcpdump shows the expected data - I have no idea what it would do to
the usual switches out there in real networks though ;-)
> +
> + &$check_mtu($ifaces, $p, $iface);
> +
> + } elsif ($d->{type} eq 'vlan' && $iface =~ m/^(\S+)\.\d+$/) {
> my $p = $1;
> my $n = $ifaces->{$p};
>
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH v3 pve-manager] API2 : Network : add network config reload
This add a new api to online reload networking configuration
with ifupdown2.
This work with native ifupdown2 modules, as ifupdown2 have
interface dependency relationships.
Some specific interfaces options can't be reloaded online
(because kernel don't implement it), it this case, we ifdown/ifup
theses interfaces. (mainly vxlan interfaces options)
---
changelog v3:
- catch errors on reloading, and try to ifdown/ifup interfaces
- if an interfaces really can't be reloaded, of ifdown/ifup,
revert current config of theses interfaces and keep interfaces.new file
changelog v2:
- remove restart option
- check if vm|ct are running on a bridge delete
- run the networking service reload in a task
PVE/API2/Network.pm | 114 +++-
1 file changed, 113 insertions(+), 1 deletion(-)
diff --git a/PVE/API2/Network.pm b/PVE/API2/Network.pm
index 92256863..6d24ae24 100644
--- a/PVE/API2/Network.pm
+++ b/PVE/API2/Network.pm
@@ -4,7 +4,7 @@ use strict;
use warnings;
use Net::IP qw(:PROC);
-use PVE::Tools qw(extract_param);
+use PVE::Tools qw(extract_param dir_glob_regex);
use PVE::SafeSyslog;
use PVE::INotify;
use PVE::Exception qw(raise_param_exc);
@@ -471,6 +471,118 @@ __PACKAGE__->register_method({
}});
__PACKAGE__->register_method({
+name => 'reload_network_config',
+path => '',
+method => 'PUT',
+permissions => {
+ check => ['perm', '/nodes/{node}', [ 'Sys.Modify' ]],
+},
+description => "Reload network configuration",
+protected => 1,
+proxyto => 'node',
+parameters => {
+ additionalProperties => 0,
+ properties => {
+ node => get_standard_option('pve-node'),
+ },
+},
+returns => { type => 'string' },
+code => sub {
+
+ my ($param) = @_;
+
+my $rpcenv = PVE::RPCEnvironment::get();
+
+my $authuser = $rpcenv->get_user();
+
+ my $current_config_file = "/etc/network/interfaces";
+ my $new_config_file = "/etc/network/interfaces.new";
+
+ raise_param_exc({ config => "you need ifupdown2 to reload networking"
}) if !-e '/usr/share/ifupdown2';
+ raise_param_exc({ config => "no new network config to apply" }) if !-e
$new_config_file;
+
+ my $tmp = PVE::INotify::read_file('interfaces', 1);
+ my $config = $tmp->{data};
+ my $changes = $tmp->{changes};
+
+ my $ovs_changes = undef;
+ my $bridges_delete = {};
+ my @lines = split(/\n/, $changes);
+ foreach my $line (@lines) {
+ if($line =~ m/^\-iface\s(vmbr(\S+))/) {
+ $bridges_delete->{$1} = 1;
+ } elsif ($line =~ m/ovs_type/) {
+ $ovs_changes = 1;
+ }
+ }
+
+ raise_param_exc({ config => "reloading config with ovs changes is not
possible currently\n" })
+ if $ovs_changes && !$param->{restart};
+
+ foreach my $bridge (keys %$bridges_delete) {
+
+ my (undef, $interface) =
dir_glob_regex("/sys/class/net/$bridge/brif", '(tap|veth|fwpr).*');
+ raise_param_exc({ config => "bridge deletion is not possible
currently if vm or ct are running on this bridge\n" })
+ if defined($interface);
+ }
+
+ my $worker = sub {
+
+ #clean-me
+ my $fh = IO::File->new("<$current_config_file");
+ my $running_config =
PVE::INotify::read_etc_network_interfaces(1,$fh);
+ $fh->close();
+
+ PVE::Tools::file_copy($new_config_file, $current_config_file);
+ my $new_config = PVE::INotify::read_file('interfaces');
+
+ my $cmd = ['ifreload', '-a'];
+ my $ifaces_errors = {};
+ my $ifaces_errors_final = {};
+
+ my $err = sub {
+ my $line = shift;
+ if ($line =~ /(warning|error): (\S+):/) {
+ $ifaces_errors->{$2} = 1;
+ print "$2 : error reloading configuration online : try to
ifdown/ifdown later : $line \n";
+ }
+ };
+
+ PVE::Tools::run_command($cmd,errfunc => $err);
+
+ my $err2 = sub {
+ my $line = shift;
+ if ($line =~ /(warning|error): (\S+):/) {
+ $ifaces_errors_final->{$2} = 1;
+ print "$2 : error restart: $line \n";
+ }
+ };
+
+ #try ifdown/up for non online change options
+ foreach my $iface (keys %$ifaces_errors) {
+ eval { PVE::Tools::run_command(['ifdown',$iface]) };
+ PVE::Tools::run_command(['ifup',$iface],errfunc => $err2);
+ }
+
+ #if we still have error, recopy failed interface old config in
current config
+ if(keys %$ifaces_errors_final > 0 ) {
+ foreach my $iface (keys %$ifaces_errors_final) {
+ print "error: $iface config has not been applied\n";
+ delete $new_config->{ifaces}->{$iface};
+ $new
Re: [pve-devel] [PATCH v2 pve-manager] API2 : Network : add network config reload
>>Any idea why json output is not supported?
seem to work with -o instead -t:
ifquery -a -o json
-o {native,json}, --format {native,json}
interface display format
-t seem to be for input format.
BTW,
it seem possible to compare running vs /etc/network/interfaces
ifquery --running -a
ifquery -a
- Mail original -
De: "dietmar"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Lundi 24 Septembre 2018 11:27:14
Objet: Re: [pve-devel] [PATCH v2 pve-manager] API2 : Network : add network
config reload
> I'm not sure if it's possible to try to reload directly
> /etc/network/interfaces.new, then if it's ok, overwrite
> /etc/network/interfaces. I'll look at this.
Thanks.
Unrelated topic, but I get the following with ifquery:
# ifquery -a -t json
error: No JSON object could be decoded
Any idea why json output is not supported?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH v2 pve-manager] API2 : Network : add network config reload
>>This looks fragile. Maybe we should first 'reload', and only rewrite if
>>reload is successful? Even better, a 'reload' should return the applied
>>configuration, and we only commit that?
It's possible to test the syntax of configuration with
"ifreload -a -s"
ifupdown2 reload should work for almost 99% of cases, only interface options
not able to be change online in kernel can give error. (mostly some vxlan
options from what I've seen).
maybe for theses known exceptions (we can catch them with ifreload -a, "error:
interface: "), then force ifdown/ifup interfaces theses interfaces?
I'm not sure if it's possible to try to reload directly
/etc/network/interfaces.new, then if it's ok, overwrite
/etc/network/interfaces. I'll look at this.
- Mail original -
De: "dietmar"
À: "pve-devel" , "aderumier"
Envoyé: Lundi 24 Septembre 2018 09:31:55
Objet: Re: [pve-devel] [PATCH v2 pve-manager] API2 : Network : add network
config reload
> + raise_param_exc({ config => "reloading config with ovs changes is not
> possible currently\n" })
> + if $ovs_changes && !$param->{restart};
> +
> + foreach my $bridge (keys %$bridges_delete) {
> +
> + my (undef, $interface) = dir_glob_regex("/sys/class/net/$bridge/brif",
> '(tap|veth|fwpr).*');
> + raise_param_exc({ config => "bridge deletion is not possible currently if
> vm or ct are running on this bridge\n" })
> + if defined($interface);
> + }
> +
> + PVE::Tools::file_copy($new_config_file, $current_config_file);
> + unlink $new_config_file;
> +
> + my $worker = sub {
> + PVE::Tools::run_command(['systemctl', 'reload', 'networking']);
> + };
> + return $rpcenv->fork_worker('srvreload', 'networking', $authuser, $worker);
> + }});
This looks fragile. Maybe we should first 'reload', and only rewrite if reload
is successful? Even better, a 'reload' should return the applied configuration,
and we only commit that?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-common 1/2] Inotify: add support for 802.1ad stacked vlans
---
src/PVE/INotify.pm | 26 -
test/etc_network_interfaces/t.create_network.pl | 14 +
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index f837596..de61d79 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -954,6 +954,7 @@ sub __read_etc_network_interfaces {
'bridge-multicast-flood' => 1,
'bond_miimon' => 1,
'bond_xmit_hash_policy' => 1,
+ 'vlan-protocol' => 1,
'vxlan-id' => 1,
'vxlan-svcnodeip' => 1,
'vxlan-physdev' => 1,
@@ -1432,7 +1433,25 @@ sub __write_etc_network_interfaces {
# check vlan
foreach my $iface (keys %$ifaces) {
my $d = $ifaces->{$iface};
- if ($d->{type} eq 'vlan' && $iface =~ m/^(\S+)\.\d+$/) {
+ if ($d->{type} eq 'vlan' && $iface =~ m/^(\S+\.\d+)\.\d+$/) {
+ my $p = $1;
+ my $n = $ifaces->{$p};
+
+ die "vlan '$iface' - unable to find parent '$p'\n"
+ if !$n;
+
+ die "stacked vlan '$iface' - parent '$p' is not a vlan interface "
+ if $n->{type} ne 'vlan';
+
+ die "stacked vlan '$iface' - parent '$p' vlan-protocol is not
802.1ad"
+ if !$n->{'vlan-protocol'} || $n->{'vlan-protocol'} ne '802.1ad';
+
+ die "stacked vlan '$iface' - vlan-protocol can't be 802.1ad"
+ if $d->{'vlan-protocol'} && $d->{'vlan-protocol'} eq '802.1ad';
+
+ &$check_mtu($ifaces, $p, $iface);
+
+ } elsif ($d->{type} eq 'vlan' && $iface =~ m/^(\S+)\.\d+$/) {
my $p = $1;
my $n = $ifaces->{$p};
@@ -1445,8 +1464,13 @@ sub __write_etc_network_interfaces {
die "vlan '$iface' - wrong interface type on parent '$p' " .
"('$n->{type}' != 'eth|bond|bridge' )\n";
}
+
+ die "bridge vlan '$iface' - vlan-protocol can't be 802.1ad"
+ if ($n->{'vlan-protocol'} && $n->{'vlan-protocol'} eq '802.1ad'
&& $n->{type} eq 'bridge');
+
&$check_mtu($ifaces, $p, $iface);
}
+
}
# check bridgeport option
diff --git a/test/etc_network_interfaces/t.create_network.pl
b/test/etc_network_interfaces/t.create_network.pl
index e446f53..bf5b4b6 100644
--- a/test/etc_network_interfaces/t.create_network.pl
+++ b/test/etc_network_interfaces/t.create_network.pl
@@ -305,6 +305,15 @@ $config->{ifaces}->{'bond0.100'} = {
mtu => 1300,
method => 'manual',
families => ['inet'],
+'vlan-protocol' => '802.1ad',
+autostart => 1
+};
+
+$config->{ifaces}->{'bond0.100.10'} = {
+type => 'vlan',
+mtu => 1300,
+method => 'manual',
+families => ['inet'],
autostart => 1
};
@@ -336,6 +345,11 @@ $bond0_part
auto bond0.100
iface bond0.100 inet manual
mtu 1300
+ vlan-protocol 802.1ad
+
+auto bond0.100.10
+iface bond0.100.10 inet manual
+ mtu 1300
$vmbr0_part
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-common 0/2] Add support for 802.1ad stacked vlans
add support of vlan-protocol option (ifupdown2), to enable 802.1ad vlans (QinQ). and add support for stacked vlan interface example --- auto eth0.100 iface eth0.100 inet manual vlan-protocol 802.1ad auto eth0.100.10 iface eth0.100.10 inet manual Alexandre Derumier (2): Inotify: add support for 802.1ad stacked vlans improve lookup_type_prio src/PVE/INotify.pm | 61 ++--- test/etc_network_interfaces/t.create_network.pl | 14 ++ 2 files changed, 58 insertions(+), 17 deletions(-) -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-common 2/2] improve lookup_type_prio
- use d->{type} instead regex on ifname
- add stacked vlan support
---
src/PVE/INotify.pm | 35 +++
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index de61d79..9d4f6d4 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -1523,30 +1523,33 @@ NETWORKDOC
my $if_type_hash = {
loopback => 10,
eth => 20,
+ OVSPort => 20,
+ OVSIntPort => 20,
bond => 30,
bridge => 40,
+ OVSBridge => 40,
vxlan => 50,
};
my $lookup_type_prio = sub {
- my $iface = shift;
-
+ my ($iface, $ifaces) = @_;
my $child = 0;
- if ($iface =~ m/^(\S+)(\.|:)\d+$/) {
- $iface = $1;
+ my $n = undef;
+
+ if ($iface =~ m/^(\S+)(\.\d+)(\.\d+)$/) {
+ my $p = $1;
+ $n = $ifaces->{$p};
+ $child = 1;
+ } elsif ($iface =~ m/^(\S+)(\.|:)\d+$/) {
+ my $p = $1;
+ $n = $ifaces->{$p};
$child = 1;
+ } else {
+ $n = $ifaces->{$iface};
}
- my $pri;
- if ($iface eq 'lo') {
- $pri = $if_type_hash->{loopback};
- } elsif ($iface =~ m/^$PVE::Network::PHYSICAL_NIC_RE$/) {
- $pri = $if_type_hash->{eth} + $child;
- } elsif ($iface =~ m/^bond\d+$/) {
- $pri = $if_type_hash->{bond} + $child;
- } elsif ($iface =~ m/^vmbr\d+$/) {
- $pri = $if_type_hash->{bridge} + $child;
- }
+ my $pri = $if_type_hash->{$n->{type}} + $child
+ if $n->{type} && $n->{type} ne 'unknown';
return $pri;
};
@@ -1554,8 +1557,8 @@ NETWORKDOC
foreach my $iface (sort {
my $ref1 = $ifaces->{$a};
my $ref2 = $ifaces->{$b};
- my $tp1 = &$lookup_type_prio($a);
- my $tp2 = &$lookup_type_prio($b);
+ my $tp1 = &$lookup_type_prio($a, $ifaces);
+ my $tp2 = &$lookup_type_prio($b, $ifaces);
# Only recognized types are in relation to each other. If one type
# is unknown then only consider the interfaces' priority attributes.
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH v2 pve-manager] API2 : Network : add network config reload
Hi,
seem to be lost in the mailing, can somebody review this V2 ?
- Mail original -
De: "aderumier"
À: "pve-devel"
Cc: "aderumier"
Envoyé: Mercredi 27 Juin 2018 04:53:57
Objet: [PATCH v2 pve-manager] API2 : Network : add network config reload
changelog:
- remove restart option
- check if vm|ct are running on a bridge delete
- run the networking service reload in a task
This add a new api to online reload networking configuration
with ifupdown2.
This work with native ifupdown2 modules, as ifupdown2 have
interface dependency relationships.
---
PVE/API2/Network.pm | 69 -
1 file changed, 68 insertions(+), 1 deletion(-)
diff --git a/PVE/API2/Network.pm b/PVE/API2/Network.pm
index c0ae1df3..9475396f 100644
--- a/PVE/API2/Network.pm
+++ b/PVE/API2/Network.pm
@@ -4,7 +4,7 @@ use strict;
use warnings;
use Net::IP qw(:PROC);
-use PVE::Tools qw(extract_param);
+use PVE::Tools qw(extract_param dir_glob_regex);
use PVE::SafeSyslog;
use PVE::INotify;
use PVE::Exception qw(raise_param_exc);
@@ -477,6 +477,73 @@ __PACKAGE__->register_method({
}});
__PACKAGE__->register_method({
+ name => 'reload_network_config',
+ path => '',
+ method => 'PUT',
+ permissions => {
+ check => ['perm', '/nodes/{node}', [ 'Sys.Modify' ]],
+ },
+ description => "Reload network configuration",
+ protected => 1,
+ proxyto => 'node',
+ parameters => {
+ additionalProperties => 0,
+ properties => {
+ node => get_standard_option('pve-node'),
+ },
+ },
+ returns => { type => 'string' },
+ code => sub {
+
+ my ($param) = @_;
+
+ my $rpcenv = PVE::RPCEnvironment::get();
+
+ my $authuser = $rpcenv->get_user();
+
+ my $current_config_file = "/etc/network/interfaces";
+ my $new_config_file = "/etc/network/interfaces.new";
+
+ raise_param_exc({ config => "you need ifupdown2 to reload networking" }) if
!-e '/usr/share/ifupdown2';
+ raise_param_exc({ config => "no new network config to apply" }) if !-e
$new_config_file;
+
+ my $tmp = PVE::INotify::read_file('interfaces', 1);
+ my $config = $tmp->{data};
+ my $changes = $tmp->{changes};
+
+ raise_param_exc({ config => "no changes detected" }) if !$changes;
+
+ my $ovs_changes = undef;
+ my $bridges_delete = {};
+ my @lines = split(/\n/, $changes);
+ foreach my $line (@lines) {
+ if($line =~ m/^\-iface\s(vmbr(\S+))/) {
+ $bridges_delete->{$1} = 1;
+ } elsif ($line =~ m/ovs_type/) {
+ $ovs_changes = 1;
+ }
+ }
+
+ raise_param_exc({ config => "reloading config with ovs changes is not
possible currently\n" })
+ if $ovs_changes && !$param->{restart};
+
+ foreach my $bridge (keys %$bridges_delete) {
+
+ my (undef, $interface) = dir_glob_regex("/sys/class/net/$bridge/brif",
'(tap|veth|fwpr).*');
+ raise_param_exc({ config => "bridge deletion is not possible currently if vm
or ct are running on this bridge\n" })
+ if defined($interface);
+ }
+
+ PVE::Tools::file_copy($new_config_file, $current_config_file);
+ unlink $new_config_file;
+
+ my $worker = sub {
+ PVE::Tools::run_command(['systemctl', 'reload', 'networking']);
+ };
+ return $rpcenv->fork_worker('srvreload', 'networking', $authuser, $worker);
+ }});
+
+__PACKAGE__->register_method({
name => 'delete_network',
path => '{iface}',
method => 'DELETE',
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH qemu-server] qemu 3.0 : add hv_synic && hv_stimer hyperv enlightment
>>Why 3.0 now? I thought 2.12 fixes this?
theses flags exists since a long time (qemu 2.5), I think we didn't enabled it
on proxmox4 because of missin kernel support.
but as you said me that you are working on qemu 3.0, it was for enabled them by
default for this machine.
>>And does this work for win 7 now actually? The previous series was for
>>win 8 and up.
yes, win2008r2/win7
need to find the official crosoft link, but here a blog about it.
http://bigdata-guide.blogspot.com/2014/01/microsoft-hyper-v-hypervisor.html
- Mail original -
De: "Wolfgang Bumiller"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Jeudi 13 Septembre 2018 11:13:41
Objet: Re: [pve-devel] [PATCH qemu-server] qemu 3.0 : add hv_synic && hv_stimer
hyperv enlightment
On Fri, Aug 31, 2018 at 03:43:01PM +0200, Alexandre Derumier wrote:
> This fix cpu bug on last win10 updates
> ---
> PVE/QemuServer.pm | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> index 9bfb4a1..52b0163 100644
> --- a/PVE/QemuServer.pm
> +++ b/PVE/QemuServer.pm
> @@ -6700,6 +6700,11 @@ sub add_hyperv_enlightenments {
>
> if ($winversion >= 7) {
> push @$cpuFlags , 'hv_relaxed';
> +
> + if (qemu_machine_feature_enabled ($machine_type, $kvmver, 3, 0)) {
Why 3.0 now? I thought 2.12 fixes this?
And does this work for win 7 now actually? The previous series was for
win 8 and up.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-docs v2 0/2] add docs about vlan mgmt with vlan aware bridge
Add some documentation about vlan management with bridge vlan aware. (tagging the vmbrX.Y) Alexandre Derumier (2): add vlanaware bridge management vlan configuration remove note about vlan management interface pve-network.adoc | 29 +++-- 1 file changed, 23 insertions(+), 6 deletions(-) -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-docs v2 1/2] add vlanaware bridge management vlan configuration
---
pve-network.adoc | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/pve-network.adoc b/pve-network.adoc
index 1ac5b28..f31362f 100644
--- a/pve-network.adoc
+++ b/pve-network.adoc
@@ -407,7 +407,7 @@ function of VLAN 5 in the guest network, but in combination
with VLAN anwareness
bridge this it will not work for guest network VLAN 5.
The downside of this setup is more CPU usage.
-.Example: Use VLAN 5 for the {pve} management IP
+.Example: Use VLAN 5 for the {pve} management IP with traditional Linux bridge
auto lo
iface lo inet loopback
@@ -432,11 +432,32 @@ iface vmbr0 inet manual
bridge_fd 0
+.Example: Use VLAN 5 for the {pve} management IP with VLAN aware Linux bridge
+
+auto lo
+iface lo inet loopback
+
+iface eno1 inet manual
+
+
+auto vmbr0.5
+iface vmbr0.5 inet static
+address 10.10.10.2
+netmask 255.255.255.0
+gateway 10.10.10.1
+
+auto vmbr0
+iface vmbr0 inet manual
+bridge_ports eno1
+bridge_stp off
+bridge_fd 0
+bridge_vlan_aware yes
+
The next example is the same setup but a bond is used to
make this network fail-safe.
-.Example: Use VLAN 5 with bond0 for the {pve} management IP
+.Example: Use VLAN 5 with bond0 for the {pve} management IP with traditional
Linux bridge
auto lo
iface lo inet loopback
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-docs v2 2/2] remove note about vlan management interface
This seem wrong,
it's possible to setup management vlan interface
on vlanaware bridge without conflict with vm.
(If vlan management is setup with vmbrX.Y)
---
pve-network.adoc | 4
1 file changed, 4 deletions(-)
diff --git a/pve-network.adoc b/pve-network.adoc
index f31362f..55e2fbf 100644
--- a/pve-network.adoc
+++ b/pve-network.adoc
@@ -402,10 +402,6 @@ abstraction layers between itself and the physical NIC.
For example, in a default configuration where you want to place
the host management address on a separate VLAN.
-NOTE: In the examples we use the VLAN at bridge level to ensure the correct
-function of VLAN 5 in the guest network, but in combination with VLAN
anwareness
-bridge this it will not work for guest network VLAN 5.
-The downside of this setup is more CPU usage.
.Example: Use VLAN 5 for the {pve} management IP with traditional Linux bridge
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-docs 1/2] add vlanaware bridge management vlan configuration
>>This example is exactly the same as the previous one. The only difference is
>>that you use bond0 instead of eno1? If so, I don't think it is worth to add.
yes, I was not sure if we need to show it.
I'll remove it and send a v2.
- Mail original -
De: "dietmar"
À: "pve-devel" , "aderumier"
Envoyé: Mardi 11 Septembre 2018 06:25:23
Objet: Re: [pve-devel] [PATCH pve-docs 1/2] add vlanaware bridge management
vlan configuration
comments/questions inline
> On September 10, 2018 at 5:31 PM Alexandre Derumier
> wrote:
>
>
> ---
> pve-network.adoc | 55 +--
> 1 file changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/pve-network.adoc b/pve-network.adoc
> index 1ac5b28..d61619f 100644
> --- a/pve-network.adoc
> +++ b/pve-network.adoc
> @@ -407,7 +407,7 @@ function of VLAN 5 in the guest network, but in
> combination with VLAN anwareness
> bridge this it will not work for guest network VLAN 5.
> The downside of this setup is more CPU usage.
>
> -.Example: Use VLAN 5 for the {pve} management IP
> +.Example: Use VLAN 5 for the {pve} management IP with traditional Linux
> bridge
>
> auto lo
> iface lo inet loopback
> @@ -432,11 +432,32 @@ iface vmbr0 inet manual
> bridge_fd 0
>
>
> +.Example: Use VLAN 5 for the {pve} management IP with VLAN aware Linux
> bridge
> +
> +auto lo
> +iface lo inet loopback
> +
> +iface eno1 inet manual
> +
> +
> +auto vmbr0.5
> +iface vmbr0.5 inet static
> + address 10.10.10.2
> + netmask 255.255.255.0
> + gateway 10.10.10.1
> +
> +auto vmbr0
> +iface vmbr0 inet manual
> + bridge_ports eno1
> + bridge_stp off
> + bridge_fd 0
> + bridge_vlan_aware yes
> +
looks good
>
> The next example is the same setup but a bond is used to
> make this network fail-safe.
>
> -.Example: Use VLAN 5 with bond0 for the {pve} management IP
> +.Example: Use VLAN 5 with bond0 for the {pve} management IP with traditional
> Linux bridge
>
> auto lo
> iface lo inet loopback
> @@ -471,6 +492,36 @@ iface vmbr0 inet manual
>
>
>
> +.Example: Use VLAN 5 with bond0 for the {pve} management IP with VLAN aware
> Linux bridge
> +
> +auto lo
> +iface lo inet loopback
> +
> +iface eno1 inet manual
> +
> +iface eno2 inet manual
> +
> +auto bond0
> +iface bond0 inet manual
> + slaves eno1 eno2
> + bond_miimon 100
> + bond_mode 802.3ad
> + bond_xmit_hash_policy layer2+3
> +
> +auto vmbr0.5
> +iface vmbr0.5 inet static
> + address 10.10.10.2
> + netmask 255.255.255.0
> + gateway 10.10.10.1
> +
> +auto vmbr0
> +iface vmbr0 inet manual
> + bridge_ports bond0
> + bridge_stp off
> + bridge_fd 0
> + bridge_vlan_aware yes
> +
This example is exactly the same as the previous one. The only difference is
that you use bond0 instead of eno1? If so, I don't think it is worth to add.
> +
>
> TODO: explain IPv6 support?
> TODO: explain OVS
> --
> 2.11.0
>
> ___
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-docs 0/2] add docs about vlan mgmt with vlan aware bridge
Add some documentation about vlan management with bridge vlan aware. (tagging the vmbrX.Y) Alexandre Derumier (2): add vlanaware bridge management vlan configuration remove note about vlan management interface pve-network.adoc | 59 ++-- 1 file changed, 53 insertions(+), 6 deletions(-) -- 2.11.0 ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-docs 2/2] remove note about vlan management interface
This seem wrong,
it's possible to setup management vlan interface
on vlanaware bridge without conflict with vm.
(If vlan management is setup with vmbrX.Y)
---
pve-network.adoc | 4
1 file changed, 4 deletions(-)
diff --git a/pve-network.adoc b/pve-network.adoc
index d61619f..10fe550 100644
--- a/pve-network.adoc
+++ b/pve-network.adoc
@@ -402,10 +402,6 @@ abstraction layers between itself and the physical NIC.
For example, in a default configuration where you want to place
the host management address on a separate VLAN.
-NOTE: In the examples we use the VLAN at bridge level to ensure the correct
-function of VLAN 5 in the guest network, but in combination with VLAN
anwareness
-bridge this it will not work for guest network VLAN 5.
-The downside of this setup is more CPU usage.
.Example: Use VLAN 5 for the {pve} management IP with traditional Linux bridge
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-docs 1/2] add vlanaware bridge management vlan configuration
---
pve-network.adoc | 55 +--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/pve-network.adoc b/pve-network.adoc
index 1ac5b28..d61619f 100644
--- a/pve-network.adoc
+++ b/pve-network.adoc
@@ -407,7 +407,7 @@ function of VLAN 5 in the guest network, but in combination
with VLAN anwareness
bridge this it will not work for guest network VLAN 5.
The downside of this setup is more CPU usage.
-.Example: Use VLAN 5 for the {pve} management IP
+.Example: Use VLAN 5 for the {pve} management IP with traditional Linux bridge
auto lo
iface lo inet loopback
@@ -432,11 +432,32 @@ iface vmbr0 inet manual
bridge_fd 0
+.Example: Use VLAN 5 for the {pve} management IP with VLAN aware Linux bridge
+
+auto lo
+iface lo inet loopback
+
+iface eno1 inet manual
+
+
+auto vmbr0.5
+iface vmbr0.5 inet static
+address 10.10.10.2
+netmask 255.255.255.0
+gateway 10.10.10.1
+
+auto vmbr0
+iface vmbr0 inet manual
+bridge_ports eno1
+bridge_stp off
+bridge_fd 0
+bridge_vlan_aware yes
+
The next example is the same setup but a bond is used to
make this network fail-safe.
-.Example: Use VLAN 5 with bond0 for the {pve} management IP
+.Example: Use VLAN 5 with bond0 for the {pve} management IP with traditional
Linux bridge
auto lo
iface lo inet loopback
@@ -471,6 +492,36 @@ iface vmbr0 inet manual
+.Example: Use VLAN 5 with bond0 for the {pve} management IP with VLAN aware
Linux bridge
+
+auto lo
+iface lo inet loopback
+
+iface eno1 inet manual
+
+iface eno2 inet manual
+
+auto bond0
+iface bond0 inet manual
+ slaves eno1 eno2
+ bond_miimon 100
+ bond_mode 802.3ad
+ bond_xmit_hash_policy layer2+3
+
+auto vmbr0.5
+iface vmbr0.5 inet static
+address 10.10.10.2
+netmask 255.255.255.0
+gateway 10.10.10.1
+
+auto vmbr0
+iface vmbr0 inet manual
+bridge_ports bond0
+bridge_stp off
+bridge_fd 0
+ bridge_vlan_aware yes
+
+
TODO: explain IPv6 support?
TODO: explain OVS
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-common V3] Inotify: fix mtu check
- special check for bond, set parent mtu from slaves mtu if no defined.
- error if parent mtu is lower than child mtu (not bigger)
- return if child mtu is not defined
- fix vlan check (parent/child was inverted)
---
changelog:
v2: bond with ifupdown2 is working like ifupdown
v3: cleanup code with wolfgang comments
src/PVE/INotify.pm | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index 4cf8699..f936a91 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -759,11 +759,16 @@ my $check_mtu = sub {
die "check mtu - missing parent interface\n" if !$parent;
die "check mtu - missing child interface\n" if !$child;
-my $pmtu = $ifaces->{$parent}->{mtu} ? $ifaces->{$parent}->{mtu} : 1500;
-my $cmtu = $ifaces->{$child}->{mtu} ? $ifaces->{$child}->{mtu} : 1500;
+my $cmtu = $ifaces->{$child}->{mtu};
+return if !$cmtu;
-die "interface '$parent' - mtu $pmtu is bigger than '$child' - mtu $cmtu\n"
- if $pmtu > $cmtu;
+my $parentdata = $ifaces->{$parent};
+my $pmtu = $parentdata->{mtu};
+$pmtu = $cmtu if $parentdata->{type} eq 'bond' && !$pmtu;
+$pmtu = 1500 if !$pmtu;
+
+die "interface '$parent' - mtu $pmtu is lower than '$child' - mtu $cmtu\n"
+ if $pmtu < $cmtu;
};
# config => {
@@ -1393,7 +1398,7 @@ sub __write_etc_network_interfaces {
die "vlan '$iface' - wrong interface type on parent '$p' " .
"('$n->{type}' != 'eth|bond|bridge' )\n";
}
- &$check_mtu($ifaces, $iface, $p);
+ &$check_mtu($ifaces, $p, $iface);
}
}
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-common V2] Inotify: fix mtu check
> changelog: bond with ifupdown2 is working like ifupdown
>>Please put patch changelogs after the '---' line
Ok, no problem
>>I'm really not a fan of the 'single-line postfix-if inside regular if
>>block' style.
>>Also, please use helper variables when accessing the same hash element
>>so many times.
Ok, will do for next time. thanks.
>>If no child mtu is set we can just return, as making it default to the
>>parent mtu has the same effect as all it does is make it pass the checks
>>successfully.
>>
>>Maybe the whole thing could look more like this?
>>my $cmtu = $ifaces->{$child}->{mtu};
>>return if !$cmtu;
>>
>>my $parentdata = $ifaces->{$parent};
>>my $pmtu = $parentdata->{mtu};
>>$pmtu = $cmtu if $parentdata->{type} eq 'bond' && !$pmtu;
>>$pmtu = 1500 if !$pmtu;
seem to be ok for me, I'll resent a v3.
Thanks !
- Mail original -
De: "Wolfgang Bumiller"
À: "aderumier"
Cc: "pve-devel"
Envoyé: Mardi 4 Septembre 2018 14:39:44
Objet: Re: [pve-devel] [PATCH pve-common V2] Inotify: fix mtu check
On Mon, Sep 03, 2018 at 03:52:41PM +0200, Alexandre Derumier wrote:
> changelog: bond with ifupdown2 is working like ifupdown
Please put patch changelogs after the '---' line
>
> - special check for bond, set parent mtu from slaves mtu if no defined.
>
> - error if parent mtu is lower than child mtu (not bigger)
>
> - child inherit from parent mtu if not defined
>
> - fix vlan check (parent/child was inverted)
> ---
> src/PVE/INotify.pm | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
> index 4cf8699..5d87261 100644
> --- a/src/PVE/INotify.pm
> +++ b/src/PVE/INotify.pm
> @@ -759,11 +759,15 @@ my $check_mtu = sub {
> die "check mtu - missing parent interface\n" if !$parent;
> die "check mtu - missing child interface\n" if !$child;
>
> + if($ifaces->{$parent}->{type} eq 'bond') {
> + $ifaces->{$parent}->{mtu} = $ifaces->{$child}->{mtu} if
> (!$ifaces->{$parent}->{mtu} && $ifaces->{$child}->{mtu});
> + }
I'm really not a fan of the 'single-line postfix-if inside regular if
block' style.
Also, please use helper variables when accessing the same hash element
so many times.
> +
> my $pmtu = $ifaces->{$parent}->{mtu} ? $ifaces->{$parent}->{mtu} : 1500;
> - my $cmtu = $ifaces->{$child}->{mtu} ? $ifaces->{$child}->{mtu} : 1500;
> + my $cmtu = $ifaces->{$child}->{mtu} ? $ifaces->{$child}->{mtu} : $pmtu;
If no child mtu is set we can just return, as making it default to the
parent mtu has the same effect as all it does is make it pass the checks
successfully.
Maybe the whole thing could look more like this?
my $cmtu = $ifaces->{$child}->{mtu};
return if !$cmtu;
my $parentdata = $ifaces->{$parent};
my $pmtu = $parentdata->{mtu};
$pmtu = $cmtu if $parentdata->{type} eq 'bond' && !$pmtu;
$pmtu = 1500 if !$pmtu;
... error cases here
>
> - die "interface '$parent' - mtu $pmtu is bigger than '$child' - mtu $cmtu\n"
> - if $pmtu > $cmtu;
> + die "interface '$parent' - mtu $pmtu is lower than '$child' - mtu $cmtu\n"
> + if $pmtu < $cmtu;
> };
>
> # config => {
> @@ -1393,7 +1397,7 @@ sub __write_etc_network_interfaces {
> die "vlan '$iface' - wrong interface type on parent '$p' " .
> "('$n->{type}' != 'eth|bond|bridge' )\n";
> }
> - &$check_mtu($ifaces, $iface, $p);
> + &$check_mtu($ifaces, $p, $iface);
> }
> }
>
> --
> 2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-docs V2] improve spectre/meltdown cpu flags documentation
-add new cpuflags for spectre v4.
-split cpuflags between amd && intel processors
---
qm.adoc | 104
1 file changed, 79 insertions(+), 25 deletions(-)
diff --git a/qm.adoc b/qm.adoc
index 1451f5d..718ecb6 100644
--- a/qm.adoc
+++ b/qm.adoc
@@ -307,56 +307,110 @@ theory this will give your guests maximum performance.
Meltdown / Spectre related CPU flags
-There are two CPU flags related to the Meltdown and Spectre vulnerabilities
+There are several CPU flags related to the Meltdown and Spectre vulnerabilities
footnote:[Meltdown Attack https://meltdownattack.com/] which need to be set
manually unless the selected CPU type of your VM already enables them by
default.
-The first, called 'pcid', helps to reduce the performance impact of the
Meltdown
-mitigation called 'Kernel Page-Table Isolation (KPTI)', which effectively hides
-the Kernel memory from the user space. Without PCID, KPTI is quite an expensive
-mechanism footnote:[PCID is now a critical performance/security feature on x86
-https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU].
-
-The second CPU flag is called 'spec-ctrl', which allows an operating system to
-selectively disable or restrict speculative execution in order to limit the
-ability of attackers to exploit the Spectre vulnerability.
-
-There are two requirements that need to be fulfilled in order to use these two
+There are two requirements that need to be fulfilled in order to use these
CPU flags:
* The host CPU(s) must support the feature and propagate it to the guest's
virtual CPU(s)
* The guest operating system must be updated to a version which mitigates the
attacks and is able to utilize the CPU feature
-In order to use 'spec-ctrl', your CPU or system vendor also needs to provide a
+Otherwise you need to set the desired CPU flag of the virtual CPU, either by
+editing the CPU options in the WebUI, or by setting the 'flags' property of the
+'cpu' option in the VM configuration file.
+
+For Spectre v1,v2,v4 fixes, your CPU or system vendor also needs to provide a
so-called ``microcode update'' footnote:[You can use `intel-microcode' /
`amd-microcode' from Debian non-free if your vendor does not provide such an
update. Note that not all affected CPUs can be updated to support spec-ctrl.]
for your CPU.
-To check if the {pve} host supports PCID, execute the following command as
root:
+
+To check if the {pve} host is vulnerable, execute the following command as
root:
-# grep ' pcid ' /proc/cpuinfo
+for f in /sys/devices/system/cpu/vulnerabilities/*; do echo "${f##*/} -" $(cat
"$f"); done
-If this does not return empty your host's CPU has support for 'pcid'.
+A community script is also avalaible to detect is the host is still vulnerable.
+footnote:[spectre-meltdown-checker https://meltdown.ovh/]
-To check if the {pve} host supports spec-ctrl, execute the following command
as root:
+Intel processors
+
+* 'pcid'
++
+This reduce the performance impact of the Meltdown (CVE-2017-5754) mitigation
+called 'Kernel Page-Table Isolation (KPTI)', which effectively hides
+the Kernel memory from the user space. Without PCID, KPTI is quite an expensive
+mechanism footnote:[PCID is now a critical performance/security feature on x86
+https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU].
++
+To check if the {pve} host supports PCID, execute the following command as
root:
++
-# grep ' spec_ctrl ' /proc/cpuinfo
+# grep ' pcid ' /proc/cpuinfo
++
+If this does not return empty your host's CPU has support for 'pcid'.
-If this does not return empty your host's CPU has support for 'spec-ctrl'.
+* 'spec-ctrl'
++
+Required to enable the Spectre v1 (CVE-2017-5753) and Spectre v2
(CVE-2017-5715) fix,
+in cases where retpolines are not sufficient.
+Included by default in Intel CPU models with -IBRS suffix.
+Must be explicitly turned on for Intel CPU models without -IBRS suffix.
+Requires the host CPU microcode (intel-microcode >= 20180425).
++
+* 'ssbd'
++
+Required to enable the Spectre V4 (CVE-2018-3639) fix. Not included by default
in any Intel CPU model.
+Must be explicitly turned on for all Intel CPU models.
+Requires the host CPU microcode(intel-microcode >= 20180703).
-If you use `host' or another CPU type which enables the desired flags by
-default, and you updated your guest OS to make use of the associated CPU
-features, you're already set.
-Otherwise you need to set the desired CPU flag of the virtual CPU, either by
-editing the CPU options in the WebUI, or by setting the 'flags' property of the
-'cpu' option in the VM configuration file.
+AMD processors
+^^
+
+* 'ibpb'
++
+Required to enable the Spectre v1 (CVE-2017-5753) and Spectre v2
(CVE-2017-5715) fix,
+in cases where retpolines are not sufficient.
+Included by default in AMD CPU models with -IBPB suf
Re: [pve-devel] [PATCH v3 pve-common 5/5] Inotify : add mtu option
>>Not sure if this is relevant here: An OVS bridge automatically adjusts
>>its MTU to the smallest MTU of all childs. This adjusting is done
>>whenever an interface/port is added or removed. Ie adding an interface
>>with small MTU automatically lowers the MTU of the OVS bridge.
Yes, this is the same with linux bridge.
Currently, when you add a vm or CT, proxmox set the same mtu on tap/veth
interfaces than the bridge.
>>Hence, it actually does not make sense to set the MTU of a OVS bridge,
>>as the next time an port is added/removed it will be recalculated.
you have the case where you have bigger mtu on physical interfaces, and lower
mtu on bridge.
auto eth0
iface eth0 inet manual
mtu 9000
auto vmbr0
iface vmbr0 inet manual
bridge_port eth0
mtu 1500
(1 usecase is with vxlan encapsulation, where you need bigger mtu to going out)
- Mail original -
De: "Klaus Darilion"
À: "pve-devel"
Envoyé: Lundi 3 Septembre 2018 15:47:06
Objet: Re: [pve-devel] [PATCH v3 pve-common 5/5] Inotify : add mtu option
Not sure if this is relevant here: An OVS bridge automatically adjusts
its MTU to the smallest MTU of all childs. This adjusting is done
whenever an interface/port is added or removed. Ie adding an interface
with small MTU automatically lowers the MTU of the OVS bridge.
Hence, it actually does not make sense to set the MTU of a OVS bridge,
as the next time an port is added/removed it will be recalculated.
Klaus
Am 28.08.2018 um 12:02 schrieb Dennis Busch:
> Hello Alexandre,
>
> this check is IMHO uneccessary as Debian inherites MTU from parent to
> child interfaces. That is AFAIK officially documente behavior, so this
> check makes it impossible to edit an interface that uses mtu definition
> only on parent devices.
>
> Best regards
>
> Dennis
>
> stacktrace GmbH
> Querstraße 3 | 96237 Ebersdorf
>
> Amtsgericht Coburg, HRB 5043
> Geschäftsführer: Dennis Busch | Jürgen Haas
>
> Tel: +49 9562 78 48 010
> Mobil: +49 171 12 62 761
> E-Mail: dennis.bu...@stacktrace.de
> De-Mail: dennis.bu...@gmx.de-mail.de
>
> Am 05.07.2018 um 02:56 schrieb Alexandre Derumier:
>> also check if mtu value is lower than parent interface
>>
>> fixme: vxlan interface should be 50bytes lower than outgoing interface
>> we need to find which interface is used (unicast/multicast/frr)
>> ---
>> src/PVE/INotify.pm | 22
>> ++
>> test/etc_network_interfaces/t.create_network.pl | 10 ++
>> 2 files changed, 32 insertions(+)
>>
>> diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
>> index f0f3144..5dd08c2 100644
>> --- a/src/PVE/INotify.pm
>> +++ b/src/PVE/INotify.pm
>> @@ -753,6 +753,20 @@ my $extract_ovs_option = sub {
>> return $v;
>> };
>> +my $check_mtu = sub {
>> + my ($ifaces, $parent, $child) = @_;
>> +
>> + die "check mtu : missing parent interface\n" if !$parent;
>> + die "check mtu : missing child interface\n" if !$child;
>> +
>> + my $pmtu = $ifaces->{$parent}->{mtu} ? $ifaces->{$parent}->{mtu} :
>> 1500;
>> + my $cmtu = $ifaces->{$child}->{mtu} ? $ifaces->{$child}->{mtu} :
>> 1500;
>> +
>> + die "interface '$parent' - mtu $pmtu is bigger than '$child' - mtu
>> $cmtu\n"
>> + if $pmtu gt $cmtu;
>> +
>> +};
>> +
>> # config => {
>> # ifaces => {
>> # $ifname => {
>> @@ -874,6 +888,7 @@ sub __read_etc_network_interfaces {
>> $id = $options_alternatives->{$id} if
>> $options_alternatives->{$id};
>> my $simple_options = {
>> + 'mtu' => 1,
>> 'ovs_type' => 1,
>> 'ovs_options' => 1,
>> 'ovs_bridge' => 1,
>> @@ -1301,6 +1316,8 @@ sub __write_etc_network_interfaces {
>> } else {
>> die "interface '$p' is not defined as OVS port/bond\n";
>> }
>> +
>> + &$check_mtu($ifaces, $iface, $p);
>> }
>> }
>> }
>> @@ -1315,6 +1332,7 @@ sub __write_etc_network_interfaces {
>> if !$n;
>> die "OVS bond '$iface' - wrong interface type on slave '$p' " .
>> "('$n->{type}' != 'eth')\n" if $n->{type} ne 'eth';
>> + &$check_mtu($ifaces, $iface, $p);
>> }
>> }
>> }
>> @@ -1330,6 +1348,7 @@ sub __write_etc_network_interfaces {
>> if !$n;
>> die "bond '$iface' - wrong interface type on slave '$p' " .
>> "('$n->{type
[pve-devel] [PATCH pve-common V2] Inotify: fix mtu check
changelog: bond with ifupdown2 is working like ifupdown
- special check for bond, set parent mtu from slaves mtu if no defined.
- error if parent mtu is lower than child mtu (not bigger)
- child inherit from parent mtu if not defined
- fix vlan check (parent/child was inverted)
---
src/PVE/INotify.pm | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index 4cf8699..5d87261 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -759,11 +759,15 @@ my $check_mtu = sub {
die "check mtu - missing parent interface\n" if !$parent;
die "check mtu - missing child interface\n" if !$child;
+if($ifaces->{$parent}->{type} eq 'bond') {
+ $ifaces->{$parent}->{mtu} = $ifaces->{$child}->{mtu} if
(!$ifaces->{$parent}->{mtu} && $ifaces->{$child}->{mtu});
+}
+
my $pmtu = $ifaces->{$parent}->{mtu} ? $ifaces->{$parent}->{mtu} : 1500;
-my $cmtu = $ifaces->{$child}->{mtu} ? $ifaces->{$child}->{mtu} : 1500;
+my $cmtu = $ifaces->{$child}->{mtu} ? $ifaces->{$child}->{mtu} : $pmtu;
-die "interface '$parent' - mtu $pmtu is bigger than '$child' - mtu $cmtu\n"
- if $pmtu > $cmtu;
+die "interface '$parent' - mtu $pmtu is lower than '$child' - mtu $cmtu\n"
+ if $pmtu < $cmtu;
};
# config => {
@@ -1393,7 +1397,7 @@ sub __write_etc_network_interfaces {
die "vlan '$iface' - wrong interface type on parent '$p' " .
"('$n->{type}' != 'eth|bond|bridge' )\n";
}
- &$check_mtu($ifaces, $iface, $p);
+ &$check_mtu($ifaces, $p, $iface);
}
}
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-common] Inotify: fix mtu check
- special check for bond, ifupdown set parent mtu from
slaves mtu if no defined.
- error if parent mtu is lower than child mtu (not bigger)
- child inherit from parent mtu if not defined
- fix vlan check (parent/child was inverted)
---
src/PVE/INotify.pm | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/PVE/INotify.pm b/src/PVE/INotify.pm
index 4cf8699..083fb70 100644
--- a/src/PVE/INotify.pm
+++ b/src/PVE/INotify.pm
@@ -754,16 +754,20 @@ my $extract_ovs_option = sub {
};
my $check_mtu = sub {
-my ($ifaces, $parent, $child) = @_;
+my ($ifaces, $parent, $child, $ifupdown2) = @_;
die "check mtu - missing parent interface\n" if !$parent;
die "check mtu - missing child interface\n" if !$child;
+if($ifaces->{$parent}->{type} eq 'bond') {
+ $ifaces->{$parent}->{mtu} = $ifaces->{$child}->{mtu} if
(!$ifaces->{$parent}->{mtu} && $ifaces->{$child}->{mtu} && !$ifupdown2);
+}
+
my $pmtu = $ifaces->{$parent}->{mtu} ? $ifaces->{$parent}->{mtu} : 1500;
-my $cmtu = $ifaces->{$child}->{mtu} ? $ifaces->{$child}->{mtu} : 1500;
+my $cmtu = $ifaces->{$child}->{mtu} ? $ifaces->{$child}->{mtu} : $pmtu;
-die "interface '$parent' - mtu $pmtu is bigger than '$child' - mtu $cmtu\n"
- if $pmtu > $cmtu;
+die "interface '$parent' - mtu $pmtu is lower than '$child' - mtu $cmtu\n"
+ if $pmtu < $cmtu;
};
# config => {
@@ -1347,7 +1351,7 @@ sub __write_etc_network_interfaces {
if !$n;
die "bond '$iface' - wrong interface type on slave '$p' " .
"('$n->{type}' != 'eth')\n" if $n->{type} ne 'eth';
- &$check_mtu($ifaces, $iface, $p);
+ &$check_mtu($ifaces, $iface, $p, $ifupdown2);
}
}
}
@@ -1393,7 +1397,7 @@ sub __write_etc_network_interfaces {
die "vlan '$iface' - wrong interface type on parent '$p' " .
"('$n->{type}' != 'eth|bond|bridge' )\n";
}
- &$check_mtu($ifaces, $iface, $p);
+ &$check_mtu($ifaces, $p, $iface);
}
}
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH v3 pve-common 5/5] Inotify : add mtu option
>>mmm,ok. I didn't known that's could work. >>So setting mtu to bond device, force mtu to slaves too ? Ok I have tried with iface bond0 inet manual slaves eth0 eth1 mtu 9000 with ifupdown , indeed, the slaves mtu are equal to bond mtu but with ifupdown2, the slave still have 1500 mtu. I'll make a bug report to ifupdown2, and improve my pve-common mtu patch. - Mail original - De: "aderumier" À: "Dennis Busch" Cc: "pve-devel" Envoyé: Lundi 3 Septembre 2018 13:14:33 Objet: Re: [pve-devel] [PATCH v3 pve-common 5/5] Inotify : add mtu option >>Just every configuration, where you change /etc/network/interfaces in a >>way like: >> >> >>iface bond0 inet manual >>... >>slaves eno18 eno19 >>mtu 9000 >> >> >>without also writing the "mtu 9000" in the eno18 and eno19 sections. It >>will work, but every try of changing network configuration via GUI will >>fail with an error message. mmm,ok. I didn't known that's could work. So setting mtu to bond device, force mtu to slaves too ? - Mail original - De: "Dennis Busch" À: "aderumier" , "pve-devel" Envoyé: Lundi 3 Septembre 2018 12:28:34 Objet: Re: [pve-devel] [PATCH v3 pve-common 5/5] Inotify : add mtu option > > Currently, I think that I'm using check_mtu only on child interfaces > (bond,vlan,bridgeport). > @Denis : do you have a sample config where it's not working ? > Just every configuration, where you change /etc/network/interfaces in a way like: iface bond0 inet manual ... slaves eno18 eno19 mtu 9000 without also writing the "mtu 9000" in the eno18 and eno19 sections. It will work, but every try of changing network configuration via GUI will fail with an error message. ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH v3 pve-common 5/5] Inotify : add mtu option
>>Just every configuration, where you change /etc/network/interfaces in a >>way like: >> >> >>iface bond0 inet manual >>... >>slaves eno18 eno19 >>mtu 9000 >> >> >>without also writing the "mtu 9000" in the eno18 and eno19 sections. It >>will work, but every try of changing network configuration via GUI will >>fail with an error message. mmm,ok. I didn't known that's could work. So setting mtu to bond device, force mtu to slaves too ? - Mail original - De: "Dennis Busch" À: "aderumier" , "pve-devel" Envoyé: Lundi 3 Septembre 2018 12:28:34 Objet: Re: [pve-devel] [PATCH v3 pve-common 5/5] Inotify : add mtu option > > Currently, I think that I'm using check_mtu only on child interfaces > (bond,vlan,bridgeport). > @Denis : do you have a sample config where it's not working ? > Just every configuration, where you change /etc/network/interfaces in a way like: iface bond0 inet manual ... slaves eno18 eno19 mtu 9000 without also writing the "mtu 9000" in the eno18 and eno19 sections. It will work, but every try of changing network configuration via GUI will fail with an error message. ___ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH pve-manager] add 'ssbd', 'ibpb', 'virt-ssbd', 'amd-ssbd', 'amd-no-ssb' cpu flags option
>>I think we need another way to show this...
>>Having it like this is very confusing, IMO, and there will probably come
>>more.
yes, I was thinking the same. Waiting for spectre v100 ;)
>>Maybe a grid with checkboxes, a flag name column and a description column
>>where we can put at least a minimal description about what this is?
>>A combobox (with same grid and multiselect) could be done too, would need
>>less
>>space, so maybe even better.
yes, indeed, could be great :)
also, some flag are for amd and other for intel, it could be great to be able
to filter
list from the cpu model.
- Mail original -
De: "Thomas Lamprecht"
À: "pve-devel" , "aderumier"
Envoyé: Lundi 3 Septembre 2018 08:41:43
Objet: Re: [pve-devel] [PATCH pve-manager] add 'ssbd', 'ibpb', 'virt-ssbd',
'amd-ssbd', 'amd-no-ssb' cpu flags option
On 9/2/18 7:54 AM, Alexandre Derumier wrote:
> ---
> www/manager6/qemu/ProcessorEdit.js | 42
> +-
> 1 file changed, 37 insertions(+), 5 deletions(-)
>
> diff --git a/www/manager6/qemu/ProcessorEdit.js
> b/www/manager6/qemu/ProcessorEdit.js
> index 3ecea205..eaec0773 100644
> --- a/www/manager6/qemu/ProcessorEdit.js
> +++ b/www/manager6/qemu/ProcessorEdit.js
> @@ -44,7 +44,7 @@ Ext.define('PVE.qemu.ProcessorInputPanel', {
>
> var flags = [];
>
> - ['pcid', 'spec-ctrl'].forEach(function(flag) {
> + ['pcid', 'spec-ctrl', 'ssbd', 'ibpb', 'virt-ssbd', 'amd-ssbd',
> 'amd-no-ssb'].forEach(function(flag) {
> if (values[flag]) {
> flags.push('+' + flag.toString());
> }
> @@ -150,7 +150,26 @@ Ext.define('PVE.qemu.ProcessorInputPanel', {
> value: '1024',
> deleteEmpty: true,
> allowBlank: true
> + },
> + {
> + xtype: 'proxmoxcheckbox',
> + fieldLabel: 'PCID',
> + name: 'pcid',
> + uncheckedValue: 0
> + },
> + {
> + xtype: 'proxmoxcheckbox',
> + fieldLabel: 'SPEC-CTRL',
> + name: 'spec-ctrl',
> + uncheckedValue: 0
> + },
> + {
> + xtype: 'proxmoxcheckbox',
> + fieldLabel: 'SSBD',
> + name: 'ssbd',
> + uncheckedValue: 0
> }
> +
> ],
>
> advancedColumn2: [
> @@ -162,16 +181,29 @@ Ext.define('PVE.qemu.ProcessorInputPanel', {
> },
> {
> xtype: 'proxmoxcheckbox',
> - fieldLabel: 'PCID',
> - name: 'pcid',
> + fieldLabel: 'IBPB',
> + name: 'ibpb',
> uncheckedValue: 0
> },
> {
> xtype: 'proxmoxcheckbox',
> - fieldLabel: 'SPEC-CTRL',
> - name: 'spec-ctrl',
> + fieldLabel: 'VIRT-SSBD',
> + name: 'virt-ssbd',
> + uncheckedValue: 0
> + },
> + {
> + xtype: 'proxmoxcheckbox',
> + fieldLabel: 'AMD-SSBD',
> + name: 'amd-ssbd',
> + uncheckedValue: 0
> + },
> + {
> + xtype: 'proxmoxcheckbox',
> + fieldLabel: 'AMD-NO-SSB',
> + name: 'amd-no-ssb',
> uncheckedValue: 0
> }
> +
> ]
> });
>
I think we need another way to show this...
Having it like this is very confusing, IMO, and there will probably come more.
Maybe a grid with checkboxes, a flag name column and a description column
where we can put at least a minimal description about what this is?
A combobox (with same grid and multiselect) could be done too, would need less
space, so maybe even better.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] [PATCH pve-manager] add 'ssbd', 'ibpb', 'virt-ssbd', 'amd-ssbd', 'amd-no-ssb' cpu flags option
---
www/manager6/qemu/ProcessorEdit.js | 42 +-
1 file changed, 37 insertions(+), 5 deletions(-)
diff --git a/www/manager6/qemu/ProcessorEdit.js
b/www/manager6/qemu/ProcessorEdit.js
index 3ecea205..eaec0773 100644
--- a/www/manager6/qemu/ProcessorEdit.js
+++ b/www/manager6/qemu/ProcessorEdit.js
@@ -44,7 +44,7 @@ Ext.define('PVE.qemu.ProcessorInputPanel', {
var flags = [];
- ['pcid', 'spec-ctrl'].forEach(function(flag) {
+ ['pcid', 'spec-ctrl', 'ssbd', 'ibpb', 'virt-ssbd', 'amd-ssbd',
'amd-no-ssb'].forEach(function(flag) {
if (values[flag]) {
flags.push('+' + flag.toString());
}
@@ -150,7 +150,26 @@ Ext.define('PVE.qemu.ProcessorInputPanel', {
value: '1024',
deleteEmpty: true,
allowBlank: true
+ },
+ {
+ xtype: 'proxmoxcheckbox',
+ fieldLabel: 'PCID',
+ name: 'pcid',
+ uncheckedValue: 0
+ },
+ {
+ xtype: 'proxmoxcheckbox',
+ fieldLabel: 'SPEC-CTRL',
+ name: 'spec-ctrl',
+ uncheckedValue: 0
+ },
+ {
+ xtype: 'proxmoxcheckbox',
+ fieldLabel: 'SSBD',
+ name: 'ssbd',
+ uncheckedValue: 0
}
+
],
advancedColumn2: [
@@ -162,16 +181,29 @@ Ext.define('PVE.qemu.ProcessorInputPanel', {
},
{
xtype: 'proxmoxcheckbox',
- fieldLabel: 'PCID',
- name: 'pcid',
+ fieldLabel: 'IBPB',
+ name: 'ibpb',
uncheckedValue: 0
},
{
xtype: 'proxmoxcheckbox',
- fieldLabel: 'SPEC-CTRL',
- name: 'spec-ctrl',
+ fieldLabel: 'VIRT-SSBD',
+ name: 'virt-ssbd',
+ uncheckedValue: 0
+ },
+ {
+ xtype: 'proxmoxcheckbox',
+ fieldLabel: 'AMD-SSBD',
+ name: 'amd-ssbd',
+ uncheckedValue: 0
+ },
+ {
+ xtype: 'proxmoxcheckbox',
+ fieldLabel: 'AMD-NO-SSB',
+ name: 'amd-no-ssb',
uncheckedValue: 0
}
+
]
});
--
2.11.0
___
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
