Recent content by Blub

You could use a somewhat weird workaround: Use the host's ssh, and add Match User sections with ForceCommand entries... Assuming the guest VMs also each have an internal IP, like fc00::1 and fc00::2 Match User user1 ForceCommand ssh user1@fc00::1 Match User user2 ForceCommand ssh...

As far as I can tell OVH's IPv6 related documentation is a bit off, actually. Eg this[1] claims you need a failover IP configured with a vMAC to be able to use more than one IPv6 address. We don't have that, yet are successfully using multiple addresses from our range. The same document also...

Followers of the vi(m) religion don't believe in arrow keys. Our movement keys are h, j, k and l ;-) That said - for me they work in normal-mode and produce letters only in insert mode. It's a different story when you're using VNC... maybe... (Why would you go through all the trouble to move...

I guess the easiest way to support the standard LXC way is to mount the rootfs on the host into LXC's standard directory instead of changing lxc.rootfs to the image file in the PVE code. In the mean time a dirty hack you can always use is using sshfs from guest to host, but the guest needs to...

Because it's newer, and vendors simply don't test other kernels. If you have any info on how RH kernels are actually better, let me know. Meanwhile: https://git.proxmox.com/?p=corosync-pve.git;a=commit;h=3b3cd2bfc5d44834cf9b396cf6303301dae63ba1 These days it's: newer kernel = fewer bugs to work...

The fixes are upstream so they will be in the next kernel update I suppose. As for older kernels (like ancient openvz stuff) ... I don't know. Do they apply conflict-free?

Can you use tcpdump on the host on the vmbr4 and the VM's tap interfaces to see where the packets get lost? While running a ping from VM1 to VM2: $ tcpdump -n -i vmbr4 ip proto '\icmp' $ tcpdump -n -i tap${VMID1}i0 ip proto '\icmp' $ tcpdump -n -i tap${VMID2}i0 ip proto '\icmp' EDIT: I was...

It may have been compiled for the regular debian kernel package so you might have to build it from source for the PVE kernel package.

Re: grub defekt nach Festplattenausfall After chrooting make sure you have a /etc/grub.d/10_linux file around. This is what's responsible for detecting the current OS and is part of the grub-common package. Then make sure you actually have the necessary files in /boot and that they're healthy...

Probably not the answer you're looking for but: If it's not in the GUI you can manually add qemu parameters to a VM via the `args` key in /etc/pve/qemu-server/${VMID}.conf. (...) #other options args: -your qemu,options -here http://pve.proxmox.com/wiki/Manual:_vm.conf

Re: Proxmox+Ceph: pveceph createmon: unable to find local address within network Seems the parsing code is a bit strict there. But then again there are a bunch of options for interfaces, there are mappings, and there's no good general parser available that I can find. (All the 3rd party...

Re: Proxmox+Ceph: pveceph createmon: unable to find local address within network It only reads addresses "eth*" devices. Which is a somewhat limited heuristic. The above change should almost do it, except the address you're trying to use is on bond0 not ib0, so make that (eth|bond) (or include...

Sorry, those symptoms are different from mine so I don't really know what to say except that you could maybe test with different browsers and/or java versions. :-/

A clone should have everything exactly like what it was cloned from. Changing the password of a VM unfortunately is no easy task. There simply is no general solution there. Just consider that the VM could have a custom partition layout, maybe even encrypted disks, or use an unknown OS with an...

What is your ultimate goal though? While with 3.4 the PVE interfaces don't support ipv6 (aside from all the other packages like rpcbind, a bunch of perl libs, parts of the kernel even (multicast issues etc.)), these are package specific issues. But general networking should work nonetheless as...