As stated, this surely does work, but it's really cumbersome to manually recreate these cloud-init disks if you have a lot of machines using them. Is there a particular reason the functionality to move them couldn't be added? It'd be a lot more convenient, faster and less error prone if one...
Thanks @Fabian_E , that makes sense. I did disable it on all my nodes and migration does indeed work now. What I'm curious about is why and how it could and used to work in previous versions of PVE? Maybe it was a "bug" in earlier releases? It just came as a surprise that it suddenly didn't work.
@mrE
It doesn't make sense to me that you marked this as "SOLVED". It appears that you were able to migrate VMs/CTs between nodes perfectly fine before the upgrade, but after the upgrade the functionality is no longer there. Having backups of everything is obviously good, but it's far from a...
Thanks for the suggestion @Alwin. However, that's not exactly what I meant. That command does indeed get me the serial number of a disk, if set. My issue is more about not having a serial number for VM disks to begin with.
In my specific use case, I have several VMs with many disks attached...
@Alwin @oguz
I've had the same problem multiple times. And I just found this thread. This should really be a feature when you add a disk to a VM. Given how easy it is to actually get this functionality with a little conf file "hack", a simple checkbox to generate a "unique disk serial number"...
Hi,
There was no real movement on backups and archiving into Swift that I could find. So, my team ended up building a relatively simple tool that can be used in various ways, including for Proxmox VE backups. Here's some information about "Watch Folder", written in Golang...
Hi,
We're having some problems replacing a PVE node in a cluster. These are the steps we've taken so far:
Turn off pve03 (out of 3).
From pve01, remove pve03 from the cluster with: pvecm delnode pve03
Unrack the hardware.
Mount a new server to become the new pve03.
Perform clean install of...
@wbumiller I just tried your suggestion to add features: nesting=1 in an Ubuntu 18.04 LXC container. It starts fine. Then I go ahead and install snapd, but it fails to start snapd.service. I've tried to run the container both in unprivileged and privileged mode, but it doesn't make a difference...
BUMP ... No one has a solution for this? If I shut down the container and back it up manually, I can get a backup to work. However, that's really not a great way to go about it.
I have an LXC container running on a Ceph pool. It's running just fine. It has a nightly backup set up to run. For the last week or so, the backup keeps on failing with:
vzdump 60180 --mailnotification always --mode snapshot --mailto someone@example.com --quiet 1 --storage nas01-backup-7x...
Yes. Have it working on PVE 5.1 with "auto-TLS" on port 389, like this:
ldap: domain.com
comment My LDAP
base_dn dc=domain,dc=com
server1 ldap.domain.com
user_attr uid
default 1
secure 0
server2 ldap-master.domain.com
@fabian First, thanks for the quick response, Second, sorry, I should've been more clear in my question. I also get the correct output/settings, like what you showed in your example. What I should've asked is if there was anything in addition to that I need to do to get ELK 5.x running. As it...
@Stefan Wienert I've tried setting the `max_map_count` on the host but it doesn't work. I've successfully done the same on Docker hosts in the past in order to run ELK. I'm running PVE5 now. Is this method still working for you?
@fabian Any ideas?
Dietmar,
You're asking: "What kind of ssl certificated do you use (default ones)?"
I'm running 3.4-6/102d4547 and I've got commercial certs applied. Why would anything other than the stock self-signed certs be a problem? Or maybe I'm misinterpreting the reason for your question? In any case...
I have the same/similar issue. I'm using a cert issued by a commercial entity (DigiCert). It's giving me "Spice-Warning **: ssl_verify.c:489:openssl_verify: ssl: verification failed", which I highly doubt, as the cert validates fine in all browsers. I did replace the self-signed Proxmox certs as...
Well, it was worth a try. Unfortunately using 'setarch x86_64' doesn't work in my case, as the application I'm trying to install is specifically looking at 'uname -a'. I'll keep on digging and will report back here if I find a solution.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.