Also occurs in virt-v2v-0.6.3-4.el5. +++ This bug was initially created as a clone of Bug #665883 +++ Description of problem: If customer uses name like redhat#1 in vm names on Vmware ESX during the conversion to KVM the name will change to redhat|231 Example: # virt-v2v -ic esx://192.168.1.13/?no_verify=1 -op default --bridge virbr0 rhel5.5#1 ** HEAD https://192.168.1.13/folder/New%20Virtual%20Machine/New%20Virtual%20Machine-flat.vmdk?dcPath=ha-datacenter&dsName=Storage1 ==> 401 Unauthorized ** HEAD https://192.168.1.13/folder/New%20Virtual%20Machine/New%20Virtual%20Machine-flat.vmdk?dcPath=ha-datacenter&dsName=Storage1 ==> 200 OK (1s) ** GET https://192.168.1.13/folder/New%20Virtual%20Machine/New%20Virtual%20Machine-flat.vmdk?dcPath=ha-datacenter&dsName=Storage1 ==> 200 OK (1481s) virt-v2v: rhel5.5|231 configured with virtio drivers [root@localhost ~]# <started the vm via virtual-Manager> # virsh Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # list Id Name State ---------------------------------- 5 rhel5.5|231 running virsh # # man ascii <snip> Oct Dec Hex Char 043 35 23 # <snip> Additional info: ======================== Other tests that I made which worked just fine: 1) #virt-v2v -ic esx://192.168.1.13/?no_verify=1 -op v2v --bridge virbr0 "rhel5(x86)" virsh # list Id Name State ---------------------------------- 3 rhel5(x86) running 2) #virt-v2v -ic esx://192.168.1.13/?no_verify=1 -op v2v --bridge virbr0 rhel5\(x86\) virsh # list Id Name State ---------------------------------- 3 rhel5(x86) running Packages: =================== #rpm -qa | grep v2v virt-v2v-0.6.2-4.el6.x86_64 #rpm -qa | grep libvirt libvirt-python-0.8.1-27.el6.x86_64 libvirt-0.8.1-27.el6.x86_64 libvirt-client-0.8.1-27.el6.x86_64 libvirt-java-0.4.5-2.el6.noarch libvirt-java-devel-0.4.5-2.el6.noarch libvirt-devel-0.8.1-27.el6.x86_64
libvirt doesn't support the hash character in guest names. This behaviour is desirable.
(In reply to comment #1) > libvirt doesn't support the hash character in guest names. This behaviour is > desirable. Yes it does ... $ sudo virsh list --all Id Name State ---------------------------------- - shut off - " shut off - # shut off - , shut off - - shut off - : shut off - ; shut off - > shut off - \ shut off - CentOS5x64 shut off - Debian5x64 shut off - F12x64 shut off - F13x32 shut off - F13x64 shut off - F14Watchdogx64 shut off - F14x64 shut off - FedoraRawhidex64 shut off - FreeBSD8x64 shut off - MeeGo11x32 shut off - Minix3x32 shut off - OpenSUSE11x64 shut off - RHEL3x64 shut off - RHEL4x64 shut off - RHEL5brewx64 shut off - RHEL5EPELx64 shut off - RHEL5Xenbrewx64 shut off - RHEL60x64 shut off - RHEL6brewx64 shut off - TwentyDisks shut off - TwoDisks shut off - Ubuntu1010x64 shut off - VBox shut off - Win7x32 shut off - | shut off - shut off - shut off - 変な shut off
Re-opened as per comment 2. Interesting that my simple test didn't show this.
This is working fine in 0.7.1.
Verified with # and ': 1. name with #: [root@dhcp-8-218 ~]# virt-v2v -ic xen+ssh://10.66.72.123 -o rhev -os 10.66.10.160:/tmp/nfs_export xen-hvm-rhel5.7-i386 You have new mail in /var/spool/mail/root [root@dhcp-8-218 ~]# virt-v2v -ic esx://10.66.72.79/?no_verify=1 -os default esx4.1-rhel5.7-x86_64-qguan-#test virt-v2v: Transferring storage volume esx4.1-rhel5.7-x86_64_esx4.1-rhel5.7-x86_64: 8589934592 bytes virt-v2v: WARNING: No mapping found for bridge interface VM Network in config file. The converted guest may not start until its network interface is updated. virt-v2v: esx4.1-rhel5.7-x86_64-qguan-#test configured with virtio drivers start the VM: [root@dhcp-8-218 ~]# virsh list --all|grep esx4.1-rhel5.7-x86_64-qguan 5 esx4.1-rhel5.7-x86_64-qguan-#test running 2. name with ': [root@dhcp-8-218 ~]# virt-v2v -ic esx://10.66.72.79/?no_verify=1 -os default esx4.1-rhel5.7-x86_64-qguan-\'test virt-v2v: Transferring storage volume esx4.1-rhel5.7-x86_64_esx4.1-rhel5.7-x86_64: 8589934592 bytes virt-v2v: WARNING: No mapping found for bridge interface VM Network in config file. The converted guest may not start until its network interface is updated. virt-v2v: esx4.1-rhel5.7-x86_64-qguan-'test configured with virtio drivers start the VM [root@dhcp-8-218 ~]# virsh start esx4.1-rhel5.7-x86_64-qguan-\'test Domain esx4.1-rhel5.7-x86_64-qguan-'test started [root@dhcp-8-218 ~]# virsh list --all|grep esx4.1-rhel5.7-x86_64-qguan 5 esx4.1-rhel5.7-x86_64-qguan-'test running
Update comment 6: Verified with virt-v2v-0.7.1-4.el5+ libguestfs-1.2.7-1.el5.13+ zlib-1.2.3-3 1.# virt-v2v -ic esx://10.66.72.79/?no_verify=1 -op default -b breth0 "ESX4.1-(x86)" virt-v2v: Transferring storage volume ESX4.1-Test-VM_ESX4.1-Test-VM: 5368709120 bytes virt-v2v: ESX4.1-(x86) configured with virtio drivers 2.# virt-v2v -ic esx://10.66.72.79/?no_verify=1 -op default -b breth0 "ESX4.1-<x86>;1" virt-v2v: Transferring storage volume ESX4.1-Test-VM_ESX4.1-Test-VM: 5368709120 bytes virt-v2v: Transferring storage volume ESX4.1-Test-VM_ESX4.1-Test-VM_1: 1073741824 bytes virt-v2v: Transferring storage volume ESX4.1-Test-VM_ESX4.1-Test-VM_2: 1073741824 bytes virt-v2v: ESX4.1-<x86>;1 configured with virtio drivers
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1125.html