RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 700759 - Suggest give warning message if specify both -n and -b for converting
Summary: Suggest give warning message if specify both -n and -b for converting
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-v2v
Version: 6.1
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Matthew Booth
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 711296
TreeView+ depends on / blocked
 
Reported: 2011-04-29 10:37 UTC by Qin Guan
Modified: 2011-12-06 14:49 UTC (History)
10 users (show)

Fixed In Version: virt-v2v-0.8.2-2.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 711296 (view as bug list)
Environment:
Last Closed: 2011-12-06 14:49:19 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:1615 0 normal SHIPPED_LIVE Low: virt-v2v security and bug fix update 2011-12-06 00:51:05 UTC

Description Qin Guan 2011-04-29 10:37:26 UTC
Description of problem:
Suggest give warning message if specify both -n and -b for converting:
WARNING: --network and --bridge can not be used in conjunction

As from the virt-v2v man page, the two options -n and -b can not be used in conjunction. 

Version-Release number of selected component (if applicable):

kernel:2.6.18-256.el5
virt-v2v-0.7.1-2.el5
libguestfs-1.2.7-1.el5.13
libvirt-0.8.2-15.el5_6.3

How reproducible:
always

Steps to Reproduce:
1. make sure both bridge and network exists on the target hypervisor
2. make sure no network and birdge define in /etc/virt-v2v.conf
3. specify both -n and -b while converting the VM:
# virt-v2v -ic xen+ssh://10.66.72.123 -b breth0 -n virbr0 -os default xen-pv-rhel5.7-x86_64
root.72.123's password: 
root.72.123's password: 
virt-v2v: Transferring storage volume xen-pv-rhel5.7-x86_64.img: 4194304000 bytes
virt-v2v: xen-pv-rhel5.7-x86_64 configured with virtio drivers

4. check the network type after VM converted

In the step 4, the VM network type set as network, which means the -b option is not effective when both specified.

Actual results:
No error or warning message print when specify both -n and -b

Expected results:
Print warning message, such as:
WARNING: --network and --bridge can not be used in conjunction.

Additional info:
virt-v2v man page:

       -n network | --network network
           Map all guest bridges or networks which don't have a mapping in the
           configuration file to network.

           This option cannot be used in conjunction with --bridge.

       -b bridge | --bridge bridge
           Map all guest bridges or networks which don't have a mapping in the
           configuration file to bridge.

           This option cannot be used in conjunction with --network.

Comment 2 Matthew Booth 2011-07-28 14:35:44 UTC
This is fixed upstream.

Comment 4 tingting zheng 2011-08-22 04:31:46 UTC
Verified this bug with the following packages:
virt-v2v-0.8.3-1.el6.x86_64
libguestfs-1.7.17-26.el6.x86_64
libvirt-0.9.4-4.el6.x86_64

Steps:
[root@tzheng-rhevm Desktop]# virt-v2v -ic xen+ssh://10.66.72.123 -b rhevm -n virbr0 -os default xen-hvm-rhel4.8-i386
--network and --bridge are mutually exclusive
Usage:
     virt-v2v -i libvirtxml -os imported --network default guest-domain.xml

     virt-v2v -ic esx://esx.server/ -os imported --network default esx_guest

     virt-v2v -ic esx://esx.server/ \
              -o rhev -os rhev.nfs.storage:/export_domain --network rhevm \
              esx_guest

Options:
    -i input
        Specifies what input method to use to obtain the guest for
        conversion. The default is "libvirt". Supported options are:

        *libvirt*
            Guest argument is the name of a libvirt domain.

        *libvirtxml*
            Guest argument is the path to an XML file containing a libvirt
            domain.

    -ic URI
        Specifies the connection to use when using the libvirt input method.
        If omitted, this defaults to qemu:///system when virt-v2v runs as
        root, or qemu:///session when virt-v2v runs as a regular user.

        N.B. virt-v2v can currently automatically obtain guest storage from
        local libvirt connections, ESX connections, and connections over
        SSH. Other types of connection are not supported.

    -o method
        Specifies the output method. Supported output methods are:

        libvirt
            Create a libvirt guest. *-os* must specify a libvirt storage
            pool for the libvirt output method.

            Also see the *-oc* option.

        rhev
            Create a guest on a RHEV 'Export' storage domain, which can
            later be imported into RHEV using the UI. *-os* must specify the
            location of a RHEV export storage domain for the RHEV output
            method.

        If no output type is specified, it defaults to libvirt.

    -oc URI
        Specifies the libvirt connection to use to create the converted
        guest. If ommitted, this defaults to qemu:///system.

        N.B. virt-v2v must be able to write directly to storage described by
        this libvirt connection. This makes writing to a remote connection
        impractical at present.

    -os storage
        The output method dependent location where new storage will be
        created for the converted guest.

        For the *libvirt* output method, this must be the name of a storage
        pool.

        For the *rhev* output method, this specifies the NFS path to a RHEV
        Export storage domain. Note that the storage domain must have been
        previously initialised by RHEV. The domain must be in the format
        <host>:<path>, eg:

         rhev-storage.example.com:/rhev/export

        The nfs export must be mountable and writable by the machine running
        virt-v2v.

    -op pool
        See *-os* for the *libvirt* output method.

        DEPRECATED Use *-os* instead.

    -osd domain
        See *-os* for the *rhev* output method.

        DEPRECATED Use *-os* instead.

    -of format
        Specifies the on-disk format which will be used for the converted
        guest. Currently supported options are *raw* and *qcow2*. If not
        specified, the converted guest will use the same format as the
        source guest.

    -oa allocation
        Specifies whether the converted guest should be *sparse* or
        *preallocated*. If not specified, the converted guest will use the
        same allocation scheme as the source.

    -on outputname
        Rename the guest.

        If this option is not given, then the output name is the same as the
        input name.

    -f file | --config file
        Load a virt-v2v configuration from *file*. Multiple configuration
        files can be specified, which will be searched in the order they are
        specified on the command line. If no configuration is specified,
        defaults to /etc/virt-v2v.conf and /var/lib/virt-v2v/virt-v2v.db in
        that order.

        When overriding the default config file it is recommended that
        /var/lib/virt-v2v/virt-v2v.db is also specified, as it contains
        default configuration data required for conversions.

    -n network | --network network
        Map all guest bridges or networks which don't have a mapping in the
        configuration file to *network*.

        This option cannot be used in conjunction with *--bridge*.

    -b bridge | --bridge bridge
        Map all guest bridges or networks which don't have a mapping in the
        configuration file to *bridge*.

        This option cannot be used in conjunction with *--network*.

    -p profile | --profile profile
        Take default values for output method, output storage and network
        mappings from *profile* in the configuration file.

    --root=ask
    --root=single
    --root=first
    --root=/dev/sdX
        Choose the root filesystem to be converted.

        In the case where the virtual machine is dual-boot or multi-boot, or
        where the VM has other filesystems that look like operating systems,
        this option can be used to select the root filesystem (a.k.a. "C:
        drive" or "/") of the operating system that is to be converted. The
        Windows Recovery Console, certain attached DVD drives, and bugs in
        libguestfs inspection heuristics, can make a guest look like a
        multi-boot operating system.

        The default in virt-v2v ≤ 0.7.1 was *--root=single*, which causes
        virt-v2v to die if a multi-boot operating system is found.

        Since virt-v2v ≥ 0.7.2 the default is now *--root=ask*: If the VM is
        found to be multi-boot, then virt-v2v will stop and list the
        possible root filesystems and ask the user which to use. This
        requires that virt-v2v is run interactively.

        *--root=first* means to choose the first root device in the case of
        a multi-boot operating system. Since this is a heuristic, it may
        sometimes choose the wrong one.

        You can also name a specific root device, eg. *--root=/dev/sda2*
        would mean to use the second partition on the first hard drive. If
        the named root device does not exist or was not detected as a root
        device, then virt-v2v will fail.

        Note that there is a bug in grub which prevents it from successfully
        booting a multiboot system if VirtIO is enabled. Grub is only able
        to boot an operating system from the first VirtIO disk.
        Specifically, /boot must be on the first VirtIO disk, and it cannot
        chainload an OS which is not in the first VirtIO disk.

    --list-profiles
        Display a list of target profile names specified in the
        configuration file.

    --help
        Display brief help.

    --version
        Display version number and exit.

Comment 5 errata-xmlrpc 2011-12-06 14:49:19 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2011-1615.html


Note You need to log in before you can comment on or make changes to this bug.