Search results

Just go with the stand-alone TrueNAS solution. Your life will be simpler.

Another question: Are you using PVE standard authentication or something else? What realm do you select on the login box?

The same way he got the install ISO. I notice too that almost nobody who has this problem admits it up front that they used a script.

Most people who have that problem got it by running an old "community script" that supposedly removes the "nag screen" but doesn't support PVE 9. The fix is to not do that.

It is also going to be a significant performance hit, especially when running under a hypervisor where nested virtualization must be enabled. The question is whether it is worth it or not. For a server that presumably doesn't have interactive users. This industry is completely full of itself...

One might also ask what the benefit of VBS is when you're already in a virtualized environment.

As @JensF said, open a root console or SSH session, use nano to edit /etc/apt/sources.list. Apparently there is also something going on with /etc/apt/sources.list.d/cisofy-lynis.list, but I can't say what exactly since I don't use that. Maybe PVE is just complaining because it is non-standard...

The Suites element for debian-security should be bookworm-security, not bookworm/updates.

What is "level-zero"? It isn't part of a standard install, so guessing it is a third party package and it conflicts with some Debian files. Maybe remove that until the upgrade is complete. If it was installed from third-party repo you might want to see if there is a version compatible with...

I would disable it. Containers get their time from the host anyway. There's no point in running another NTP client in the container.

Glad to hear you got it sorted. Please mark the thread solved by editing your first post.

One thing I don't get about homelabbers is using a bunch of vlans and then making sure there is complete connectivity between them.

You can have multiple vlans on a single VM. They can all use DHCP.

Having more than one NIC on the same network isn't a good idea for Windows either, although they do have differences in the way they handle that. Even listening to 0.0.0:8006 won't really solve the problem because it is a bridge. Unplugging the cable doesn't make the bridge go away, and usually...

What shouldn't be what way? Don't know what you mean by that. What I stated is how the kernel has always worked and it is why having multiple IP's on the same subnet can result in confusing behavior. The other thing, of course, is that the PVE gui may bind to specific interfaces on startup...

Both bridges are in the same network, so the kernel will pick one at random for reply packets. Remove the IP from the "slow" one and it should use the "fast" one.

Backup jobs sort of "pre-start" the VM (I forget why), so if the VM has a pass-thru device that is also passed to another VM that is running you will see this problem.

You are setting up a very complex scenario. I don't have time this morning to walk you through all the complexities of what you are trying to do with regard to the dual ISP setup. It is called "multi-homing" and you can look it up. That is not a trivial thing to get working and depending on what...

Did you set a DNS when you configured the VM? If it gets an IP via DHCP, make sure the DHCP server is sending the DNS option. The settings on your PVE host are not relevant to the VM.

This is kind of a mess. You should not have gateways specified for all the bridges, and you should not have a gateway that's on a different network than the bridge, and you should not have the same /24 on multiple interfaces unless they really are connected to the same network (and even that is...