Re: [libvirt-users] Managing eths in vm from HV
On 12/07/2012 01:37 PM, john fisher wrote:
KVM Ubuntu 12.04 libvirt 1.0
Related to my post of a day ago, but I can't reply to it...
I want to control the order ( and therefore the connection) of eth devices in the vm. If
I know what the MAC addresses
are on my HV, as seen in virsh domiflist or in dumpxml, and I then re-write the
/etc/udev/rules/70 file in the VM, I can
get the eth devices ordered in a predictable way.
Is there a virsh way to create a VM from a generic xml file, allowing libvirt to add
randomized MAC addresses, and then
edit the /etc/udev/rules/70 file in the VM, to associate the eths with the desired MAC?
Yes. virsh define (but not start) so that libvirt will create the
randomized MAC, then use libguestfs-tools to modify files residing in
the guest image, and then finally boot the guest.
Better yet, is there a way to simply control the assigning of the eths in the generic xml
file used to create the VM?
Libvirt passes the devices to the qemu command line in the same order
that they appear in the XML. It is not libvirt's fault if qemu then
takes the command line arguments and presents it to the guest in such a
way that the guest can initialize the devices in the order in which a
bus scan finds them, rather than in the order they were presented on the
command line.
So far I can make a wrapper script to virsh create xml, read the addresses back, and
then start the VM independently,
write to it, and then return control to virsh. That seems clumsy. Virsh ought to be able
to control the eths in the VM
without resorting to OS-dependent kludges.
With libguestfs, you don't have to start the guest to modify files
residing within the guest image; that may reduce some of your
OS-dependence. However, knowing what files to write, and even what file
systems the guest OS uses, is inherently guest-OS-dependent, so I don't
see how you can get completely away from that fact.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)