Description of problem:
The disk which the OS is in is destroyed by not becoming an error when the host
OS is installed in an specified disk.
Version-Release number of selected component (if applicable):
Because, there is only a check to judge whether specified --file operand is a file,
It adds a check to judge whether specified --file operand is a disk.
Steps to Reproduce:
1. add a check to judge whether specified --file operand is a disk to get_disk()
The disk which the OS is in is destroyed by not becoming an error.
When the disk which the OS is in is specified, becoming an error.
Because content to fill out XX and YY is wrong, I revise it. It is as follows to
always :When it specified disk which the OS is in
Steps to Reproduce:
1. it specified disk which the OS is in to an operand of
I do not understand the bug report. Please clarify:
- "The disk which the OS is in" does taht mean a file, a CDROM, a partition ?
- "when the host OS is installed in an specified disk", what disk ?
you mention two disks, are they the same ?
Why is the bug assigned to libvirt if you suggest to fix virt-install ?
With respect to comment #1:
- what is XX what is YY ?
- I do not understand the step to reproduce, provide a *full* information
or explain better what is the matter with passing --file=/dev/sda
As such the bug is not understandable to me, sorry !
Sorry, Shigeki made several mistake.
This is a full information of steps to reproduce:
1. Confirm the device name and the partition mounted by host OS.
in this case, "/dev/sda1" and "/dev/sda2" is mounted,
and device name is "/dev/sda"
# df -kh
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 23G 4.4G 18G 20% /
/dev/sda1 99M 26M 69M 28% /boot
tmpfs 467M 12K 467M 1% /dev/shm
2. Create a guest OS by specifying the device name.
(i.e. "/dev/sda", not "/dev/sda1" or "/dev/sda2")
# virt-install --name=test --ram=256 --hvm --cdrom=/dev/cdrom --file=/dev/sda
3. The host OS will be destroyed because a system file is compulsorily
> - "The disk which the OS is in" does taht mean a file, a CDROM, a
that disk means device name that specified with virt-install as --file option.
> - "when the host OS is installed in an specified disk", what disk ?
that disk means device name that mounted by host OS.
> Why is the bug assigned to libvirt if you suggest to fix virt-install ?
yes, you are right. I changed the component from libivrt to python-virtinst.
> With respect to comment #1:
> - what is XX what is YY ?
that is his mistake, sorry.
Hum, sure such a check could be aded, but in general the UNIX philosophy is that
if you run as root (and that command runs as root) and you mess up with files
well, you get to clean up the mess. Famous example includes '# rm -rf /' but
in your case if you were typing
# cat /dev/zero > /dev/sda
then again you will trash your data. And the shell won't protect you. Basically
command like virt-install, which are to be run as root, cannot be made completely
fool-proof, and such access and permissions should never be granted to a normal
Maybe a test can be added, but in general trying to foolproof full root access
system tools like this is just impossible.
I think that what is not checked at all is bad.
Surely, it may be impossible to make foolproof,
but it should give the warning at least.
The one is user-friendly.
Created attachment 228301 [details]
Add the check of the disk like the check of the file, and warning is output.
I make the patch which improved this problem.
I attach it.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
The patch which I showed is inappropriate.
It only prevent only a part of range and,
It is illogical because it lose usability by giving warning every time.
> Basically command like virt-install,
> which are to be run as root, cannot be made completely fool-proof,
Surely, the completely fool-proof check seems to be impossible
when I think about a range of a check.
Therefore, please close this bug.
Okay, thanks. I understand why you wanted to try to do this but it's really
impractical, and a false sense of security is worse than knowing there is