| Summary: | Libvirt can't dump floppy device and cdrom which is client device from vmware guest | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | mxie <mxie> | ||||||
| Component: | libvirt | Assignee: | Virtualization Maintenance <virt-maint> | ||||||
| libvirt sub component: | General | QA Contact: | mxie <mxie> | ||||||
| Status: | CLOSED WONTFIX | Docs Contact: | |||||||
| Severity: | medium | ||||||||
| Priority: | medium | CC: | jsuchane, juzhou, mkletzan, mprivozn, mxie, mzhan, ptoscano, rjones, tzheng, virt-maint, xiaodwan, xuzhang | ||||||
| Version: | 9.0 | Keywords: | Reopened, Triaged | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2022-01-19 14:40:09 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Attachments: |
|
||||||||
|
Description
mxie@redhat.com
2016-09-22 09:24:28 UTC
Libvirt also can't dump floppy device which has connected with floppy file from vmware guest
Packages:
libvirt-3.2.0-9.el7.x86_64
qemu-kvm-rhev-2.9.0-10.el7.x86_64
Steps:
1.Prepare a floppy guest whose floppy device has connected with floppy file on vmware, pls refer to screenshot "floppy"
2.Use virsh to dump the xml info of vmware floppy guest but can't find any floppy device info in xml
2.1#virsh -c vpx://root.75.182/data/10.73.72.61/?no_verify=1
Enter root's password for 10.73.75.182:
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
2.2 virsh # dumpxml test-floppy
<domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'>
<name>test-floppy</name>
<uuid>4237c5ba-2b98-8c53-4e31-9ae6e17b203a</uuid>
<memory unit='KiB'>2097152</memory>
<currentMemory unit='KiB'>2097152</currentMemory>
<vcpu placement='static'>1</vcpu>
<cputune>
<shares>1000</shares>
</cputune>
<os>
<type arch='i686'>hvm</type>
</os>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<disk type='file' device='disk'>
<source file='[esx6.0-tzheng] test-floppy/test-floppy.vmdk'/>
<target dev='sda' bus='scsi'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<disk type='file' device='cdrom'>
<source file='[windows-iso] VMware-VCSA-all-6.0.0-2656757.iso'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<controller type='scsi' index='0' model='vmpvscsi'/>
<controller type='ide' index='0'/>
<interface type='bridge'>
<mac address='00:50:56:b7:75:9e'/>
<source bridge='VM Network'/>
<model type='vmxnet3'/>
</interface>
<video>
<model type='vmvga' vram='8192' primary='yes'/>
</video>
</devices>
<vmware:datacenterpath>data</vmware:datacenterpath>
</domain>
Created attachment 1287572 [details]
floppy
Old bug... would it be possible to get the .vmx file of the guest? Sorry for late reply, this is the vmx of guest which has client floppy and cdrom # cat esx5.5-rhel7.4-x86_64.vmx .encoding = "UTF-8" config.version = "8" virtualHW.version = "10" nvram = "esx5.5-rhel7.4-x86_64.nvram" pciBridge0.present = "TRUE" svga.present = "TRUE" pciBridge4.present = "TRUE" pciBridge4.virtualDev = "pcieRootPort" pciBridge4.functions = "8" pciBridge5.present = "TRUE" pciBridge5.virtualDev = "pcieRootPort" pciBridge5.functions = "8" pciBridge6.present = "TRUE" pciBridge6.virtualDev = "pcieRootPort" pciBridge6.functions = "8" pciBridge7.present = "TRUE" pciBridge7.virtualDev = "pcieRootPort" pciBridge7.functions = "8" vmci0.present = "TRUE" hpet0.present = "TRUE" displayName = "esx5.5-rhel7.4-x86_64" extendedConfigFile = "esx5.5-rhel7.4-x86_64.vmxf" virtualHW.productCompatibility = "hosted" memSize = "2048" scsi0.virtualDev = "pvscsi" scsi0.present = "TRUE" ide1:0.deviceType = "atapi-cdrom" ide1:0.fileName = "emptyBackingString" ide1:0.present = "TRUE" floppy0.startConnected = "FALSE" floppy0.clientDevice = "TRUE" floppy0.fileName = "vmware-null-remote-floppy" ethernet0.virtualDev = "vmxnet3" ethernet0.networkName = "VM Network" ethernet0.addressType = "vpx" ethernet0.generatedAddress = "00:50:56:b7:68:00" ethernet0.present = "TRUE" scsi0:0.deviceType = "scsi-hardDisk" scsi0:0.fileName = "esx5.5-rhel7.4-x86_64.vmdk" scsi0:0.present = "TRUE" guestOS = "rhel7-64" toolScripts.afterPowerOn = "TRUE" toolScripts.afterResume = "TRUE" toolScripts.beforeSuspend = "TRUE" toolScripts.beforePowerOff = "TRUE" uuid.bios = "42 37 df 0e 8d e9 2d 1d-d4 86 90 8d ab f6 08 10" vc.uuid = "50 37 f8 08 b4 9b 00 e8-e5 df fe 6b 8a 1b 13 64" svga.vramSize = "8388608" sched.swap.derivedName = "/vmfs/volumes/b986a262-5393f43f/esx5.5-rhel7.4-x86_64/esx5.5-rhel7.4-x86_64-46519a75.vswp" uuid.location = "56 4d 68 a7 10 d0 94 20-ca ca 89 7f 7f fe 28 ea" replay.supported = "FALSE" replay.filename = "" scsi0:0.redo = "" pciBridge0.pciSlotNumber = "17" pciBridge4.pciSlotNumber = "21" pciBridge5.pciSlotNumber = "22" pciBridge6.pciSlotNumber = "23" pciBridge7.pciSlotNumber = "24" scsi0.pciSlotNumber = "160" ethernet0.pciSlotNumber = "192" vmci0.pciSlotNumber = "32" scsi0.sasWWID = "50 05 05 6e 8d e9 2d 10" vmci0.id = "-1409939440" vmotion.checkpointFBSize = "8388608" cleanShutdown = "TRUE" softPowerOff = "TRUE" tools.syncTime = "FALSE" ide1:0.startConnected = "FALSE" ide1:0.clientDevice = "TRUE" pciPassthru0.id = "02:00.1" pciPassthru0.deviceId = "0x1521" pciPassthru0.vendorId = "0x8086" pciPassthru0.systemId = "559ce51f-08f9-eeda-a53c-2c59e54291e4" sched.cpu.min = "0" sched.cpu.units = "mhz" sched.cpu.shares = "normal" sched.mem.min = "2048" sched.mem.shares = "normal" ethernet1.virtualDev = "vmxnet3" ethernet1.networkName = "VM Network" ethernet1.addressType = "vpx" ethernet1.generatedAddress = "00:50:56:b7:60:2a" ethernet1.present = "TRUE" ethernet2.virtualDev = "vmxnet3" ethernet2.networkName = "VM Network" ethernet2.addressType = "vpx" ethernet2.generatedAddress = "00:50:56:b7:ce:2c" ethernet2.present = "TRUE" ethernet3.virtualDev = "vmxnet3" ethernet3.networkName = "VM Network" ethernet3.addressType = "vpx" ethernet3.generatedAddress = "00:50:56:b7:39:43" ethernet3.present = "TRUE" ethernet4.virtualDev = "vmxnet3" ethernet4.networkName = "VM Network" ethernet4.addressType = "vpx" ethernet4.generatedAddress = "00:50:56:b7:94:05" ethernet4.present = "TRUE" ethernet5.virtualDev = "vmxnet3" ethernet5.networkName = "VM Network" ethernet5.addressType = "vpx" ethernet5.generatedAddress = "00:50:56:b7:bf:4c" ethernet5.present = "TRUE" ethernet6.virtualDev = "vmxnet3" ethernet6.networkName = "VM Network" ethernet6.addressType = "vpx" ethernet6.generatedAddress = "00:50:56:b7:93:c8" ethernet6.present = "TRUE" ethernet7.virtualDev = "vmxnet3" ethernet7.networkName = "VM Network" ethernet7.addressType = "vpx" ethernet7.generatedAddress = "00:50:56:b7:59:7b" ethernet7.present = "TRUE" ethernet8.virtualDev = "vmxnet3" ethernet8.networkName = "VM Network" ethernet8.addressType = "vpx" ethernet8.generatedAddress = "00:50:56:b7:24:df" ethernet8.present = "TRUE" ethernet9.virtualDev = "vmxnet3" ethernet9.networkName = "VM Network" ethernet9.addressType = "vpx" ethernet9.generatedAddress = "00:50:56:b7:54:a1" ethernet9.present = "TRUE" ethernet1.pciSlotNumber = "224" ethernet2.pciSlotNumber = "256" ethernet3.pciSlotNumber = "1184" ethernet4.pciSlotNumber = "1216" ethernet5.pciSlotNumber = "1248" ethernet6.pciSlotNumber = "1280" ethernet7.pciSlotNumber = "2208" ethernet8.pciSlotNumber = "2240" After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. My apologies, this bug was closed by a broken process that we do not have any control over. Reopening. (In reply to mxie from comment #6) > Sorry for late reply, this is the vmx of guest which has client floppy and > cdrom > > # cat esx5.5-rhel7.4-x86_64.vmx > scsi0.virtualDev = "pvscsi" > scsi0.present = "TRUE" > ide1:0.deviceType = "atapi-cdrom" > ide1:0.fileName = "emptyBackingString" > ide1:0.present = "TRUE" > floppy0.startConnected = "FALSE" > floppy0.clientDevice = "TRUE" > floppy0.fileName = "vmware-null-remote-floppy" Are you sure this is the correct .vmx file? It looks like both CDROM and floppy are empty. (In reply to Michal Privoznik from comment #14) > (In reply to mxie from comment #6) > > Sorry for late reply, this is the vmx of guest which has client floppy and > > cdrom > > > > # cat esx5.5-rhel7.4-x86_64.vmx > > > scsi0.virtualDev = "pvscsi" > > scsi0.present = "TRUE" > > ide1:0.deviceType = "atapi-cdrom" > > ide1:0.fileName = "emptyBackingString" > > ide1:0.present = "TRUE" > > floppy0.startConnected = "FALSE" > > floppy0.clientDevice = "TRUE" > > floppy0.fileName = "vmware-null-remote-floppy" > > Are you sure this is the correct .vmx file? It looks like both CDROM and > floppy are empty. Yes, this is correct, the reason why the cdrom and floppy device doesn't show real file name in guest vmx file is there is no file connected in client floppy and cdrom device at this time, but you can connect files to cdrom and floppy device in guest remote console, pls refer to screenshots"can-connect-file-for-client-floppy-device.png" and "client-type-cdrom-floppy-device.png" Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release. After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. The comment above is incorrect but was generated by a process we have no control over, reopening. It looks like there is no way to gather this information from the vmx file and it would require either a rewrite of our driver for the new APIs or possibly a partial fix with SOAP APIs, but similarly to Bug 1794317 this will not get enough attention unless there are more resources and needs for this. Therefore I suggest closing this. @ Closing per previous comment. |