From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <010701a0fd8b38a5-970cf8c7-2955-41de-a1f2-b0b0994d7d1f-000000@eu-central-1.amazonses.com> Received: from AM0PR83CU005.outbound.protection.outlook.com (mail-westeuropeazon11020102.outbound.protection.outlook.com [52.101.69.102]) by lore.virtuozzo.com (Postfix) with ESMTPS id 9C3B0802A7 for ; Fri, 2 Oct 2026 16:56:00 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vL8tZCjt7q542tQMJl05KS5KaPwnVTfiIO7Bl7AqphfizB3HwA9f4csEscaDawto5ST40jBlHbuTInvo3v3MiwK7IVHpeNCh2XyOOsSWRUSWWZKXTEkW0bjsfaQgA2S3Zltego7PnN/VCYnom/vyxZl6DqbsecF54OuHHjRrCPofPk6PnQaST725uUdTtGEdV+2vz3cVOJLIr5BrYGPO1JYUiewIAEPosG7zQUp51tN5fIPIBmN3OKWfRPc5WBgLZg/CdnepoVgm6ztky+y61BFoA89gkpMoaP5a1v/qmAj6X6B/rM6d0JWI8/G5FM6+m4Zz8IsZmuppkaBHVlMXAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+gMlUFS46JquoiNYHhmdMqRjampAF/sq57/m0MTXvzo=; b=gjpDTHUnj0f4m3jcEqxCYYQB+Byj8IaE4w9L7ecFG4BNow56zqJ5VfQ/doKWen7sfOpDGTtuf3I+Ij4KOjpvGF7nj2gqQGj3nyPPzbnVJP7Ke2JQI/8mPRW2iEJF/Gbl5fgcZU72s+I+e7AJPZzYBWwQF7SGSywBeX68tcMeN0iTRtcldKWFWU4mrpguf2eJGz0l2ZmYjk0VArreTuQ9EvibMy9lsZt62U/7bTUz7TkURXZDR0PUvR/F4ABqYImVUrCMpwkJznFNWkjwKw3tVboO+YRXmAy2+9lFRexlpcnRto2X/A0z70zwvq6YlY3DhDaM1wk9CXJficV5OL85NA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 69.169.224.1) smtp.rcpttodomain=virtuozzo.com smtp.mailfrom=eu-central-1.amazonses.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com; dkim=pass (signature was verified) header.d=amazonses.com; arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.onmicrosoft.com; s=selector2-virtuozzo-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+gMlUFS46JquoiNYHhmdMqRjampAF/sq57/m0MTXvzo=; b=EGORUz15+v9XV3JVCGN9WPuBTUgo97YwBCc1k4kC0A/DwHutPC4cQObZK3DTN9CUDw4xzlKgqWN8v4tn/GzJohJCxNQM00ix2q4ACHrjbSzNm0JKaVK3gH/Dnmmq5Y8Ln8EetoVsP18BkBnxtQACzTnzOfeQBbCYgzgFY45dl1s= Received: from PAYP264CA0018.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:11e::23) by AS2PR08MB10055.eurprd08.prod.outlook.com (2603:10a6:20b:645::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.496.13; Fri, 2 Oct 2026 16:55:55 +0000 Received: from MI3PEPF0000848A.eurprd02.prod.outlook.com (2603:10a6:102:11e:cafe::3f) by PAYP264CA0018.outlook.office365.com (2603:10a6:102:11e::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.19 via Frontend Transport; Fri, 2 Oct 2026 16:55:55 +0000 Authentication-Results: mx.microsoft.com 1; spf=pass (sender IP is 69.169.224.1) smtp.mailfrom=eu-central-1.amazonses.com; dkim=pass (signature was verified) header.d=sashiko.virtuozzo.com;dkim=pass (signature was verified) header.d=amazonses.com;dmarc=pass action=none header.from=sashiko.virtuozzo.com; Received-SPF: Pass (protection.outlook.com: domain of eu-central-1.amazonses.com designates 69.169.224.1 as permitted sender) receiver=protection.outlook.com; client-ip=69.169.224.1; helo=b224-1.smtp-out.eu-central-1.amazonses.com; pr=C Received: from b224-1.smtp-out.eu-central-1.amazonses.com (69.169.224.1) by MI3PEPF0000848A.mail.protection.outlook.com (10.167.240.137) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.472.14 via Frontend Transport; Fri, 2 Oct 2026 16:55:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=23yjbh4k34hwzfubhuiim7m4inbd3ick; d=sashiko.virtuozzo.com; t=1790960155; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID; bh=TH+R80/rF7EtER9TAxHNlNwSIAjubLogXCdqPMU4vHo=; b=dBqS833siJwmBit4l/xx2EkhPJfYekHz6BLqEFBEqzwBe5lOsoInJ1ggvb33Iiq1 SL4E/5HDw4QfeRzSFZtrHaOmUMfKLIEqSG8FZ4+EsZ9Wob+3AIACz5sTEo2Xyg6hr63 t3Rk+0+fiT/KcmQEX6TRchKtsC8yVqwL6ejmWXqH0eKzxMP9QMqr+hIF3q5VxItYn6f U3NOKj0QZtjSuPzz+ziwj9NbTVOvGEZUSKbX5Z4rhYzK6TWbLv8xdoi156/DzbT0Fng XM1Yp4pNvCrsHvkjhs36N3U5oAk9JgcVfLcVmzsfWh3ub54cyBYlCLATcVtQWROGxWz gSVVwgNzsw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=sokbgaaqhfgd6qjht2wmdajpuuanpimv; d=amazonses.com; t=1790960155; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date:Message-ID:Feedback-ID; bh=TH+R80/rF7EtER9TAxHNlNwSIAjubLogXCdqPMU4vHo=; b=CBnerVgdu9yWOMasPA/sh9t6TQw5HF7sTw6Gc8zUQ012x4P/zDhJskvuQ8GWVlkW z+XICsOdy3sMmMBqLacz6Ao+F8M+/Ar6G9R4Az4/oHT8xIibvLrPcsTUVfSVjreM4dQ dhl3uesFkvE9v3m9a2X9Wo/BwKJ7KoHVwEJQGsSU= From: no-reply@sashiko.virtuozzo.com Subject: Re: [PATCH 3/3] iotests/migrate-cpr-exec: cover chardevs with logfile= #VSTOR-148304 To: "Denis V. Lunev" , svt-core@virtuozzo.com Cc: andrey.drobyshev@virtuozzo.com, den@virtuozzo.com In-Reply-To: <20261002164853.2130337-4-den@openvz.org> References: <20261002164853.2130337-1-den@openvz.org> <20261002164853.2130337-4-den@openvz.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Oct 2026 16:55:54 +0000 Message-ID: <010701a0fd8b38a5-970cf8c7-2955-41de-a1f2-b0b0994d7d1f-000000@eu-central-1.amazonses.com> Feedback-ID: ::1.eu-central-1.2wRQJBpg9g1fGRYexx3dUuYGS25Bux+2TEOx72/m6U4=:AmazonSES X-SES-Outgoing: 2026.10.02-69.169.224.1 X-EOPAttributedMessage: 0 X-EOPTenantAttributedMessage: 0bc7f26d-0264-416e-a6fc-8352af79c58f:0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MI3PEPF0000848A:EE_|AS2PR08MB10055:EE_ MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 691d81de-f050-46ea-f1ad-08df20a60662 X-LD-Processed: 0bc7f26d-0264-416e-a6fc-8352af79c58f,ExtAddr X-MS-Exchange-AtpMessageProperties: SA List-Id: svt-core@virtuozzo.com X-MS-Exchange-Transport-Rules-Loop: 1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|704161211799003|32142699015|61400799027|48200799018|376014|9140799003|22082099003|16102099003|18002099003|55112099003|13003099007|4143699003|10067099003|5063699009|5023799004|56012099006|4113699003|5113699003; X-Microsoft-Antispam-Message-Info: Nn3Ny6qLoU+hn+x4iq/VlJOe6QluyuX+PrhQ8lB82rcC3DazeW1oiNiWUGSmymXTEQwE4+H7Iv+iEtuHGs58nt9XivU0X8GM6fdY8JSUMQiJtvIzHk9vkGA1HYKo+Ms86UF1t0d8KdyZa0qYdGJa48TqIUTPm954vwGlOnyBNmdGawgWbyr+Qls7A+zKljOTT+iQxt/EEHpwRPx3qBwq3wN0QScR8siUIDPfqTahZdH5CJhTnHBhbqaSOGb/Ge7mHuPqGjbI1fU5zQwMifHCbcgyJxTUjKFlp2G/FgObn3FYgoc0AD2FXFIhQI8k7ly/wRvg0zErbRBarc7IHVhHDqjAtffO/UiyFEu7bSf66tHdkITYizLECyE7aDdfhIDxKX2ObpZuVIg2yI960z87WVSpVsYKn8ZwcqXJkg7w7NPuE1tbbiGcDXV7gBuFqmOYTKPbFudlRVwVBItZGDj42gKmhuL3PgC5f21uJwtINCl5GRl1O3J15hT1G8l17VZ3syWu5Pa9YWvx3mPG2KAPGXM0DFgMqDzuIM9I3wlyTso5AhBnvcRSRsMD8q9tV1ucgxTf+jGSRGe3Wv9+ydVkB3y1vcNFfb1/bw31blFsO8eZkCZRcajmkpiCavIuhwZTxR+Mu4K+liHR6ZvTfJsNDiWfp58+ZyIY7vDcdemgeF0MPuAzpYhQ+I1zCnjfDEFjVUZcpTroQT2rdbVgN5Ps/E1JpD7UGJh/JgjF4/G07jho70Y3+KIMeJAVbF7QWGIhVu2GnYnhzMsk0DZl/afPyiKWAWji77KVWdRpU0QwdkZfvggyWjetgxOGu+Exqo1eDJx5oCx83WtpesRiM9NnDV5d7BjNEiZYY9zXLeKjouP7lxkKovyXHWsxdYz8puZoox+eVEXds/xrYxkGiF4kkZiXu6JPmPfYrUhNoZyqgFODWwp2GZb3qvd7njO/a1gY X-Forefront-Antispam-Report: CIP:69.169.224.1;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:b224-1.smtp-out.eu-central-1.amazonses.com;PTR:b224-1.smtp-out.eu-central-1.amazonses.com;CAT:NONE;SFS:(13230040)(704161211799003)(32142699015)(61400799027)(48200799018)(376014)(9140799003)(22082099003)(16102099003)(18002099003)(55112099003)(13003099007)(4143699003)(10067099003)(5063699009)(5023799004)(56012099006)(4113699003)(5113699003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: pMAl8rDduKjqzRR0egvSQdv0ouOsP9pJfXYB0tCrcrd9SRx6arcd/vWKtFsAvWXdu9wLfY9pGlo+cGhGZ47u2ZQCxhqMmcHUPCLf+o1eDYr+6YM4Dloo/ww5wV03NKVjrSez+jtx8ECXySWtPxUo6S3oIoqviiBRHx3+z7n5pTEP1gJMiSZfH8NtWd4YUYCF5mRSQNnaJTFSX64SCPU1Z81HB79O+K4gmbGmIrl59kn3aBGzeukvifg13nuc+sFfxqYNcROJpDmb5CUAhh3BVzhxq0GKru5opM2Ll/grCGCwffcYPd/ZawteQ2t0dD1GRYz2KDm7fvtnqJUGGkn7FVDqqBo+WH9ChD0mllU3Us8z2zOQF09gByRJEfuG41q3UBEKXEhWlSPA79nxglHzNAOnTMrXcuXcHSbfgbqeU6Q67MzpFUhGd5CK3f7bMUxP X-ExternalRecipientOutboundConnectors: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Oct 2026 16:55:55.3030 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 691d81de-f050-46ea-f1ad-08df20a60662 X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-AuthSource: MI3PEPF0000848A.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB10055 Thank you for your contribution! Sashiko AI review found 4 potential issue(= s) to consider: - [Low] iotests: socket logfile test leaves stale path=3Dsock1 in exec comm= and line - [Low] iotests: assertFalse on BAD_LOG parent dir cannot detect an attempt= ed logfile open - [Low] iotests: _open_files() compares /proc readlink results to non-canon= ical paths - [Low] iotests: pre_cpr rewrite drops logappend=3Don from the console char= dev argument -- commit 8a854fc4d41646d884346abb08e5af9be8f46b16 Author: Denis V. Lunev iotests/migrate-cpr-exec: cover chardevs with logfile=3D #VSTOR-148304 This adds four tests to migrate-cpr-exec. They cover a pty console, a guest agent socket and a second QMP monitor, each with a log, through cpr-exec with logfile paths that cannot be created. They also cover chardev-change to a new log for pty and socket, and a failed chardev-change whose rollback must keep the old log. > diff --git a/tests/qemu-iotests/tests/migrate-cpr-exec b/tests/qemu-iotes= ts/tests/migrate-cpr-exec > index 51e6cbcd6593..e8a6c502c840 100755 > --- a/tests/qemu-iotests/tests/migrate-cpr-exec > +++ b/tests/qemu-iotests/tests/migrate-cpr-exec [ ... ] > + def _open_files(self) -> set: > + fd_dir =3D f'/proc/{self.vm.get_pid()}/fd' > + return {os.readlink(os.path.join(fd_dir, fd)) > + for fd in os.listdir(fd_dir)} [Severity: Low] Can this comparison fail when TEST_DIR is not canonical? os.readlink() on /proc//fd/N returns the kernel's resolved path. The expected paths come from _log_path() as os.path.join(iotests.test_dir, name= ), and they are not passed through os.path.realpath(). If TEST_DIR is reached through a symlink, this assertion fails even though the fds were preserved: self.assertLessEqual({agent_log, mon_log}, self._open_files()) In the same case, this assertion in _test_chardev_change_logfile() passes vacuously, so it no longer checks that the old log fd was dropped: self.assertNotIn(log_old, self._open_files()) I did not confirm how iotests normalizes test_dir. Would applying os.path.realpath() to the expected paths avoid the mismatch? [ ... ] > + def pre_cpr(): > + self._serial_write('before\n') > + for c in (console, agent, mon): > + self._replace_arg(c, c.replace(c[c.index('logfile=3D'):], > + f'logfile=3D{self.BAD_LOG= }')) [Severity: Low] Does this rewrite drop logappend=3Don from the console chardev argument? For the console chardev, c[c.index('logfile=3D'):] is 'logfile=3D/dev/fdset/1,logappend=3Don'. The whole tail is replaced, so the= new argument becomes: pty,id=3Dcharserial0,logfile=3D The agent and mon arguments have logfile=3D last, so they are unaffected. The combination of logappend=3Don with an fd-backed preserved log is therefore not exercised after the exec. This is the combination the commit message says libvirt sends. Today qemu_char_open() does not use the computed flags when cpr_exec_is_incoming() is true, so the test passes. A later change that consults logappend on the restore path would not be caught. Would it be better to replace only the path value and keep ",logappend=3Don= "? > + args =3D list(self.vm._qemu_full_args) > + i =3D args.index('-add-fd') > + self.vm._qemu_full_args =3D tuple(args[:i] + args[i + 2:]) > + > + def post_cpr(): > + self._serial_write('after\n') > + self.assertEqual(self._read(console_log), 'before\nafter\n') > + self.assertLessEqual({agent_log, mon_log}, self._open_files(= )) > + self.assertFalse(os.path.exists(os.path.dirname(self.BAD_LOG= ))) [Severity: Low] Can this assertion ever fail? BAD_LOG is /nonexistent/chr.log, and nothing creates the "nonexistent" directory. qemu_create() called from qemu_char_open() does not create parent directories. If a regressed QEMU tried to open the path, it would get ENOENT and the directory would stay absent, so assertFalse(os.path.exists(os.path.dirname(self.BAD_LOG))) always holds. The real evidence that the path is not opened is that the new QEMU starts at all. The docstring ("the new logfile=3D paths are never opened") and the commit message suggest this assertion adds coverage that it does not. Could the assertion be dropped, or replaced with a check that can actually fail? [ ... ] > + def test_chardev_change_logfile_socket(self) -> None: > + sock1 =3D iotests.file_path('chr-log-sock1') > + sock2 =3D iotests.file_path('chr-log-sock2') > + self._test_chardev_change_logfile( > + 'socket', > + {'addr': {'type': 'unix', 'data': {'path': sock2}}, > + 'server': True, 'wait': False}, > + f'path=3D{sock1},server=3Don,wait=3Doff,') [Severity: Low] This isn't a bug, but the rewritten exec command line for the socket case looks inconsistent with the live chardev. In _test_chardev_change_logfile(), change() calls: self._replace_arg(arg, f'{backend},id=3Dchar0,{opts_old}' f'logfile=3D{self.BAD_LOG}') For the socket case opts_old is 'path=3D,server=3Don,wait=3Doff,'. A= fter chardev-change the live chardev listens on sock2, so the new command line still names sock1, which is no longer in use. The existing test_chardev_change_socket_to_socket updates the path to sock2. The test passes here because chr_socket_cpr_restore_addr_fd() in chardev/char-socket.c uses the inherited fd and not the path. As written, the test does not model what a management layer would send. It would also not catch a regression that used the path instead of the fd. Should the rewritten argument use sock2 for the path? [ ... ] --=20 Sashiko AI review =C2=B7 https://sashiko.vzint.dev/#/patchset/2026100216485= 3.2130337-1-den@openvz.org?part=3D3