We have all APCs and they work fine in our DC. They work fine for us which include our windows and linux servers.

https://forum.proxmox.com/threads/setting-time-options.28099/

System time is generally viewed as UTC Time - which I can understand for standardization.
Will have to 'adjust' my expectations.

@scottalanmiller said in Broadcom Acquired VMware: Does KVM Have a Chance?:

@CCWTech said in Broadcom Acquired VMware: Does KVM Have a Chance?:

@Oksana You couldn't pay me enough to use VMware. KVM is the industry standard and has been for years. And VMware with the recent announcement to kill their free offerings is now just a sinking ship.

And it isn't like when it was free, it was worth it. It was laughable what a bad product it was for free. Paying for it is totally insane.

The people who are using VMware have to either be getting kickbacks or completely ignorant or incompetent tbh.

@WLS-ITGuy Typically we use the time to rebuild. Any VM should, in theory, be quick and easy to rebuild. If it isn't, it's the perfect time to make it so.

If you absolutely have to convert rather than move through application migration, then there are disk conversation tools that change the format. There's very little needed for the migration.

After scouring countless sites and articles, only thing that could fully read the drives was UFS Explorer. $700 later and many, many crashes, we are starting to have a reliable process of recovering the data. We have to use UFS Explorer and recover as raw disk images. Then attach those raw images to new VMs manually. Then do a Windows recover to each one.

Proxmox is great so far. 2 servers, setup and available for replication/migration via separate 10G NICs that are direct connected. Then a PBS server where everything is backed up to. So far, so good.

Leaving this new system standalone, not joining the old cluster or creating a single system cluster.

The new (added in 7.3) qm remote-migrate works well. The docs suck, but the function is great.
bb4d3436-413c-4121-bbba-92032927da78-image.png

3124c7d3-2c98-4f08-966d-5d2089534292-image.png

9247c618-4860-410c-880d-b53698015d98-image.png

@Pete-S said in ProxMox: Set VM to AutoStart from Command Line CLI Start:

Nice but it's even easier with pure kvm as you don't have to go the roundabout way of using VMid.

virsh autostart somevm

Personally I find the number quite a bit easier.

@scottalanmiller said in Proxmox hates security:

@Pete-S said in Proxmox hates security:

@scottalanmiller said in Proxmox hates security:

@Pete-S said in Proxmox hates security:

I'm not saying Proxmox is insecure, I'm just saying it wasn't designed with security as it's primary focus.
KVM by default for instance is managed by libvirt and by default doesn't open any tcp ports at all. That gives the administrator the option to decide what level of security versus convenience they want.

Ignoring "by default" in that, ProxMox can be the same. You can close everything up and only manage however you like. You don't have to use the web interface on it, it can be totally shut down. Obviously defeating lots of the purpose, but plausible.

I spend far more time on ProxMox via command line via MeshCentral than via the web interface and the web interface, while we don't lock it down from the LAN in most cases (we run a LOT of ProxMox these days) we primarily access it from the PM host itself from a jump box running on top of it for the cases when the web interface is needed. So while we don't go to the degree of locking it off from the LAN, we could and we wouldn't notice the difference most of the time.

That's not a default, so obviously totally different. But it's a really simple setting.

That's good to know.

We don't use gui anymore either but we're moving away from pre-packaged hypervisors and to pure KVM with libvirt compatible management tools.

We have found that to be the best solution for our use case (high degree of automation and customization).

I'd like to see that for sure. There's a lot of benefit to that, potentially at least.

We're automating a lot.

But the real problem is not the automation itself. The real problem is that automation and standardization is time consuming.

It's an easy fix. Sometimes the directions for the upgrade don't account for the source location of the APT REPO for ProxMox. Check your /etc/apt files and see where your repo is configured. If you are going from Buster to Bullseye for example, make sure that you have this line somewhere and the error should go away...

deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription

I don't know if ubuntu has a similar cloud kernel.

Update: It looks like there is a linux-kvm kernel amongst others. Haven't tried it though.

BTW, in Debian/Ubuntu and other distros the different kernels are often referred to as kernel flavors. Good to know if you want to search for them.

@Pete-S said in Live migration Proxmox?:

@JaredBusch said in Live migration Proxmox?:

@Pete-S That is what the docs say. I have never tried.

But also, why not have everything in the cluster? What is the need to make them "individual" hosts?

Pools (resource pools) as they are called in xenserver/xcp-ng will put at lot of restrictions on the hosts.

Pools are managed as one entity (through the pool master) and works best when you have shared storage.

They are however a huge hassle when you don't have shared storage. So hosts that use local storage and are individual are best kept as separate hosts. So in this case everything started out as pools but have been migrated to individual hosts.

Maybe it works differently in Proxmox, I've only used it in the lab on a single host.

I manage multiple servers through the single IP of the cluster, but you can still directly access the individual nodes if you desire.

I do not know about resource pools and such as I have not used those with Proxmox yet. Just multiple servers in a cluster, but no shared resources more than a setup for replication at one place. But that one is only for replication, so not a good example.