Hi all,
Any idea why this option '-boot menu=on' makes a VM unbootable in
nested virtualization under qemu-2.4?
Anyway to debug what goes on?
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG keys:
michael rasmussen cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir d
Hi,
here a deb source package for iproute2 4.1
http://odisoweb1.odiso.net/iproute2.tar.gz
I haved added the buffer increase patch to handle all the vlans in "bridge" and
"ip" commands.
Alexandre
___
pve-devel mailing list
pve-devel@pve.proxmox.com
On Tue, Aug 04, 2015 at 04:43:48PM +0200, Alexandre DERUMIER wrote:
> +return 0 if $exclude_cloudinit && $drive->{file} =~
> m@[:/]vm-\d+-cloudinit\.$QEMU_FORMAT_RE@;
>
> I think this will not match disks on block storage ?
>
> file sample : 100/vm-100-cloudinit.raw
> block sample : vm-100
BTW, can you test this method too ?
>>eth0.10>vmbrcustomer<--(vlanX)--tapX
>>
>>
>>
>>auto vmbrcustomer1
>>iface vmbrcustomer1 inet manual
>>bridge_vlan_aware yes
>>bridge_ports eth0.10
>>bridge_stp off
>>bridge_fd 0
>>pre-up ip link add link eth0
>>Something to be aware of, QinQ does not always have an outer tag with
>>ethertype 0x88a8, it can also have a tag of 0x8100 or 0x9100 depending on the
>>implementation.
ah ok, dindn't known that
echo 0x8100 > /sys/class/net/vmbr1/bridge/vlan_protocol
echo 0x88a8 > /sys/class/net/vmbr1/bridge/vl
>>Am I right in thinking that for 4x bridges each with a different SVID
>>(101,102,103,104) that the config would look like this ?
Yes, I think it should work.
I'm not just that all pre-up,post-up will be run in correct order, but that's
the idea.
- Mail original -
De: "Andrew Thrift"
Alexandre,
Am I right in thinking that for 4x bridges each with a different SVID
(101,102,103,104) that the config would look like this ?
auto vmbrcustomer1
iface vmbrcustomer1 inet manual
bridge_vlan_aware yes
bridge_ports customer1lp
bridge_stp off
bridge_fd 0
Hi Alexandre,
This looks like it should work.
Something to be aware of, QinQ does not always have an outer tag with
ethertype 0x88a8, it can also have a tag of 0x8100 or 0x9100 depending on
the implementation.
For example:
0x88a8--0x8100Outer-tag (SVID) of 0x88a8, Inner-tag (CVID) of 0x8100
On Tue, 4 Aug 2015 21:20:07 +0200
Kamil Trzciński wrote:
> Did you try to remove:
>
> -boot menu=on,strict=on,reboot-timeout=1000
>
> For me it fixes the problem with qemu 2.4.
>
You are right;-) But it is enough to remove menu=on. However, this has
the bad side effect that you are not shown a
Did you try to remove:
-boot menu=on,strict=on,reboot-timeout=1000
For me it fixes the problem with qemu 2.4.
On Tue, Aug 4, 2015 at 7:14 PM, Michael Rasmussen wrote:
>
> But can you start a kvm guest from the guest with kvm enabled?
--
Kamil Trzciński
ayu...@ayufan.eu
www.ayufan.eu
_
> -#my $cmd = ['/sbin/lvextend', '-L', $size, $path];
> -#run_command($cmd, errmsg => "error resizing volume '$path'");
> +# FIXME if there's ever more than one volume in a resource
>
> not sure if we ever want to support multiple volumes inside one
> resource?
> Why would we want to d
On Tue, 04 Aug 2015 18:50:12 +0200
Emmanuel Kasper wrote:
>
> guest (pve v4.0 VM, with cpu type set to host)
> grep --quiet vmx /proc/cpuinfo && echo found
> found
>
> uname -srm
> Linux 4.1.3-1-pve x86_64
>
> kvm --version
> QEMU emulator version 2.3.93, Copyright (c) 2003-2008 Fabrice Bellar
Dear,
Please add the following patch into the 4.1.3 kernel releases for proxmox
4.0.
This is needed to split up / break up some (multi)devices iommu groups.
Using this myself to split up my rocketU USB3.0 cards USB controllers into
different iommu groups so that vfio can passthrough each cont
On 08/04/2015 04:35 PM, Alexandre DERUMIER wrote:
>>> Maybe qemu-2.4 has introduced something which makes it incompatible with
>>> previous versions of qemu?
>
> Yes, maybe.
>
> do you have tried qemu 2.4 on top of 2.4 ?
>
I tried nested KVM virtualization with qemu 2.4, and "it works here"
Begin forwarded message:
Date: Tue, 4 Aug 2015 17:59:57 +0200
From: Michael Rasmussen
To: Alexandre DERUMIER
Subject: Re: [pve-devel] updated PVE 4.0 packages on pvetest
On Tue, 4 Aug 2015 16:35:45 +0200 (CEST)
Alexandre DERUMIER wrote:
>
> do you have tried qemu 2.4 on top of 2.4 ?
>
No
keep them for now
> On August 4, 2015 at 2:20 PM Emmanuel Kasper wrote:
>
>
> Hi
> I see we still have references to the java applet in Utils.js and
> VNConsole.js
> Should we keep them or do we want to remove them ?
> Emmanuel
>
> ___
> pve-devel m
+return 0 if $exclude_cloudinit && $drive->{file} =~
m@[:/]vm-\d+-cloudinit\.$QEMU_FORMAT_RE@;
I think this will not match disks on block storage ?
file sample : 100/vm-100-cloudinit.raw
block sample : vm-100-cloudinit
- Mail original -
De: "Wolfgang Bumiller"
À: "pve-devel
>>Maybe qemu-2.4 has introduced something which makes it incompatible with
>>previous versions of qemu?
Yes, maybe.
do you have tried qemu 2.4 on top of 2.4 ?
- Mail original -
De: "datanom.net"
À: "pve-devel"
Envoyé: Mardi 4 Août 2015 16:33:56
Objet: Re: [pve-devel] updated PVE 4.0
On Mon, 3 Aug 2015 12:54:10 +0200
Michael Rasmussen wrote:
> To summe it all up:
> qemu-2.3 can run nested over qemu-2.2
> qemu-2.4 cannot run nested over qemu-2.2
>
I have made further tests. It seems qemu-2.4 cannot run nested over
qemu-2.3 as well. Maybe qemu-2.4 has introduced something whic
Updated debian package control files and Makefile to build gfs2-3.1.8
for Proxmox VE 3.4.
We use the following gfs2-utils sources for this build:
gfs2-utils.git: 3.1.8 tag
Signed-off-by: Thomas Lamprecht
---
Makefile |6 +++---
debian/changelog |6 ++
debian/control |2
Updating the gfs2-utils to the latest stable upstream version
for PVE 3.4. Targets the stable-3 branch from gfs2-utils
GFS2 sources used:
https://git.fedorahosted.org/cgit/gfs2-utils.git/snapshot/gfs2-utils-3.1.8.tar.gz
Thomas Lamprecht (2):
gfs2-utils: update package control files for updated
Removed old, for the actual gfs2 version (3.1.8), unnecessary patch.
Do not throw an error when no GFS2 entry is in /etc/fstab, because
there cannot possible be an entry after the first installation and it's
very confusing to get an error at this point. A info message should be
enough. Using gfs2-u
---
PVE/API2/Qemu.pm | 2 +-
PVE/QemuServer.pm | 14 +-
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
index 82a8e15..38eefb4 100644
--- a/PVE/API2/Qemu.pm
+++ b/PVE/API2/Qemu.pm
@@ -41,7 +41,7 @@ my $resolve_cdrom_alias = sub {
m
To be applied to the v8 series.
I gave drive_is_cdrom a flag for whether to treat cloudinit images as
cdrom drive (which it now does by default), in order to easily be able
to exclude it in places where it makes sense. $test_deallocate_storage
for instance now doesn't treat cloudinit images as cdr
This seem to work.
(I'm not sure about tcpdump result when vlan are stacked)
auto vmbrcustomer1
iface vmbrcustomer1 inet manual
bridge_vlan_aware yes
bridge_ports customer1lp
bridge_stp off
bridge_fd 0
pre-up ip link add dev customer1l type veth peer name c
Hi
I see we still have references to the java applet in Utils.js and
VNConsole.js
Should we keep them or do we want to remove them ?
Emmanuel
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Another way,
but I'm not sure it's working, is to tag 802.1ad on the physical interface
eth0.10>vmbrcustomer<--(vlanX)--tapX
auto vmbrcustomer1
iface vmbrcustomer1 inet manual
bridge_vlan_aware yes
bridge_ports eth0.10
bridge_stp off
bridge_fd 0
On Tue, Aug 04, 2015 at 12:24:06PM +0200, Alexandre DERUMIER wrote:
> >>Regarding the error when the image already exists: In Qemu.pm only disks
> >>that were previously marked as unused get deleted
> >>($test_deallocate_drive), also this function ignores cdrom drives.
> >>Maybe a media=cloudini
>>Regarding the error when the image already exists: In Qemu.pm only disks
>>that were previously marked as unused get deleted
>>($test_deallocate_drive), also this function ignores cdrom drives.
>>Maybe a media=cloudinit would be useful after all?
>>On one side it would give us an easy conditi
>>Hi Alexandre,
Hi,
>>We also use QinQ and have submitted patches for the previous network
>>implementation that made use of a "bridge in bridge" design to achieve the
>>QinQ functionality.
They are also a new way to implement q-in-q with vlan aware bridge
http://www.spinics.net/lists/linux-
applied and uploaded to pvetest.
Thanks for the fix.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Signed-off-by: Alen Grizonic
---
src/PVE/Firewall.pm | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/PVE/Firewall.pm b/src/PVE/Firewall.pm
index 1286238..83915df 100644
--- a/src/PVE/Firewall.pm
+++ b/src/PVE/Firewall.pm
@@ -1197,7 +1197,9 @@ my $apply_macro = sub {
> > > -my $path = $class->path($scfg, $volname);
> > > +die "illegal name '$name' - should be 'vm-*-*'\n"
> > > + if $name !~ m/^vm-\d+-/;
> > >
> > > And reason for above check? Or did you just copied that code from
> > > alloc_image?
> > Right. And that's why I changed the name - to keep
Hi Alexandre,
We also use QinQ and have submitted patches for the previous network
implementation that made use of a "bridge in bridge" design to achieve the
QinQ functionality.
The new vlan aware bridge implementation will be a lot cleaner.
When your patches are ready we will test them and prov
> > -my $path = $class->path($scfg, $volname);
> > +die "illegal name '$name' - should be 'vm-*-*'\n"
> > + if $name !~ m/^vm-\d+-/;
> >
> > And reason for above check? Or did you just copied that code from
> > alloc_image?
> Right. And that's why I changed the name - to keep it the same
Regarding the error when the image already exists: In Qemu.pm only disks
that were previously marked as unused get deleted
($test_deallocate_drive), also this function ignores cdrom drives.
Maybe a media=cloudinit would be useful after all?
On one side it would give us an easy condition to allow de
>>I'd like to pick this up again. Have you made any more changes?
No change since the last time. (I would like to work on it again too)
>>Currently generating the cloudinit image is a one-shot mechanism (and
>>also currently fails if the image already exists.), it ends up as a
>>"normal" (persist
> > Anyways, I tested the patch, and volume_resize() now returns without errors.
> > The problem is that it does not resize the underlying LVM volume.
> >
> > Do I need to install any drbdmanage updates/patches to make that work?
>
> I just scanned the drbdmanage sources, and the corresponding im
> > Please see attached a patch to implement "resize" for the DRBD backend.
> >
> > I hope it matches all your coding style guidelines;
> > feedback is welcome, of course.
>
> Please can you send patches inline? That way it is easier to review code
> and add comments. I copied the code for this p
39 matches
Mail list logo
