I figured it out myself: somehow PVE cached the Cloudinit.pm (The "Regenerate
Image" button still works even if I moved away the file; I don't speak Perl but
I think it's working as intended). I restarted pvedaemon.service and the iso
generation is working as intended.
--
Zhuoyun Wei
On Wed,
I did my little experiemnt:
root@inf-vmh-3:~# for i in /dev/pve/*cloudinit; do grep package_upgrade $i; done
Binary file /dev/pve/vm-104-cloudinit matches
Binary file /dev/pve/vm-110-cloudinit matches
Look, there are two VM (104 and 110) that have "package_upgrade" options in
their cloud-init
Hi again,
sorry for bringing this up. I have commented out the code that generates
hard-coded "package_upgrade: true" config in cloud-init drive two weeks ago.
And all worked well, until today.
Today I modified the hardware (CPU and memory) of a VM thru the Web UI, and
rebooted the VM. After
Tried that this morning, no luck. Not having much luck finding anything about
83h in vioscsi, but I did find a few things:
https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg04999.html
https://marc.info/?l=qemu-devel=146296689703152=2
Hi Alwin,
On 8-2-2019 9:41, Alwin Antreich wrote:
I pressume, that you run hyper-converged (CT/VM) on the machine. As you
mentioned there where issues with slow request due to some "sudden" high
resource demand, it could be that most of the memory contents, oft that
OSD, where swapped out.
On 2/11/19 9:18 PM, Edwin Pers wrote:
Happy Monday all,
Trying to get storage spaces direct running. WinSvr2016 guests, PVE 5.2-2, NFS
shared storage for the guest disk images.
I'm getting an error when running the cluster validator in windows: "The required
inquiry data (SCSI page 83h VPD
