Search results

"The filesystem disk format is no longer unstable" means that you can be sure that filesystem created with latest btrfstool will run on any more recent kernel. Filesystem still under development, which means that in any moment new cool bugs can be introduced, so usage in production environments...

No, after few months of active usage I didn't seen any other problems. But not using virtio drivers may be bad idea on some workloads. I had webserver stuck with network IRQ processing on VM with virtual e1000 dev, where virtio-net done just fine. Who said you that? Didn't found any info where...

Still no OpenVZ and some bugs present. See for example http://forum.proxmox.com/threads/19194-VM-start-problem-with-virtio-net

You can add directory where your ramdisk is mounted to PVE as storage and manually add one of images there to VM's configs. But you need something to recreate images after host reboots because without it them VMs will not start. And to share single image on several machines you will need to use...

Yes, even after I have raised memory usage and ran all load that caused problem several times: free -m total used free shared buffers cached Mem: 64348 63147 1201 0 150 26045 -/+ buffers/cache: 36951 27396...

Patch submitted to pve-devel and I'm testing fixed kernel. Successfully. Still not commited to PVE's git. Actually e1000 shouldn't be affected. If it is, then this is another bug.

Maybe just use rbd export/import command to backup/restore rbd images? It should be much faster than qemu's backup.

I have 20MB/s for allocated space and 40 for unallocated (reported sparse). Mayde there's easy way to enable readahead at lower level, while still read 64k in qemu's backup level?

Could You show current fully-patched net.c? I'm sure that I can adopt patch to it. It should be easy... I'll try tomorrow with current CentOS's kernel :)

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/vhost/net.c?id=d04257b07f2362d4eb550952d5bf5f4241a8046d and https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/vhost/net.c?id=23cc5a991c7a9fb7e6d6550e65cee4f4173111c5 Not sure...

May be not directly. But in 3.16.1 same technique is used: if kmalloc() didn't succeed, try vmalloc(). And now use kvfree() instead of own vhost_net_kvfree(). Comapre allocation of memory for variabe n in the beginning vhost_net_open() in...

In recent kernels another patch adopted: https://lkml.org/lkml/2013/1/23/492 Is it possible to apply it to PVE's 3.10-series kernel?

Hi. Yes. And no, there's only one small VM running on this host (I'm trying to start second) and most memory used as disk cache, which we can assume as free.

I have cluster of 3 almost identical nodes with ceph storage. From some poing it won't start new VMs with virtio network interfaces. If I change virtio to e1000 then all works fine. On fail it prints this to host's dmesg: Versions: And this seems like a fix...

I've read that witeback is cache inside host, no-cache is cache inside guest. Unsafe writeback is just writeback without forwarding flushes from guest to host.

/64 is minimal subnet in IPv6 by design. No one can guarantee longer prefixes to work. Need several subnets -- take several /64s.

Are You sure? In pass-thru mode all commands are (almost) directly forwarded from OS to physical disk. How they (or some subset) can be cached? Controller is (almost) just a PHY. Maybe You mean single-drive volumes? Controller's manual also not shows such features. Just enabling-disabling disk...

Actually, looks very similar: slow backup of network-storage-backed VM to network storage.

Controller's cache is usually ignored in pass through more. Actually, I've never seen it working. Only single-drive "RAIDs".

Same speed issue with backup of RBD-backed VMs to NFS. It's regardless of data fill of machine. All NICs are 10Gbps.