Re: [libvirt] [PATCH 7/7] Add support for attaching network/bridge NICs in QEMU driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 22, 2009 at 10:57:36PM +0100, Mark McLoughlin wrote:
> @@ -4637,10 +4639,16 @@ static int qemudDomainAttachNetDevice(virConnectPtr conn,
>  
>      if (net->type == VIR_DOMAIN_NET_TYPE_BRIDGE ||
>          net->type == VIR_DOMAIN_NET_TYPE_NETWORK) {
> -        qemudReportError(conn, dom, NULL, VIR_ERR_NO_SUPPORT,
> -                         _("network device type '%s' cannot be attached"),
> -                         virDomainNetTypeToString(net->type));
> -        return -1;
> +        if (vm->monitor_chr->type != VIR_DOMAIN_CHR_TYPE_UNIX) {
> +            qemudReportError(conn, dom, NULL, VIR_ERR_NO_SUPPORT,
> +                             _("network device type '%s' cannot be attached: "
> +                               "qemu is not using a unix socket monitor"),
> +                             virDomainNetTypeToString(net->type));
> +            return -1;
> +        }
> +
> +        if ((tapfd = qemudNetworkIfaceConnect(conn, driver, net, qemuCmdFlags)) < 0)
> +            return -1;
>      }


Obviously this code is supporting upgrades frm 0.6.5 -> 0.7.0 where
libvirtd restarts with VMs already running using a PTY.

We should decide on how many versions we wish to support upgrades
with live VMs for. ie, delete all this PTY compatability code in
something like the 0.8.0 release ?

It is also probably worth formalizing how long we wish to support a
particular hypervisor release series for.

ie how long do we wish to support Xen 3.0.3 for (for benefit of
RHEL-5) before we declare only Xen 3.1.0 or later & thus drop
all the crufty xm_internal.c code.

As a starting point I'd say we should support a particular HV
release for as long as it is shipped in the current release of
a major distro. ie we'd support Xen 3.0.3 for as long as RHEL-5
was most recent, and once RHEL-6 came out we'd drop Xen 3.0.3
support, picking the next oldest Xen version that's used in a
current major distro whether that's 3.1.0 or 3.3.0 or something
else. This would allow distro maintainers reasonably easy
backports and/or rebases to newer libvirt versions for some
amount of time, without burdening us (upstream) to support ancient
versions of Xen / QEMU forever.


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]