Search results

cat /etc/pve/storage.cfg

So you want to run ZFS and a VM with ~12GB RAM allocated in a host that has a total of 16GB?

1. You are talking about SAS, not SATA. 2. Unless you find your controller in a dumpster, any recent (7-8 years) controller should do it. Event stupid SATA multipliers work, although not recommended. The controllers have nothing to do with deduplication. The story is simple: DDT fits in memory...

zpool attach tank mir sigxcpu :)

1. set the virtual disk type to SCSI 2. set the SCSI controller type (in "Options") to VIRTIO-SCSI Start the VM and do a "fstrim /" or the filesystems you want to trim. For Windows or other OSes you need to find the equivalent.

Are you sure that is the boot log of the container? It looks like host's one. What is the output of lxc-start -n <container id> -F -l debug -o /dev/stdout

I hardly think you will saturate the link bond before saturating I/O on a storm boot (you can play with order and delay on autoboot, anyway).

What does /proc/meminfo show when you use transparent hugepages? LE: Sorry, I've seen above. 8GB only. Is that with the VM on? Start the VM (remove the mem-path thing and set vm.hugepages to 0) and post the whole contents of /proc/meminfo please.

Where did mode=1770,gid=2021 come from?

It is best to add vm.hugepages=something into your /etc/sysctl.conf and reboot the machine as you will not be able to reserve them if you already fiddled with stuff. It looks like a page is 2MB, so for 320GB you will want to allocate 163840 of them.

you add in the <VMID>.conf args: -mem-path /hugepages

Try this: http://www.linux-kvm.com/content/get-performance-boost-backing-your-kvm-guest-hugetlbfs

You separate the 4x NICs in 2+2, add the other two in vmbr1. You will need to keep vmbr0 for cluster comms (and strorage?) and then move the VMs to vmbr1.

Then I think you will need to fiddle with "Firewall" section on each VM. I don't know if it will apply security inter-VM or you will need to play with bridge firewalls, too.

Never said it is hardware. It looks like pve-manager (daemon, not service) does not do its job on shutdown. The "Stopping VMs and Containers" comes from /etc/init.d/pve-manager script. "stopall" is puhsed as the service script says, it seems, but nothing after, except "OK" that may mean "OK...

Keep management network untagged. Use tagged VLANs for all your VMs.

If it is local ZFS you can use SCSI VIRTIO and do a full drive TRIM. ZFS volumes support UNMAP.

You can do it low level if you use ZFS storage. You can do full backups, incremental backups and, best of all, the backup-ed live VM does not change during the copying of the backup (as you copy the snapshot). Of course, it is not ideal because you don't stop/free+sync the VM, but much better...

I told you I don't know about FreeBSD. You should need to fix the root device first (in /etc/fstab and wherever else is specified for booting), then the /dev entries, maybe.

I know that. That is why I've asked you about host shutdown logs, not the task viewer/event viewer.