I've moved most of our important stuff onto Proxmox over the last 2 to 3 years. It's been great.
I've been using the PBS as well for the backups - it's so much better than manually doing full backups of VMs (which was the case with KVM and it's tools).
So thumbs up for Proxmox from me.
We moved from LastPass to 1Password. We liked the flow of it better.
As a company they've been very attentive and responsive even after they got our money which isn't always the case!
The subscription we got includes free home accounts as well that link to the business ones.
Congrats Scott. Is there any extra benefit to you if I buy from Packt Publishing rather than Amazon, or vice versa?
@DustinB3403
I don't doubt it.
There wasn't really any added complexity though. PVE was installed with all the defaults.
@JaredBusch
Yes - I've done that a few times. I'm running with the default LVM.
I think it might be a little less picky about CPU options (during a migration) than raw KVM too. Though I definitely don't have enough data to say that with lots of confidence.
That's true but being able to schedule backups easily from the console (even if they are full backups) is a benefit over raw KVM which was the question.
Actually another benefit is being able to live migrate between cluster hosts (without shared storage) from the console. I could live migrate stuff from raw KVM but only from the command line on the host.
@JaredBusch
The reason I'm in the process of moving over to Proxmox is the ease of setting up backups. It's very straightforward and if a backup doesn't work then it doesn't require someone who understands scripting to work out why.
Since Proxmox backup server was introduced a few months ago, PVE has the ability to do incremental backups too.
Apart from that there's not much extra functionality.
Nice!
I'm on day 9 :man_getting_massage_medium-light_skin_tone:
Well since I use this forum a lot and I don't want to be seen as 'weird' I'll try to explain where I was coming from.
Yes I've been using vanilla KVM for a few years and I've always used qcow2. There was some talk about qcow2 earlier in the conversation with stacksofplates being quite positive about their advantages and then SAM saying that he uses qcow2 on lvm-thin mostly and it was the default for Proxmox.
So I thought - those guys generally know what they are talking about, let me see if I can make a qcow2 on lvm-thin.
But proxmox wouldn't let me until I created some directory storage on the thinpool.
Ok great that works - but that seems a little strange - let me ask the guys and gals on the forum what they think.
And here we are.
As regards moving to an appliance - I'm comfortable with KVM but I run our VM infrastructure mostly on my own. On occasions where I'm on holiday or otherwise unavailable, it would be helpful if at least a couple of others could administer the system (particularly backups).
@scottalanmiller said in Reconsidering ProxMox:
@Doyler3000 said in Reconsidering ProxMox:
The method of creating a volume group on the thinpool and creating the qcow2 files in that works for me. Just wondered if anyone had thoughts on whether that's the right thing to do.
Nothing wrong with that at a technical level, but makes no sense to try to work around ProxMox' mechanisms if using ProxMox.
So I'm wondering what I've missed. You use qcow2 on lvm-thin but I don't seem to have that option unless I create directory storage on top of the lvm-thin volume.
I'll keep playing around.
Yeah I'm considering moving form vanilla KVM, particularly for the simplified backup and restore options. Though I haven't yet tried the new proxmox backup server that's just been released. That might make the move more compelling.
Is there a philosophy behind them moving away from creating qcow2?
The method of creating a volume group on the thinpool and creating the qcow2 files in that works for me. Just wondered if anyone had thoughts on whether that's the right thing to do.
@scottalanmiller said in Reconsidering ProxMox:
@stacksofplates said in Reconsidering ProxMox:
@stacksofplates said in Reconsidering ProxMox:
@scottalanmiller said in Reconsidering ProxMox:
@stacksofplates said in Reconsidering ProxMox:
After all of this, I still don't get the use case for LVM backed VMs. Other than possibly, possibly a super IO heavy database. Even then, it's questionable.
That's roughly it, and yes, it remains questionable at the best of times.
In the cases where you need LVM fat, you almost certainly also need to avoid LVM because that itty bitty overhead is still too much.
Preallocated qcow2 images are 99% as fast as LVM volumes. Even with just preallocating just the metadata I've had almost native disk write speeds. You lose all of the advantages of qcow2 like libguestfs, the qemu agent, internal and external snapshots, etc.
that said, no idea how the eff you do that with ProxMox. That was just KVM.
It's the default actually. We use Qcow2 on LVM-Thin mostly.
Hi Scott (and everyone else),
I've been playing around with Proxmox for a week or so. I haven't used LVM thinpools before so I wanted to check if I'm making sense here. Proxmox doesn't let me put a qcow directly onto a thinpool (like the local-lvm created by default).
Do I need to create a volume group on top of the thinpool, and mount that as directory storage to be able to use qcow2 on LVM-Thin as you're doing?
Cheers!
We've had the Meeting Owl for about a year now. It's great - though the room it's in is smaller than yours.
We've got another larger room with a more traditional camera. That room is less popular than the smaller one, partly because at the remote end people prefer the view given by the Meeting Owl.
I didn't have an account so I've just created one. I can create my first network up to 100 nodes. So maybe the 50 on the pricing page is a a typo?
@JaredBusch We're using Zoom.
We had been using something called Starleaf but it didn't work with the Meeting Owl as well. That's one of the reasons we moved to Zoom.
There's a Meeting Owl Pro for bigger rooms but it's not available for us in the UK until later this year. When it is I think we'll be buying that for our main conference room.
We've recently started to use a Meeting Owl in our smaller meeting room (maybe 6 people capacity)
The remote workers love it and insist we use it rather than a traditional front of the room cam.
I've got two physical interfaces in a team, on the bridge that the production VMs are on.
You think this relates to the "Ooops" ? or the "name not activatable" error?
And in cockpit, clicking on virtual networks causes an "unexpected internal error". So much for that replacing virt-manager.
In the interests of reopening the previous closure, virtual networks are broken again. I can't create or start virtual networks. Same 'name is not activatable ' rubbish 
Annoying.
In the interests of "closure", the plethora of libvirt updates which came down the line yesterday from fedora seem to have fixed the problem. I can now create virtual networks again. Yay!