Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

disk_utils: new functions provider #4219

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mcasquer
Copy link
Contributor

@mcasquer mcasquer commented Nov 26, 2024

disk_utils: new functions provider

Creates a new file containing a set of functions
useful for managing disks and filesystems in guest
environments

Signed-off-by: mcasquer mcasquer@redhat.com
ID: 3118

@mcasquer mcasquer force-pushed the 3118_new_disk_functions_provider branch from a9a7080 to b126ffe Compare November 26, 2024 13:55
@mcasquer mcasquer marked this pull request as ready for review November 26, 2024 13:57
@mcasquer
Copy link
Contributor Author

@qingwangrh please, could you help reviewing this PR? Thanks !

guest_cmd = guest_cmd.format(output_path)

session.cmd(guest_cmd)
vm.reboot()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@qingwangrh I've tried many things after the reboot but it always complains about: Shell process terminated while waiting for command to complete
I am not sure if either the file doesn't exist or the the command is not working, do you have any suggestion here? I tried with a single dir {output_path}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the file check as first, it doesn't belong to the intention of this provider and second, it is not really needed if the dd command succeeds
FYI @qingwangrh

@mcasquer mcasquer force-pushed the 3118_new_disk_functions_provider branch 3 times, most recently from ee6ef9a to 997fc06 Compare November 27, 2024 09:03
idx_info = get_disk_props_by_serial_number(session, serial, ["Index"])
if idx_info:
return idx_info["Index"]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest adding a function like get_disk_by_id or get_disk_by_serial. The ID may be the serial/www/device ID. It may handle different OSs. for windows it return disk idx, for linux , it return disk name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@qingwangrh done!

if idx_info:
return idx_info["Index"]


Copy link
Contributor

@qingwangrh qingwangrh Nov 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

after the first function is ready, We can provide more functional encapsulation. like as
fake code:
init_disk_by_id(mountpoint=“1“,fstype=none):
“”“
mountpoint:
0 :it does not need mount

  1. auto select the mountpoint
    other: user specify the mountpoint

“”“
id=get_disk_by_id
if not fstype:
fstype= ntfs if windows else xfs
format_disk_with_fstype
mount disk->mountpoint
return mountpoint

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@qingwangrh done!

return guest_cmd


def guest_fs_mount_and_dd_cmd(os_type, tmp_dir):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same thinking. we may consider more powerful encapsulation, like as

execute_cmd_on_disk_by_id():
drv= init_disk_by_id
cmd=xxxxx
session_cmd ()

the utils provide different granularity functions, most cases may use execute_cmd_on_disk_by_id directly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@qingwangrh
Just one comment here, we may want to directly execute the command? or just return it? Because execution could be done on the test side e.g. after rebooting the VM and renewing the session

Copy link
Contributor

@qingwangrh qingwangrh Nov 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the session and cmd as parameters, it could have two functions, 1 hardcode execute dd 2. execute cmd come from parameter.
I prefer the function 2. based on the function 2 , you may wrap the function 1
.

@mcasquer mcasquer force-pushed the 3118_new_disk_functions_provider branch from 997fc06 to f126ecf Compare November 29, 2024 07:00
@mcasquer
Copy link
Contributor Author

@qingwangrh pleasae could you review again this PR? Thanks !

@mcasquer
Copy link
Contributor Author

mcasquer commented Dec 5, 2024

This is a kindly reminder, @qingwangrh please could you review again this PR? Thanks !

@mcasquer
Copy link
Contributor Author

mcasquer commented Dec 5, 2024

@yanan-fu and @YongxueHong could you also help reviewing this PR? Thanks !

session.cmd(cmd)


def execute_cmd_on_disk_by_id(params, disk_id, session, tmp_dir):
Copy link
Contributor

@qingwangrh qingwangrh Dec 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this function hardcodes dd cmd, so I suggest to change the name to execute_dd_on_disk_by_id.
this function may cover the most user cases.

Copy link
Contributor

@qingwangrh qingwangrh Dec 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And could you please add a new execute_cmd_on_disk_by_id(params, disk_id, session, cmd) to support user defined cmd ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@qingwangrh renamed the existing function and added a new one

tmp_dir=tmp_dir,
)
if os_type == "windows":
cmd = "dd if=/dev/urandom of={}:\\test.dat bs=1M count=10"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

count=10 ->count=100 to keep consistency with linux.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@qingwangrh updated !

session.cmd(cmd)


def execute_cmd_on_disk_by_id(params, disk_id, session, tmp_dir):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

parameter change to (params, disk_id, session, tmp_dir=None): most user they do not need to care the tmp_dir

the implementation may help to do the following:
if not tmp_dir:
tmp_dir="/var/tmp/"+disk_id

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@qingwangrh updated !

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mcasquer mcasquer force-pushed the 3118_new_disk_functions_provider branch from f126ecf to 41c59b2 Compare December 10, 2024 10:21
@mcasquer
Copy link
Contributor Author

We're approaching to the end of the quarter... again a kindly reminder, @yanan-fu @YongxueHong could you help reviewing this PR? Thanks !

from virttest.utils_windows.drive import get_disk_props_by_serial_number


def get_disk_by_id(os_type, disk_id, session):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
def get_disk_by_id(os_type, disk_id, session):
def get_disk_by_id(vm, os_type, disk_id):

From my understanding, we want to provde an interface of VM for the user, so I suggest that we could specify the scope with the vm argument, and then get the session object by the interface wait_for_login of the vm object inside the function.
Pls let me know your thougths.
Thanks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mcasquer
I am a bit confused about the definition of the disk object by calling get_disk_by_id.
How do you define it? I think we are better to clarify what kind of information the user will get with the naming of the function. The concept disk of get_disk_by_id compares with it returns is a bit of generalization
Here, we can get the disk index inside Windows guest, and the disk path inside Linux guest.
So I think we could figure out and abstract out a name to represent such return value, for example: get_disk_xxxx_by_id to let the users know how and where they can call it instead of reading the code to get to know which information they will get.
Feel free to share your thoughts. Thank you!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@YongxueHong what about get_disk_reference_by_id() ?

return utils_disk.configure_empty_disk(session, disk, img_size, "windows")[0]


def mount_disk(disk, session, tmp_dir):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like it does not support the Windows guest session.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@YongxueHong sorry because I am not aware of the difference, what changes if the session instance belongs to a Windows guest?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@YongxueHong sorry because I am not aware of the difference, what changes if the session instance belongs to a Windows guest?

Hi @mcasquer
From my understanding, if the session belongs to a Windows guest, the command mkdir -p {tmp_dir} && mount -t xfs {{0}} {tmp_dir} cannot be executed within the Windows environment. This is because the Windows operating system does not support the mkdir and mount commands in the same way as Linux, where these commands are natively supported. Please let me know if I misunderstood or if there are additional details to consider. Thanks!

:param img_size: The size of the image to be configured in Windows.
:param session: The guest session.
"""
if fstype == "xfs":
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For Linux, there are several fs type it support, such as ext3, ext4, Btrfs, and others.
Do we just cover the xfs fs type? I suggest raising an error to let the user know we do not support other types besides xfs.

return driver


def format_disk_by_fstype(disk, fstype, img_size, session):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mcasquer
Could you explain more about the purpose?
From your code, I see the different behaviors between Linux guest and Window guest.
Thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, disk formatting is needed if we want to access to the disk inside the guest, please @qingwangrh correct me if I am wrong

session.cmd(f"umount {tmp_dir}")


def execute_cmd_on_disk_by_id(params, disk_id, session, cmd, tmp_dir=None):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mcasquer
Could you provide more information about it?
Which scenario do you want to apply?
Thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function won't be used right now, but the idea is for the users to execute a command that applies to the specific guest disk, cc @qingwangrh

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function won't be used right now, but the idea is for the users to execute a command that applies to the specific guest disk, cc @qingwangrh

Thanks for your explanation.
I suggest not adding it at this moment as there is no such place to call it, we could add it when we really need it.
The reason is that we need to collect the requirement for the interface and then we could design it well in order to satisfy the user's scenarios.
Please let me know your opinion.
Thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@YongxueHong I agree with you :) removing it

session.cmd(cmd)


def execute_dd_on_disk_by_id(params, disk_id, session, tmp_dir=None):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like not only executes the dd command but also other jobs, like mount and umount here, but the name of the function mainly focuses on executing the dd command by the user's requirement, I think.
From my perspective, we just execute the dd command, not provide to customize the dd option for the user.

And we should make sure this function is the common interface as the provider module if we really want to create it.
Hi @mcasquer
Would you help to explain the reason for this function?
Thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@YongxueHong here are all the steps needed to execute a dd command on a specific guest disk. If the function only does the dd it shouldn't be necessary because it will be the same as session.cmd("dd ...") so that's the reason of the function. I will add more info in the docstring, please @qingwangrh correct me if I am wrong

@YongxueHong
Copy link
Contributor

Hi @peixiu @menli820 @fbq815 @maxujun
Would you like to help to review it?
Thanks a lot.

@YongxueHong
Copy link
Contributor

Hi @mcasquer
Would you like to help to refine the docstring for each function? even each parameter?
Thanks a lot.

from virttest.utils_windows.drive import get_disk_props_by_serial_number


def get_disk_by_id(os_type, disk_id, session):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest use the same way to get os_type, os_type = params["os_type"]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maxujun so are you suggesting to obtain the os_type inside the function by os_type = params["os_type"] ?
if that's true, receiving the params as an argument will be needed so I think the current approach is easier, am I missing something?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, need params. It's ok too by os_type paramete.

from virttest.utils_windows.drive import get_disk_props_by_serial_number


def get_disk_by_id(os_type, disk_id, session):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest use the same way to get os_type, os_type = params["os_type"]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maxujun Same question as the comment above

def init_disk_by_id(
mount_point="1",
fstype=None,
os_type="linux",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest use the same way to get os_type, os_type = params["os_type"]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maxujun Same question as the comment above

return driver


def format_disk_by_fstype(disk, fstype, img_size, session):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest set default value None for img_size.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would agree with that, but that makes necessary to define the session too as it's the next argument, so which will be the main benefit of applying this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK for me now.

@mcasquer mcasquer force-pushed the 3118_new_disk_functions_provider branch from 41c59b2 to 9a9bfd3 Compare January 9, 2025 12:33
@mcasquer
Copy link
Contributor Author

mcasquer commented Jan 9, 2025

Would you like to help to refine the docstring for each function? even each parameter?
Thanks a lot.

@YongxueHong I updated the entire provider script, please feel free to review it again, docstrings have been properly formatted and some code refactored :)

@mcasquer
Copy link
Contributor Author

mcasquer commented Jan 9, 2025

Test cases passed with latest provider

 (1/2) Host_RHEL.m9.u6.ovmf.qcow2.virtio_blk.up.virtio_net.Guest.RHEL.9.6.0.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: STARTED
 (1/2) Host_RHEL.m9.u6.ovmf.qcow2.virtio_blk.up.virtio_net.Guest.RHEL.9.6.0.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: PASS (92.05 s)
 (2/2) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.RHEL.9.6.0.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: STARTED
 (2/2) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.RHEL.9.6.0.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: PASS (92.17 s)
RESULTS    : PASS 2 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0

@peixiu
Copy link
Contributor

peixiu commented Jan 14, 2025

@mcasquer Do we have any windows cases called these new functions? I can help to run them~

Thanks!
Peixiu

@mcasquer
Copy link
Contributor Author

@mcasquer Do we have any windows cases called these new functions? I can help to run them~

@peixiu Sure! See the related patch #4209 you should be able to run the test case in Win11 guest :)

Comment on lines 66 to 76
def creates_xfs_filesystem(device, session):
"""
This function creates the XFS filesystem on the received device.

:param device: The device used to create the filesystem.
:param session: The Linux guest session.
"""
cmd = "mkfs.xfs -f {0}"
cmd = cmd.format(device)
session.cmd(cmd)
return device
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mcasquer
I noticed that there is already a similar function available in the Avocado-VT repository, specifically def create_filesyetem_linux(session, partition_name, fstype, timeout=360).

Could you please share the reasoning behind adding this function in the tp-qemu repository, considering the existing functionality?

Thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmm I wasn't aware of the existence of this function, replaced !

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ps: this functiom from avocado-vt has a typo in the name, I will send a small patch for fixing it once this gets merged

Comment on lines 102 to 104
cmd = f"mkdir -p {tmp_dir} && mount -t xfs {{0}} {tmp_dir}"
cmd = cmd.format(disk)
session.cmd(cmd)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mcasquer
Actually, there is a similar function https://github.com/avocado-framework/avocado-vt/blob/0812d4d400da2b99d7610e5ebc154870fda4fab5/virttest/utils_disk.py#L109 and it looks like support more options.
I see you just added the step for creating a directory as the mount point, it will be cleaned up automatically if it is a temporary directory, but we have to clean up it without this function if it is not a temporary directory.
We can not ensure each user wants a temporary directory for testing.
So I think it's a bit unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fully agree, replaced with the existing function

session.cmd(cmd)


def execute_dd_on_disk_by_id(params, disk_id, session, tmp_dir=None, test=None):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mcasquer
I can see that this function execute_dd_on_disk_by_id is you really want, you want to create a dd test function for tp-qemu test case. Indeed, you do not need to do the above function, from my side, we just keep this function execute_dd_on_disk_by_id for the test case with the existing functions the framework provided to implement.
If there are places that need the others' function, we can create them later.
Please feel free to let me know your opinions.
Thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated, thanks @YongxueHong

@YongxueHong
Copy link
Contributor

Hi @mcasquer
I suggest modifying the module name with disk_utils to keep the consistency with other modules.
Thanks.

@mcasquer mcasquer force-pushed the 3118_new_disk_functions_provider branch from 9a9bfd3 to e6d645b Compare January 19, 2025 23:22
@mcasquer mcasquer changed the title disk_utilities: new functions provider disk_utils: new functions provider Jan 19, 2025
@mcasquer
Copy link
Contributor Author

Hi @mcasquer I suggest modifying the module name with disk_utils to keep the consistency with other modules. Thanks.

@YongxueHong done !

@mcasquer mcasquer force-pushed the 3118_new_disk_functions_provider branch from e6d645b to b019ebc Compare January 23, 2025 12:03
@mcasquer
Copy link
Contributor Author

@YongxueHong could you review again this PR? Thanks !

@peixiu
Copy link
Contributor

peixiu commented Jan 23, 2025

Hi @mcasquer , I tried to test this patch + #4209

Job failed with error " Shell command failed: 'mkdir -p /var/tmp/test' (status: 1, output: 'The syntax of the command is incorrect.\n\n') "

python3 ConfigTest.py --testcase=block_disk_not_default_options --guestname=Win10,Win11,Win2025 --platform=x86_64 --clone=no --machines=q35

(1/3) Host_RHEL.m9.u*.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win10.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: STARTED
(1/3) Host_RHEL.m9.u*.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win10.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: ERROR: Shell command failed: 'mkdir -p /var/tmp/test' (status: 1, output: 'The syntax of the command is incorrect.\n\n') (110.08 s)
(2/3) Host_RHEL.m9.u*.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win11.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: STARTED
(2/3) Host_RHEL.m9.u*.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win11.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: ERROR: Shell command failed: 'mkdir -p /var/tmp/test' (status: 1, output: 'The syntax of the command is incorrect.\n\n') (110.85 s)
(3/3) Host_RHEL.m9.u*.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: STARTED
(3/3) Host_RHEL.m9.u*.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: ERROR: Shell command failed: 'mkdir -p /var/tmp/test' (status: 1, output: 'The syntax of the command is incorrect.\n\n') (130.33 s)

@mcasquer mcasquer force-pushed the 3118_new_disk_functions_provider branch 2 times, most recently from 1fceb75 to 15028f9 Compare January 24, 2025 08:59
@mcasquer
Copy link
Contributor Author

Hello @peixiu I've updated the code in both places, could you test it again ? Thanks

@peixiu
Copy link
Contributor

peixiu commented Jan 24, 2025

Hello @peixiu I've updated the code in both places, could you test it again ? Thanks

Hi @mcasquer I retested the case with the latest codes, also hit the same error!
"mkdir /var/tmp/test" is not sutiable on the windows guests!

python3 ConfigTest.py --testcase=block_disk_not_default_options --guestname=Win11,Win2025 --platform=x86_64 --clone=no --machines=q35

(1/2) Host_RHEL.m*.u0.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win11.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: STARTED
(1/2) Host_RHEL.m*.u0.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win11.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: ERROR: Shell command failed: 'mkdir /var/tmp/test' (status: 1, output: 'The syntax of the command is incorrect.\n\n') (93.51 s)
(2/2) Host_RHEL.m*.u0.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: STARTED
(2/2) Host_RHEL.m*.u0.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: ERROR: Shell command failed: 'mkdir /var/tmp/test' (status: 1, output: 'The syntax of the command is incorrect.\n\n') (243.11 s)

Creates a new file containing a set of functions
useful for managing disks and filesystems in guest
environments

Signed-off-by: mcasquer <mcasquer@redhat.com>
@mcasquer mcasquer force-pushed the 3118_new_disk_functions_provider branch from 15028f9 to 7e4c2ad Compare January 27, 2025 10:53
@mcasquer
Copy link
Contributor Author

Test case passed with latest code on Win11 and Win2025 guests

 (1/4) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win11.x86_64.io-github-autotest-qemu.unattended_install.cdrom.extra_cdrom_ks.default_install.aio_threads.q35: STARTED
 (1/4) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win11.x86_64.io-github-autotest-qemu.unattended_install.cdrom.extra_cdrom_ks.default_install.aio_threads.q35: PASS (4178.23 s)
 (2/4) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.unattended_install.cdrom.extra_cdrom_ks.default_install.aio_threads.q35: STARTED
 (2/4) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.unattended_install.cdrom.extra_cdrom_ks.default_install.aio_threads.q35: PASS (4159.05 s)
 (3/4) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win11.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: STARTED
 (3/4) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win11.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: PASS (267.22 s)
 (4/4) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: STARTED
 (4/4) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.block_disk_not_default_options.with_packed_and_ppv.q35: PASS (304.00 s)
RESULTS    : PASS 4 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants