Search results

For /tmp specifically it should be possible to do without a mountpoint. Most distros allow a mounting a tmpfs. So unless you require a shared mount for some reason you should be able to solve your issue simply by adding a proper entry to /etc/fstab in the container. tmpfs /tmp tmpfs...

You might be able to get your own ticket from /access/ticket.

I suggest you open a bug/feature over at our bugzilla. This way the issue doesn't get lost and you'll even get a notification when it's fixed.

No.

Huh… according to the posts linked here we either overwrite custom settings when regenerating the config or ignore/bypass them altogether.

Did you look into LXC's hooks? I suppose it should be possible to define mountopts in some mount hook.

Not quite sure I understand you correctly. The max backups configuration defines how many backups are allowed in that storage per guest. So if you require daily backups you need to store the backups for VM1 and VM2 on different storages, from PVE's point of view, one configured to retain 8...

That's not what I meant. Create a new container from the template you normally use. Or, if you already use a custom template, skip this step. In that container edit /etc/motd to your liking. If it isn't already a template, make a backup of the container, and move it to a storage that can...

btw, there's an edit function in the forum, so you don't have to post twice.

As I said, it should work but I doubt it's been tested extensively. The corosync version is the same, so the nodes can communicate just fine. The backup format didn't change and migration should work, too, but only from 4 to 5.

Of course it's possible. We don't usually expect people to take their whole cluster offline to upgrade. But I don't think it's been tested for extended periods of time. So while I don't expect the cluster to explode when you update one node I'm not sure what will happen if you keep it that way...

I wouldn't. PVE 5 uses newer versions of many packages, like ceph for example. So even if PVE works with different versions in the same cluster you may end up braking things the cluster uses. If you only want to test PVE 5 (as in not use in production) I suggest making a VM running it. If you...

Edit /etc/motd. Probably for every existing container. You can create a new container, edit the file to your liking and declare the container a template. This way you don't need to make the edit for future containers but just use the new template.

`qm help set` lists you all possible settings along with the valid and default settings. Setting it to the default should be equivalent to unsetting in most cases. For settings like -cdrom you could try an empty string.

Yes, but it's possible to over-commission. You can create a 32G zvol in a pool with 8G free space. Basically I'd just like to be sure that all parties have enough free space. You need to be able to store one more backup than the max backups you configured for the backup storage. So if you have a...

What does the task log tell? Is there enough free space left on all volumes (virtual disks, volumes they reside on, backup storage)?

You just have to mark the storage the disks reside on correctly. Actually shared storage as "Shared" and local storage as non-shared. Migration should automatically move the disk images on non-shared storage and keep the ones on shared storage.

Oh, it's a container. In that case the image does contain a partition. :rolleyes: Sorry for the confusion. So yes, it seems like the FS took a hit. Did something happen to the container?

You can scan the partition table of the image with # partx -va /var/lib/vz/images/107/vm-107-disk-1.raw That will show you the partitions it found and also the loop device it uses for the image. You can then mount it with a regular mount, as the loop has already been taken care of. To fsck it...