Jekyll2026-10-15T10:05:30+08:00https://www.ikrazel.com/feed.xml米斯特周A minimal, responsive and feature-rich Jekyll theme for technical writing.老周推荐:Typora 能做的，它全能做2026-10-15T09:13:32+08:002026-10-15T09:13:32+08:00https://www.ikrazel.com/posts/solomd-free-typoraAI时代，人人都可以做开发，也是重复造轮子的时代，今天我想介绍一个markdown编辑器SoloMD，1.3K star，截止目前下载量超过81k，SoloMD既是markdown编辑器，又内置了Agent面板，一些活可以交给AI处理。

卖点：Typora 能做的，它全能做。免费。

所见即所得实时预览、多标签、主题、PDF / Word 导出 。并且还有 AI 改写、文件夹同步、原生 iOS 与 Android 应用。MIT 开源，无账号、无订阅、无广告。

卖点：技术架构新，macOS · Win · Linux · iPad/iOS/安卓统统拿下

技术架构：

  • Tauri2
  • Vue3
  • Codemirror6

系统要求： Windows 10+、macOS 10.15+、主流 Linux 发行版、iOS 15+、Android 7+(API 24)。

卖点：隐私与安全

纯客户端。你的.md文件留在你选的文件夹里。API key存在系统钥匙串(macOS Keychain / Windows Credential Manager / Linux libsecret),永远不进 localStorage 或配置文件。AI 请求从你的机器直连厂商 —— 不经 SoloMD 中转。RAG 嵌入索引和 AutoGit 仓库都是本地。MCP server 默认走 stdio;可选的 HTTP 传输默认只监听本机,并可要求 Bearer token。整个代码库 MIT 协议,可审计。

Agent 安全护栏(v4.0)。 每次 Recipe 运行都开自己的 AutoGit 分支 —— main 在你点 Accept 之前一动不动。单次 write-cap(默认 5,硬上限 50)防止失控循环。Recipe runner 在工作区脏时直接拒绝启动(agent commit 不会扫到你的 WIP)。所有接受用户传入路径的 Tauri / MCP / REST 端点都前置拒绝 .. 段和绝对路径。

E2EE 同步用 Argon2id(RFC9106 默认参数)→ XChaCha20-Poly1305,确定性 nonce + path-as-AAD。明文留在你的设备上;远端只看到密文。sync.json 解析失败会拒绝推送,绝不降级到明文(v3.0.x 审计修过的一条)。

目前最新版本：v5.0.1

官方网站：SoloMD

github仓库：SoloMD仓库

]]>关于静态博客引擎的比较2026-10-10T10:50:32+08:002026-10-10T10:50:32+08:00https://www.ikrazel.com/posts/about-static-blog-engine一直以来，我都在使用静态博客引擎来搭建我的个人博客。经过多年的使用和比较，我对几款主流的静态博客引擎有了一些自己的看法。

jekyll

先来说jekyll吧，一直让我感觉很没有存在感的这个引擎，虽然它是GitHub Pages的官方支持引擎，但在国内的使用率并不高。jekyll的优点是简单易用，适合初学者入门，而且有大量的主题和插件可以选择。然而，它的缺点也很明显，构建速度较慢，尤其是在内容较多的时候，生成静态页面的时间会显著增加。此外，jekyll对Windows用户的支持不够友好，需要额外安装Ruby环境，这对于一些新手来说可能是一个门槛。

我一般都不安装ruby环境，就是直接使用GitHub Actions来构建jekyll博客，这样可以避免在本地环境中遇到的各种问题。不过，这也意味着每次更新博客内容时，都需要等待GitHub Actions的构建时间，这对于频繁更新的博客来说，可能会有些不便。目前我的博客文章大概在800多条数据，使用jekyll构建一次大概需要就几分钟搞定，没有任何错误。我这些博文都是从pjblog时代迁移到wordpress，然后又迁移到typecho，最后全部转为markdown了，文件本身也存在各种语法问题，前前后后折腾了很多次。

我想说的就是即便文档存在各种问题，jekyll都能顺利构建成功，这说明jekyll的容错能力还是很强的。对于我来说，jekyll的稳定性和可靠性是它最大的优势。

hugo

再来说说hugo吧，hugo曾经也是我最推荐的静态博客引擎，可是更新迭代多次后，虽然构建速度快，但是越来越难用了。这两天，我本来想把我的hugo博客升级一下，换换主题，使用了stack主题，托管在Netlify平台上进行构建，昨天一直构建失败，都是和post文件有关系，来来回回改动了好多次，最后我忍无可忍，把全量文件全部修了一遍，我以为这样就可以构建成功了，结果又失败了，而且netlify的credit也用完了，一气之下，从netlify删了项目全部搬家到cloudflare上了。按理说，使用golang开发的hugo，应该是效率很高的，但是，给我的感觉是构建速度没有以前那么快了，而且从昨天一天的折腾来看，我其实挺失望的。

hexo

以前挺火的hexo，不知道发生了什么事情，国内的使用率好像下降了，我在网上浏览了一些以前做hexo主题的个人博客，发现都转hugo了。我试用了一下hexo 8.1.2，构建我的博客速度还行，没有以前那么慢了，以前真的是特别慢，而且构建时经常报错，就是因为post文件被转了多次，文件中存在不合适的语法问题，或者特殊符号等等问题，所以才转了hugo。今天构建时，也报错了，虽然昨天把全量post文件改了一次，今天构建时仍然有五六个文件因为格式问题，构建出错，修复后，构建成功。然后就默默删除了静态部署。

所以呢，图省事，感觉还是jekyll确实是最稳定的静态博客引擎首选。如果是从零开始写博，根据自己的喜好，以及，喜欢的主题，选择合适的静态博客引擎。话说，现在估计也没多少人写了吧。

]]>CertBot申请证书2026-04-13T10:50:32+08:002026-04-13T10:50:32+08:00https://www.ikrazel.com/posts/howto-use-certbot-with-cloudflare1、安装certbot

1

apt install certbot python3-certbot-dns-cloudflare

2、设置cloudflare Token

1
2
3
4
5
6

vi .cerbot

# cloudflare token
dns_cloudflare_api_token = your_cloudflare_token

chmod 600 .cerbot

3、申请证书

1

certbot certonly --dns-cloudflare --dns-cloudflare-credentials ~/.certbot -d example.com

4、部署脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#!/bin/bash

# 定义目标域名和目标目录
DOMAIN="example.com"  # 替换为你的域名
DEST_DIR="/path/to/destination"  # 替换为目标目录

# 检查目标目录是否存在，不存在则创建
if [ ! -d "$DEST_DIR" ]; then
    mkdir -p "$DEST_DIR"
fi

# 从 Certbot 的默认目录复制证书文件到目标目录
cp "/etc/letsencrypt/live/$DOMAIN/privkey.pem" "$DEST_DIR/privkey.pem"
cp "/etc/letsencrypt/live/$DOMAIN/fullchain.pem" "$DEST_DIR/fullchain.pem"

# 设置目标目录中的文件权限
chmod 600 "$DEST_DIR/privkey.pem" "$DEST_DIR/fullchain.pem"

echo "证书已成功复制到 $DEST_DIR"

6、调用脚本

1

certbot renew --deploy-hook "/path/to/your/script.sh"
]]>Tailscale-自建Derp中继服务器2026-03-12T15:29:32+08:002026-03-12T15:29:32+08:00https://www.ikrazel.com/posts/tailscale-setting-derp-relay-server1. Tailscale 与 DERP 简介

Tailscale 是什么？

Tailscale 是一个基于 Wireguard 的带有多种网络工具的 P2P 组网工具。得益于其 P2P 的特性，Tailscale 还可以进行内网穿透，打破 NAT 的限制直达另一台主机。

DERP 是什么？

DERP是一个 Tailscale 自行开发的中继服务。当所处网络环境难以穿透（如校园网、移动大内网、4G、5G等）时，所有流量都会经由 DERP 中转至目标地址。

在默认情况下，Tailscale 官方已经提供了环大陆的官方 DERP 服务（见下方图 1），但是由于中国大陆的网络连通性等问题，官方并未提供大陆的 DERP 节点。为了确保大陆的打通成功率，我们需要自建一个 DERP 服务，来帮助我们“打洞”。

2. 安装 Docker 与 Docker compose

这段请自行参考 Docker 官方网站与其他作者写的部署教程，毕竟每个发行版都不尽相同。

1
2
3
4
5

curl -fsSL https://get.docker.com | bash -s docker

或者

curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun

3. 在 DERP 节点服务中部署 Tailscale 客户端

先安装

1

curl -fsSL https://tailscale.com/install.sh | sh

登录

1

tailscale login

4. 启动 Docker 镜像

可用的docker-compose.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

services:  
  derper:
    image: fredliang/derper
    restart: always
    ports:
      - 13443:443
      - 3478:3478/udp
    environment:
      DERP_DOMAIN: "derp.example.com"
      DERP_CERT_MODE: "manual"
      DERP_ADDR: ":443"
      DERP_VERIFY_CLENTS: "true"
    volumes:
      - /var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock
      - /home/derp:/app/certs

注意：本地路径 /home/derp 保存与域名相同名称的ssl证书和私钥，例如derp.example.com.cer,derp.example.com.key。

5. 配置 tailscale ACL

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

	"derpMap": {
		"OmitDefaultRegions": false,//这里改成true就是只用自己的derp互联，建议不改，如果要跨网可以改成true
		"Regions": {
			"900": {
				"RegionID":   900,
				"RegionCode": "85",
				"RegionName": "HK",
				"Nodes": [{
					"Name":     "myderp",
					"RegionID": 900,
					"HostName": "derp.example.com",
					"DERPPort": 13443,
					"STUNPort": 3478 //这里改成stun的端口
				}],
			},
		},
	},

6. 测试

重新连接Tailscale，然后测试

1

tailscale netcheck
]]>Github无法push代码报Connection closed2024-11-28T10:50:32+08:002024-11-28T10:50:32+08:00https://www.ikrazel.com/posts/how-to-fix-github-cant-push今天在更新博客文章时，发现无法push代码，错误如下：

1
2
3
4
5

Connection closed by 140.82.116.3 port 22
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Google了一下错误信息，反正肯定是和防火墙有关，禁止了我们访问GitHub的22端口，通过查看GitHub的文档，可以使用HTTPS端口进行push代码。

测试HTTPS端口的SSH是否可行

首先，要测试通过 HTTPS 端口的 SSH 是否可行，请运行以下 SSH 命令：：

1

ssh -T -p 443 git@ssh.github.com

返回如下信息，表示你可以使用这个办法去规避22端口无法push的问题：

1

Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.

修改SSH配置文件

打开.ssh/config文件，增加如下内容：

1
2
3
4

Host github.com
    Hostname ssh.github.com
    Port 443
    User git

测试

Clone代码

1

git clone ssh://git@ssh.github.com:443/YOUR-USERNAME/YOUR-REPOSITORY.git

Push代码

1

git push
]]>Cloudflare Tunnels无法建立隧道的解决办法2024-11-26T20:50:32+08:002024-11-26T20:50:32+08:00https://www.ikrazel.com/posts/how-to-fix-cloudflare-tunnel-no-connection今天在使用CloudFlare的tunnel，给NAS搞一个公网访问，结果发现从NAS里面运行docker，Cloudflare客户端无法建立连接，错误如下：

1
2
3
4
5
6

2024-11-26T09:05:39Z ERR Failed to dial a quic connection error="failed to dial to edge with quic: timeout: no recent network activity" connIndex=0 event=0 ip=198.18.0.50
2024-11-26T09:05:39Z INF Retrying connection in up to 2s connIndex=0 event=0 ip=198.18.0.50
2024-11-26T09:05:45Z ERR Failed to dial a quic connection error="failed to dial to edge with quic: timeout: no recent network activity" connIndex=0 event=0 ip=198.18.0.49
2024-11-26T09:05:45Z INF Retrying connection in up to 4s connIndex=0 event=0 ip=198.18.0.49
2024-11-26T09:05:54Z ERR Failed to dial a quic connection error="failed to dial to edge with quic: timeout: no recent network activity" connIndex=0 event=0 ip=198.18.0.50
2024-11-26T09:05:54Z INF Retrying connection in up to 8s connIndex=0 event=0 ip=198.18.0.50

网上查询了一下，大家的说法是NAT，防火墙，再就是客户端的协议方式，最后查了一下自己的网络，排除了NAT，防火墙问题，于是就按照下面的方式修改协议，在docker命令中增加--protocol http2即可，此时强制指定协议为http2，使用的是TCP，这样就不会被运营商阻断了。当然，也可以设置为–protocol auto ，开启自动切换，默认依然是quic，但是失败后可自动切换到http2。

1

sudo docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --protocol http2 --token <YOUR_TOKEN>

心想这样应该就可以了吧，结果又报了下面的错误：

1
2
3
4
5
6
7
8

2024-11-26T09:11:24Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: EOF" connIndex=0 event=0 ip=198.18.0.49
2024-11-26T09:11:24Z ERR Serve tunnel error error="TLS handshake with edge error: EOF" connIndex=0 event=0 ip=198.18.0.49
2024-11-26T09:11:24Z INF Retrying connection in up to 16s connIndex=0 event=0 ip=198.18.0.49
2024-11-26T09:11:32Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: EOF" connIndex=0 event=0 ip=198.18.0.50
2024-11-26T09:11:32Z ERR Serve tunnel error error="TLS handshake with edge error: EOF" connIndex=0 event=0 ip=198.18.0.50
2024-11-26T09:11:32Z INF Retrying connection in up to 32s connIndex=0 event=0 ip=198.18.0.50
2024-11-26T09:11:41Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: EOF" connIndex=0 event=0 ip=198.18.0.49
2024-11-26T09:11:41Z ERR Serve tunnel error error="TLS handshake with edge error: EOF" connIndex=0 event=0 ip=198.18.0.49

又是查网络发现这个issue说的靠谱，我家里是软路由透明代理，DNS应该是使用了旁路由的DNS，导致了这个问题，于是我把NAS的dns地址手动指定为我的主路由地址，再次运行docker，查看日志，it works!

1
2
3
4
5

2024-11-26T09:20:02Z INF Initial protocol http2
2024-11-26T09:20:02Z INF ICMP proxy will use A.A.A.A as source for IPv4
2024-11-26T09:20:02Z INF ICMP proxy will use 0000::0000:0000:0000:0000 in zone eth0 as source for IPv6
2024-11-26T09:20:07Z INF Starting metrics server on 127.0.0.1:45025/metrics
2024-11-26T09:20:08Z INF Registered tunnel connection connIndex=0 connection=xxxxxxxxx event=0 ip=198.41.200.193 location=sjc07 protocol=http2
]]>Stay With Me - Miki Matsubara2024-11-23T20:50:32+08:002024-11-23T20:50:32+08:00https://www.ikrazel.com/posts/stay-with-me-jp抖音流行了一个阶段，歌曲来自2008年发布的《Miki Matsubara Best Collection》 专辑。我特地查了一下这个歌星，很可惜的是在2004年10月7日，因宫颈癌去世，享年44岁。

歌词如下：

To you, yes, my love to you Yes, my love to you, you, to you 私は私 貴方は貴方と 昨夜言ってた そんな気もするわ グレイのジャケットに 見覚えがある コーヒーのしみ 相変らずなのね ショーウィンドウに 二人映れば Stay with me 真夜中のドアをたたき 帰らないでと泣いた あの季節が 今 目の前 Stay with me 口ぐせを言いながら 二人の瞬間を抱いて まだ忘れず 大事にしていた 恋と愛とは 違うものだよと 昨夜言われた そんな気もするわ 二度目の冬が来て 離れていった貴方の心 ふり返ればいつも そこに 貴方を感じていたの Stay with me 真夜中のドアをたたき 心に穴があいた あの季節が 今 目の前 Stay with me 淋しさまぎらわして 置いたレコードの針 同じメロディ 繰り返していた Stay with me 真夜中のドアをたたき 帰らないでと泣いた あの季節が 今 目の前 Stay with me 口ぐせを言いながら 二人の瞬間を抱いて まだ忘れず 暖めてた Stay with me 真夜中のドアをたたき 帰らないでと泣いた あの季節が 今 目の前 Stay with me 口ぐせを言いながら 二人の瞬間を抱いて まだ忘れず 暖めてた Stay with me 真夜中のドアをたたき 帰らないでと泣いた あの季節が 今 目の前 Stay with me

]]>CloudFlare Tunnel 免费内网穿透的简明教程2024-11-23T20:28:35+08:002024-11-23T20:28:35+08:00https://www.ikrazel.com/posts/howto-use-cloudflare-tunnelTunnel可以做什么[^1]
  • 将本地网络的服务暴露到公网，可以理解为内网穿透。 例如我们在本地服务器 192.168.1.1:3000 搭建了一个 Transmission 服务用于 BT 下载，我们只能在内网环境才能访问这个服务，但通过内网穿透技术，我们可以在任何广域网环境下访问该服务。相比 NPS 之类传统穿透服务，Tunnel 不需要公网云服务器，同时自带域名解析，无需 DDNS 和公网 IP。
  • 将非常规端口服务转发到 80/443 常规端口。 无论是使用公网 IP + DDNS 还是传统内网穿透服务，都免不了使用非常规端口进行访问，如果某些服务使用了复杂的重定向可能会导致 URL 中端口号丢失而引起不可控的问题，同时也不够优雅。
  • 自动为你的域名提供 HTTPS 认证。
  • 为你的服务提供额外保护认证。
  • 最重要的是——免费。

    Tunnel 工作原理

Tunnel 通过在本地网络运行的一个 Cloudflare 守护程序，与 Cloudflare 云端通信，将云端请求数据转发到本地网络的 IP + 端口。

前置条件

  • 持有一个域名
  • 将域名 DNS 解析托管到 CF
  • 内网有一台本地服务器，用于运行本地与 cloudflare 通信的 cloudflared 程序
  • 一张境内双币信用卡（仅用于添加付款方式，服务是免费的）

开始

  1. 打开 Cloudflare Zero Trust 工作台面板
  2. 创建 Cloudflare Zero Trust ，选择免费计划。需要提供付款方式，使用境内的双币卡即可 填写team name，随意填写 选择免费计划 添加付款方式 填写信用卡信息（仅验证，不会扣款），完成配置
  3. 完成后，在 Access Tunnels 中，创建一个 Tunnel。 创建 Tunnel
  4. 选择 Cloudflared 部署方式。 Tunnel 需要通过 Cloudflared 来建立云端与本地网络的通道，这里推荐选择 Docker 部署Cloudflared 守护进程以使用 Tunnel 功能。 获取 Cloudflared 启动命令及 Token 点击复制按钮复制指令，在本地网络主机上运行命令。我们还可以加上--name cloudflared -d --restart unless-stop为Docker容器增加名称和后台运行。你可以使用下方我修改好命令来创建 Docker，注意替换你为自己的 Token（就是网页中—-token之后的长串字符） 
    1

    docker run --name cloudflared -d --restart unless-stop cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <YourToken>
  5. 配置域名和转发URL 为你的域名配置一个子域名（Subdomain），Path 留空，URL 处填写内网服务的IP加端口号。注意 Type 处建议使用 HTTP，因为 Cloudflare 会自动为你提供 HTTPS，因此此处的转发目标可以是 HTTP 服务端口。 配置内网目标 IP+端口

完成

接着访问刚刚配置的三级域名，例如 https://app.yourdomain.com（是的，你没看错，是 https，cloudflare 已经自动为域名提供了 https 证书）就可以访问到内网的非公端口号服务了。一个 Tunnel 中可以添加多条三级域名来跳转到不同的内网服务，在 Tunnel 页面的 Public Hostname 中新增即可。

为你的服务添加额外验证

如果你觉得这种直接暴露内网服务的方式有较高的安全风险，我们还可以使用 Application 功能为服务添加额外的安全验证。

  1. 点击 Application - Get started。 创建 Application
  2. 选择 Self-hosted。 选择类型
  3. 填写配置，注意 Subdomain 和 Domain 需要使用刚刚创建的 Tunnel 服务相同的 Domain 配置。 配置三级域名
  4. 选择验证方式。填写 Policy name（任意）。在 Include 区域选择验证方式，示例图片中使用的是 Email 域名的方式，用户在访问该网络时需要使用指定的邮箱域名（如@gmail.com）验证，这种方式比较适合自定义域名的企业邮箱用户。另外你还可以指定特定完整邮箱地址、IP 地址范围等方式。 选择验证方式
  5. 完成添加

此时，访问 https://app.yourdomain.com 可以看到网站多了一个验证页面，使用刚刚设置的域名邮箱，接收验证码来访问。

评价

除了上述直接转发 http 服务之外，Tunnel 还支持 RDP、SSH 等协议的转发，玩法丰富，有待各位探索。作为一款免费的服务，简单的配置，低门槛使用条件，适合各位 Self-hosted 玩家尝试。不过要注意的是 Tunnel 在国内访问速度不快，并且有断流的情况，请酌情使用。

]]>使用WinSCP连接OneDrive2024-06-05T19:28:35+08:002024-06-05T19:28:35+08:00https://www.ikrazel.com/posts/winscp-webdav-onedrive使用WinSCP，基于WebDAV协议可以轻松地上传、管理、备份文件到OneDrive。

准备工作

找到你的”OneDrive客户ID”

打开浏览器，登录OneDrive，登录以后，地址栏的地址类似如下： https://onedrive.live.com/?id=root&cid=ABCDEFGHIJKLMNOP

这个ABCDEFGHIJKLMNOP就是你的客户ID，选中复制到粘贴板，我们一会要用。

WinSCP 配置

启动WinSCP工具，在显示的登录对话框中，选择WebDAV，加密类型选择TLS/SSL Implicit encryption，主机名填写d.docs.live.net，用户名和密码填写你的OneDrive账号和密码。

注意：如果你的OneDrive账号启用了二次验证，需要去创建app应用密码

接下来，点击Advanced按钮，在Environment > Directories下面的Remote Directory中填写 /ABCDEFGHIJKLMNOP

点击OK按钮确认，再次点击Save按钮保存设置。

开始使用

双击保存的会话名称，就可以连接了。

]]>PVE硬件直通之网卡直通2024-05-20T09:28:35+08:002024-05-20T09:28:35+08:00https://www.ikrazel.com/posts/pve-network-passthrough硬件直通这块，因为设备不同，不能硬套如下步骤，具体要多查一下谷歌，不要人云亦云。因为我的网卡是由PCIE转接的四个I226-V网卡，按照PVE官方的步骤，打开IOMMU之后，分配了网卡，但是无法启动，后来终于从google上查到了结果。

以下硬件直通步骤仅针对PVE 8.0以上版本。

打开IOMMU

1

nano /etc/default/grub

英特尔CPU使用下面的引导参数:

1

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"

AMD CPU使用下面的引导参数:

1

GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on"

特别注意，如果你的网卡是PCIE转接的网卡，请多增加一个参数： 我的主机CPU是J4125,参数如下

1

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on pcie_port_pm=off"

之后，更新grub配置文件

1

update-grub

增加内核模块

1

nano /etc/modules

在modules文件中增加如下内容:

1
2
3

vfio
vfio_iommu_type1
vfio_pci

pve8.0以上版本不需要vfio_virqfd这个模块，因为模块目录压根就没有！！！

更新 initramfs 归档文件

1

update-initramfs -k -u all

重启pve

1

reboot

验证IOMMU是否开启

1

dmesg | grep -e DMAR -e IOMMU

会看到

1

DMAR: IOMMU ENABLED

可以新增虚拟机了，分配PCI设备，开机！

USB硬盘的直通，PVE确实很方便，直接qm disk set就可以了。

如果你觉得local-lvm 和 lvm 两个分区容易造成空间浪费，可以合并成一个

  1. 备份虚拟机
  2. 删除虚拟机
  3. 删除local-lvm: lvremove pve/data
  4. 把local-lvm空间分配给Local:
1
2

lvextend -l +100%FREE -r pve/root
resize2fs /dev/mapper/pve-root
  1. 删除local-lvm: 网页登陆，数据中心-存储-删除local-lvm
  2. 编辑local，内容里添加 磁盘映像和容器，保存
  3. 恢复虚拟机
]]>